Gateways on site-to-site VPN cannot access resources in remote subnet

I have a site-to-site L2TP VPN running in our live environment. The setup looks something like this:

Gateway 1
Public IP: 1.1.1.1
Local private subnet: 192.168.1.0/24

Gateway 2
Public IP: 2.2.2.2
Local private subnet: 192.168.2.0/24

I can't ping (nor access any resources on) hosts on the remote subnet from either gateway. That is, Gateway 1 cannot ping anywhere in 192.168.2.0 and Gateway 2 cannot ping anywhere in 192.168.1.0.

What are the routes I need?
bevco7Asked:
Who is Participating?
 
Rob WilliamsCommented:
>>"I was reluctant to list my hardware at first, for fear of having to jump up and defend my firewalls "
Now were not that bad are we  :-)   Mac's are great !  I just don't know how to configure them. I suppose the routing principals would be similar.

If I understand correctly you have:
                                                                             | <= GW2a = Public IP 2a <= |
LAN 1 => Mac=> Public IP 1 => GW1 => Internet <=|                                          | <= Mac <=  LAN 2
                                                                             | <= GW2b = Public IP 2b <= |

If this is the case then at site 2 all LAN traffic destined for Internet browsing would be sent through GW2a which must be the default gateway. What happens in this scenario is VPN traffic from site 1 is pointed to Public IP 2b and forwarded to the PC on LAN 1, the reply is sent back but by default is sent through the default gateway GW2a and lost. So the only routing statement needed should be on the Mac at site 2:
send packets destined for LAN 1 through GW2b
If this were Windows the command would be:
route  add  192.168.1.0  mask  255.255.255.0  192.168.2.b      {where 'b' = gateway IP}
                 ^remote subnet       ^subnet mask   ^local gateway

I don't know if this helps any.
0
 
stressedout2004Commented:
What devices are involve here?
0
 
bevco7Author Commented:
It's running two Apple Xseve G5s with Mac OS X 10.4.6
0
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

 
Rob WilliamsCommented:
So long as the router through which the VPN is connected is the default gateway for the PC's you shouldn't need to add any routes. Any traffic destined for a network other than the local network is automatically re-directed to the default gateway.  If however you have multiple gateways in your network, and the one connecting the tunnel is not the default then you would add to subnet 1 computers:
route  add  192.168.2.0  MASK  255.255.255.0  192.168.1.1
Assuming the VPN gateway address for subnet 1 is 192.168.1.1

Or, if this is a Windows VPN server to VPN server network the virtual adapters should look after it.
Are you sure you have a connection. It is possible to have a connection but have GRE is being blocked by the routers and therefore not able to ping or make use of resources. On many routers this is enabled with "enable PPTP pass-through". If you provide specific router information we may be able to be more specific.
0
 
Rob WilliamsCommented:
Sorry didn't see last post referencing Mac's
0
 
bevco7Author Commented:
Thanks RobWill.  To answer your questions:

1. The Macs are the default gateways for PCs, though one side has two public interfaces.  VPN traffic heads down one interface, other traffic down the other (it is the default route).  The other side has a single interface.  Hosts behind the gateways can contact each other without problems, we definitely have a connection.  The routing table on each gateway doesn't have an entry for the opposite subnet.

2. I was reluctant to list my hardware at first, for fear of having to jump up and defend my firewalls before the routing (or firewall?) issue was considered.

Thanks again,

Sam
0
 
bevco7Author Commented:
Hi Rob,

That's the setup we have (assuming that GWs are logical representations of interfaces on the Macs).  We have VPN traffic going from LAN1 to LAN2 and back again across GW2b, so the Macs are doing routing correctly there.  It's when I try and get from Mac1 to LAN2 or Mac2 to LAN1 that everything goes belly-up.

That rule you've suggested makes sense, I'll give it a try tonight.

Thanks
0
 
Rob WilliamsCommented:
>>"It's when I try and get from Mac1 to LAN2 or Mac2 to LAN1 that everything goes belly-up."

That would make sense without adding the route. Only need it on the site with the dual public IP Mac.
0
 
Rob WilliamsCommented:
ps- as a test can you change the default gateway on LAN2, just to test your VPN. Should work then.
0
 
bevco7Author Commented:
That route did the trick, thanks Rob.  That said, we had to add the inverse route to the other end as well.  All's well now, they've been added to our persistent route startup script.
0
 
bevco7Author Commented:
That route did the trick, thanks Rob.  That said, we had to add the inverse route to the other end as well.  All's well now, they've been added to our persistent route startup script.
0
 
Rob WilliamsCommented:
Thanks bevco7, glad it worked out for you.
--Rob
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.