Seems like a hard issue to track down a definitive guide on - I have two RV042 routers in separate sites - both are stuck behind ADSL modems with private IP addresses on the RV042 WAN ports for various reasons (on the satellite office the DSL modem is controlled by the ISP so cannot be set to bridge mode) and dynamic IP address on the DSL WAN side. My question is what should the local and remote group setup be for a tunnel between such routers?
Have gone through all the permutations I can muster and get tunnel N/A always in the RV042 web config page which was time consuming enough to justify doing a little diagram (see attached) - the frustrating thing is this worked previously with an old (now long obsolete) DSL modem that was giving unreliable connection problems so had to be replaced...
Thanks in advance
Do you have the option NAT traversal checked on both side on the VPN configuration. It will be good if you can share how is configured the VPN on the 2 routers as of now
yes NAT-T and the rest of the advanced options ON and OFF have been part of the many permutations that I have tried - also VPN passthrough enabled on the ADSL gateways (and the UDP ports noted forwarded to the RVO42).
My guess is its something to do with the local/remote group setup - theres nothing in the RV042 manual about what the setup should be when behind a gateway - all the descriptions assume that the RV042 has a public IP address which of course neither of my RV042's do - of course could be something missing on the gateway configuration
Generally the Small Business routers need to be on the edge themselves, with the public IP on the WAN interface of our device. The reason for that is because the WAN IP is what the routers use to identify each other when establishing the VPN connection.
That is why there is no recommended setup for when you are behind a gateway, because it usually just doesn't work. In fact when we get calls here at the Small Business Support Center if the public IPs are not on our device we cannot support that setup. You have to get the ISP to bridge the modems first.
Your best bet really would be to convince your ISP to bridge your modems, it is quite unusual that they won't do that for you.
However, your main question here seems to be what your local and remote groups should be so let's focus on that.
From your diagram it looks like site 1 has a LAN subnet of 192.168.100.0/24 and site 2 has a LAN subnet of 192.168.101.0/24.
In that case your local group on site 1 will be 192.168.100.0 255.255.255.0 and the remote will be 192.168.101.0 255.255.255.0. Then you simply reverse those on site 2.
One other thing that popped into my head is you mentioned one of the modem's was recently replaced, is it possible the DMZ or port forwards were not reconfigured?
You can also post the log messages if you have them, they may be able to tell us what is going wrong.
Thank you for choosing Cisco,
Network Support Engineer - Cisco Small Business Support Center
Still not sure of your local and remote group suggestion - I improved the diagram (attached) so that my expected configuration is shown in detail but I have tried countless other permutations - I guess basically I just dont understand the local group requirement in particular and how the security grouping works in general.
I reckon both modems respective DMZ and port forwarding is good in my configuration as remote PPTP clients have no trouble connected to either site (obviously different ports on gateway to gateway but I have shown these in the diagram for clarity).
User kivanova has noted that both R042's are on 192.168.1.0 private subnets - something new for me to try - probably best that they are different any case
Thank you for the updated diagram. Going off of that it looks like you have all the settings correct as far as local and remote group go.
I agree Kremena and would also suggest changing the WAN IPs of the two RV042s to be in different subnets.
Another issue you may be having here is that you are using FQDN with dynamic IPs on both ends, this usually doesn't work.
Try changing one side to be set to IP by DNS resolved, that way you can still use the dyndns name but it will resolve to the correct IP.
Network Support Engineer - Cisco Small Business Support Center
Fixed the subnet clash (192.168.100.0) according to Kremena's suggestion and changed both remote group settings to IP to DNS resolved. Also managed to get the main office modem into bridge mode so now at least one RV042 has its WAN side on the public internet. Outcome is the tunnel test button shows enabled and the status is now waiting for connection but it never connects - getting closer at least
A thought occurred to me - should the remaining RV042 behind the modem/firewall be configured in router mode rather than gateway mode?
Once the tunnel are setup you may have to go and actually hit the connect button to bring the tunnel up. Before you do that you should enable the debug logging level so any errors and issues will show up in the logs, which can help us figure out what is going on.
As for router vs gateway mode, it sort of depends. When the router is in router mode the firewall and NAT/PAT are both disabled, meaning the traffic leaving the WAN of the RV won't be translated. Whether that will work or not depends on your modem/router and whether it will NAT for the subnet behind the RV as well.
Network Support Engineer - Cisco Small Business Support
Thanks again Christopher
Ok so now it works - see attached for final configuration - think getting the modems more favourably configured helped but it was getting the correct local and remote group settings that is crucial.
My only nagging doubt is the local group IP only forces the dynamic WAN IP address at the time of configuration and does not give the IP by DNS Resolved option that appears on the remote group same selection. What happens to the VPN tunnel if the ISP randomly changes the IP address we get (which has happened) as we dont have a guaranteed assignment. I guess the simple answer is manual edit the VPN tunnel config when it does (hope it doesn't happen too often)
I'm not quite sure I understand your question, but let me see.
I noticed you changed on site to just IP, you should still be able to use the FQDN option, that way when the ISP assigned IP does change it should resolve using the dyndns entry you had earlier. You only run into an issue when you use FQDN on both sides, but FQDN and IP by DNS resolved should work just fine, so go ahead and give FQDN on one side and IP by DNS resolved on the other.
Your diagram also seems to group the local group and the IP address of the gateway together, but these settings are really separate. You have control over your local group, it is your inside subnet. The local IP is just the identifier for the router itself, they are independent of each other.
I would also strongly suggest a different password, although I'm guessing that is just there for testing purposes.
Let me know how that goes,