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

Can't get to other local hosts on RV042 once Greenbow VPN is up!

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by jmpage2, Aug 9, 2008.

  1. jmpage2

    jmpage2 Addicted to LI Member

    Hi guys, I'm posting here as I've been racking my brain trying to get this to work. Any ideas are welcome.

    I have an RV042 that is setting in the DMZ of a Cradlepoint MBR1000 router. The Cradlepoint is connected to the Internet through the Sprint PCS network. The goal is to connect into this remote network (a dental office) from anywhere with Greenbow VPN so that the Dentist can access their software, look up patient records, etc, when they are not in the office.

    The MBR1000 has IP address and has DHCP hosts in the range The RV042 has a static IP address of with a default gateway of and is connected via its WAN1 port to the Cradlepoint router.

    I can connect to the RV042 with Greenbow and get the VPN tunnel established. The problem is that once I am connected to the RV042, I can't connect to any other hosts on the 192.168.10.x subnet. I can't even ping them. I can ping the IP address of the RV042 just fine and I can get internet access, etc, just fine.

    I have tried building static routes between the RV042 and the MBR1000, changing the RV042 from gateway to router mode. Built an access list on the RV042 that allows all traffic in and out of the WAN interface, etc, but I can't seem to get this to work.

    When I do a trace route from the VPN connected client to a PC on the 192.168.10.x subnet I am seeing that the traceroute is hitting the WAN interface of the RV042 (in this case and then the Requests are showing as timed out. It is as if the packets are hitting the RV042 interface and then getting routed out to the internet instead of getting routed to the local interface on the MBR1000 (even though I have a static route there saying that if you want to talk to send the packets to (the IP address of the RV042 on the LAN)).

    Any ideas ??
  2. Toxic

    Toxic Administrator Staff Member

    what Access Rules do you have set on the RV042?
  3. jmpage2

    jmpage2 Addicted to LI Member

    Thanks for taking the time to reply. Supposedly people have this working but I haven't been able to get any first hand accounts of how MBR1000 owners have things set up other than simply putting the RV042 in the Cradlepoint's DMZ.

    I created a WAN access rule on the RV042 that says pass all traffic to and from any address.

    I've tried putting the LAN and WAN addresses of the RV042 in the same subnet as the Cradlepoint router, and I've also tried creating a completely separate subnet for the LAN interface on the RV042 while still keeping the WAN interface address as an IP address on the Cradlepoint subnet.

    Neither has worked. Although when I put the RV042 LAN interface in a separate subnet, such as, and I then try to do a ping out to the Cradlepoint subnet from the VPN connected machine I can see that it is dying when it hits the interface of the RV042.

    When I put both LAN and WAN interfaces on the same subnet that the rest of the LAN lives on ( I can see the trace routes going out to the internet, so it appears as though they are getting routed out directly to the internet and bypassing the local subnet... even with a static route defined in the Cradlepoint box.
  4. Sfor

    Sfor Network Guru Member

    In case of the VPN related pakets you have to make a routing rule considering the remote IP. Ping responses are adressed directly to the remote VPN device, not the VPN gateway. So, if the remote device has an IP different from the local subnet, the communication will break on the gateway, in case of your LAN configuration.

    The simplest way to solve your problem is connecting the RV042 as the Internet gateway. All LAN devices you wish to access through VPN should be placed in a separated network on the LAN side of the RV042. No additional routing rules will be necesary, then.
  5. jmpage2

    jmpage2 Addicted to LI Member

    I think trying to make the RV042 the internet gateway would actually make things worse, since it is not really possible. The internet gateway that I am using is a cell router that is making the internet connection via a cellular/3G modem and then distributing it out to the rest of the network via its layer 2 ports. I don't see how I can make the RV042 the head end easily in such a situation.

    If I'm understanding you correctly it sounds like you are saying that I need to identify the actual VPN address that the remote host is being assigned and build routes for this into the head end gateway so that it knows to direct packets destined for that subnet directly to that host?

    I'm not sure if I really understand this so any additional info such as a sample config, etc, would really be appreciated.
  6. Sfor

    Sfor Network Guru Member

    Yes, that's what I ment. I do have a WRV200 set as a VPN gateway while another router is the Internet gateway. I had to add a separate routing rule for each VPN tunnel in the internet gateway router.

    Well. The idea is to set the RV042 as a DMZ device of the MBR1000. All the devices in the LAN would be connected to the LAN side of the RV042. So, all packets going to the Internet or remote VPN networks would go to RV042. Then they would go to the MBR100 after passing RV042 NAT or VPN encryption. This would act just as a standard one IP internet connection sharing.
  7. jmpage2

    jmpage2 Addicted to LI Member

    So am I adding a route to the routable internet address of the host machine or for the host machine's VPN tunnel address? Sorry, just not completely clear on this. I can see an IP that is assigned for the VPN tunnel (at least that's what I'm assuming it is) by looking in the RV042 VPN status.

    OK, I see what you mean, use the RV042 as the LAN side core router and just have the MBR1000 act as the internet gateway after all traffic routes in and out of the RV042. I thought about trying it this way but saw several RV042 setup tutorials that expressly said such a thing would not work since effectively there would be a double natted connection between the RV042 clients and the internet which would cause several things to not work correctly.
  8. vpnuser

    vpnuser LI Guru Member

    In the User Guide of RV042 (available at
    there is an appendix D showing how to build a G2G tunnel with double NAT.
  9. jmpage2

    jmpage2 Addicted to LI Member

    I'm not sure if those scenarios would work with my cell router, which does not support one-to-one NAT like the RV042.

    It seems as though this won't be simple, although I am probably going to attempt both of the previously recommended solutions of building the RV042 as the head end of the private LAN network, then route it to the internet directly through the MBR1000 and also trying to put a VPN routing rule into the MBR1000 to route packets back to the internet/vpn host.
  10. Sfor

    Sfor Network Guru Member

    If you are pinging an IP in the LAN. A packet arrives the RV042. It is decrypted by the local VPN endpoint. Then it is sent to the IP you are pinging. The answer should go back the same way. But, the pinged device sends response through the internet gateway. Since the response is sent to the IP of the device you sent the ping request from, you have to set a proper routing rule in the Internet gateway router. The rule should direct all the traffic destined to the remote LAN address you sent the ping from through the RV042. The remote VPN gateway address is irrelevant in this case. As the VPN tunnel should be transparrent to both "pinger" and "pinged".

    Indeed the double NAT has some disadvantages. But, since the RV042 is in the DMZ of the MBR1000, it should work just as it would be connected directly. If a device is in DMZ it means it is excluded from NAT.
  11. jmpage2

    jmpage2 Addicted to LI Member

    OK, thanks, so I will need to put a routing rule in the MBR1000 that says if a packet is going to the "real" address of the VPN client then that traffic needs to be directed back to the RV042.

    I will give that a shot sometime soon and report back if I had any success.

  12. jmpage2

    jmpage2 Addicted to LI Member

    OK, I gave this a try and unfortunately it made it so that I could not do the initial VPN tunnel establishment since with the new routing rule it was routing all packets that needed to go to the outside client address back to the RV042 which is a bit of a catch 22.

    Just to recap, this is the configuration that I have->

    Client PC
    Cradlepoint MBR1000
    (LAN address
    RV042 Linksys
    (WAN port address (LAN port address

    The goal here is to establish a VPN tunnel from the internet into the RV042 and then still be able to access the various devices on the production subnet.

    If anyone has any further ideas on this I'd love to hear them, thanks!
  13. Sfor

    Sfor Network Guru Member

    In this case it is a catch 22, indeed. It can work only, if the client PC is behind NAT and the client PC IP is different from the other VPN tunnel end IP.

    So, the only possible solution left is to set the RV042 as the Internet gateway, and to place in the subnet all the devices you wish to access through VPN tunnel.
  14. jmpage2

    jmpage2 Addicted to LI Member

    Ah, I did not realize that if the client was behind a NAT it might work. So if the client is behind a NAT then just put a static route in the MBR1000 with a route instruction to route all packets destined for the client IP back to the RV042 router interface?

    I can test with client behind NAT as this in fact will be the normal configuration once this is working.
  15. Sfor

    Sfor Network Guru Member

    The problem with this scenario is, the remote VPN tunnel end has to have different IP then the remote VPN client. So it will work with a gateway to gateway VPN tunnel, for sure.

    As for the client behind NAT to gateway tunnel - it could work, but I had no opportunity to test it. It relies on NAT traversal function. In theory it should map the the remote VPN tunnel end to be different from the client IP.

Share This Page