1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

RV042 and gateway to gateway VPN

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by Billsey, Jun 28, 2007.

  1. Billsey

    Billsey LI Guru Member

    OK, so I have two RV042s, one out in the field using a 172.20.x.x subnet on it's LAN port and one at the office using a 192.168.7.x subnet on it's LAN port. I setup a gateway to gateway tunnel between the two subnets (127->192 on one side, 192->172 on the other) and had it connect. When I sit at a machine at the office (say 192.168.7.50) and try to ping a piece of equipment in the field (say 172.20.0.100) I get a timeout. Is there some routing I need to setup on the RV042s to allow traffic to actually go through the tunnel?
     
  2. binderz77

    binderz77 Network Guru Member

    No you would need to. Firstly, were you able to setup the tunnel successfully? If so, try testing the tunnel by using the "Diagnostic" under "System Management" to ping the local IP's of the gateway's on each end. If that fails I would suggest using - 192.168.7.x/24 on one end and 192.168.10.x/24 on the other.
     
  3. binderz77

    binderz77 Network Guru Member

    No you would NOT need to. Firstly, were you able to setup the tunnel successfully? If so, try testing the tunnel by using the "Diagnostic" under "System Management" to ping the local IP's of the gateway's on each end. If that fails I would suggest using - 192.168.7.x/24 on one end and 192.168.10.x/24 on the other.
     
  4. Billsey

    Billsey LI Guru Member

    When I use the "Diagnostic" under "System Management" to ping to the 172.20.0.x address of the field router, I get 4/4 successful, albeit slowly. When I instead try to ping any other address on the 172 subnet, I get 0/4 instead. This includes pinging the default gateway on the 172 side, 172.20.0.1. It looks as if that side isn't passing tunneled packet on to where they should go?
     
  5. fred3

    fred3 Network Guru Member

    Does the VPN show that it's connected?
    How does the pinging host route those packets to the VPN?

    What if you add a route to the pinging host like this: (XP method)

    route add 172.20.x.x mask 255.255.0.0 [IP of the 192.168.7.x VPN LAN address]
    .... or the equivalent of this for your particular situation.

    Then, any packet destined for the remote subnet will be directed to the VPN.
     
  6. ifican

    ifican Network Guru Member

    If the tunnel is established correctly no route will be needed for the connected subnet. You say that you get slow responses on the ping requests, how slow? If you are pinging from a windows machine they have a default "waittime", if your initial requests are getting close to that time and your requests from hosts past the gateway are going over that time, your requests will appear to time out even though they are getting through.
     
  7. Billsey

    Billsey LI Guru Member

    Figured out what was wrong... The RV042 at one end of the tunnel wasn't the default gateway for the devices on that subnet. If I change the default gateway on any of those devices to point to the RV042 (and through the RV042 to the normal default gateway) then I can browse that device. I'll have to go through my network and change default gateway on all internal devices, which will take a while, but at least then I can access them through a tunnel from outside our network.
     
  8. fred3

    fred3 Network Guru Member

    I wonder why changing the default gateway isn't (maybe) more of a problem than adding a specific route as I mentioned earlier? At least then the default gateway won't change and unforeseen problems won't be so likely.

    It said:
    On the hosts in the 192.168.7.x subnet, add a persistent route:

    route add -p 172.20.x.x mask 255.255.0.0 [IP of the 192.168.7.x VPN LAN address]
    .... or the equivalent of this for your particular situation.

    Then you leave the default alone - so no worries about changes there.
    And, any traffic for 172.20.x.x will be directed to the VPN.

    Of course, this makes no difference if the RV042 happens to be your public internet interface as well.
     
  9. Billsey

    Billsey LI Guru Member

    Fred, I may not understand what you are saying completely, but it sounds as if you're trying to fix the part that's not broken. Here's what was happening when things didn't work:

    A client on the 192.168.7.x network attempts to connect to a device on the 172.20.x.x network. It send an ARP out asking for the 172.20.x.x IP. The RV042 at 192.168.7.1 answers with 'I know where that is'. The 192.168.7.x client then sends a SYNC request to the 172.20.x.x address using 192.168.7.1's MAC address. The RV042 routes this packet through the tunnel to the RV042 at 172.20.0.2. On receipt 172.20.0.2 sends and ARP looking for the 172.20.x.x device. It receives a response from that device. It forwards the SYNC request packet to 172.20.x.x. The first portion of our transaction is done.

    The device at 172.20.x.x wants to send a ACK-SYNC to 192.168.7.x. It sends an ARP out and receives an answer from both the RV042 at 172.20.0.2 and from the default gateway at 172.20.0.1 (a layer 3 switch that handles both the 172.20.x.x network and our public IP space). For some reason, I'm guessing default routing metrics, the SYNC-ACK is then sent to 172.20.0.1, who tries to route it to it's default gateway where the packet is dropped since 192.168.x.x is a non-public address.

    My fix is to change the default gateway for the 172.20.x.x device to 172.20.0.2 (remember that the RV042 at 172.20.0.1 has 172.20.0.1 as its default gateway). Traffic destined for the 192.168.7.x subnet gets routed to the tunnel, traffic for 172.20.x.x gets routed by the RV042 to 172.20.0.1 and on from there to the other 172.20.x.x devices.

    I think my logic works anyway... :cool:
     
  10. fred3

    fred3 Network Guru Member

    Oh, OK. Now the concern is on the other side.

    So, consistent with what I said before, then you add a persistent route on the 172 side host that routes traffic destined for 192.168.7.0/24 to the local VPN address 172.20.0.2 as THE gateway for this traffic alone and leaving the default gateway alone otherwise.

    In other words, the treatment of the VPN can well be symmetrical. It doesn't matter which end is "remote", etc. Both sides need a mechanism to route packets through the VPN.

    You're relying on the ARP to affect the routing and on the VPN to cooperate. You might just as easily add static routes to the subnets I should think. A lot depends on how large the sytem is and how subject to change. The static routes could be in a local gateway or on each of the hosts.

    At least I think this makes sense ...... I'm very much learning this stuff at the moment.
     

Share This Page