cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
739
Views
1
Helpful
3
Replies

VPN change broke NAT Loopback on RV320

ken.johnson1
Level 1
Level 1

A change to a VPN configuration caused NAT loopback to stop working on the RV320 router I call RV320_Branch.

Here's the network configuration; a vertical bar (|) is an Ethernet network.  The branch where I am located is connected to the main office by a pair of RV320 routers with an IPsec VPN over the Internet.

Client|Router|RV320_Main-(Ipsec VPN over Internet)-RV320_Branch|Server

Client and Router (and other systems) share network 10.20.20.0/24.

Router and RV320_Main (and other systems) share network 10.30.30.0/24

RV320_Branch and Server (and other systems) share network 10.10.10.0/24

In the old configuration, the Client on the left could reach systems on 10.30.30.0, but not systems on 10.10.10.0.  To change that, we set up some static routes in the Router and made a change to the VPN configuration.

Old VPN configuration:
Main:
Local Group 10.30.30.0/24
Remote Grp  10.10.10.0/24
Branch:
Local Group 10.10.10.0/24
Remote Grp  10.30.30.0/24

New VPN configuration:
Main:
Local Group 10.0.0.0/10
Remote Grp  10.10.10.0/24
Branch:
Local Group 10.10.10.0/24
Remote Grp  10.0.0.0/10

This change to the VPN configuration, along with the changes in 'Router', enabled Client (on the left above) to reach Server (on the right above).  Great, so far.

There are a limited set of services on the Server which can be accessed from the Internet via port forwarding.

The problem is that when we made this change, NAT loopback stopped working on the RV320_Branch router.  That is, systems on the 10.10.10.0/24 network could formerly reach resources on the server by specifying the external IP address of the RV320_Branch router.  That was convenient, because that allowed laptops to reference resources by DNS names, and it worked anywhere. After the VPN change, that stopped working.  When we changed the VPN configuration back to the original values, NAT loopback started working again.

Does anyone know of a workaround to this problem?

3 Replies 3

Mehdi Boukraa
Cisco Employee
Cisco Employee

Hi Ken, 

I can see from the new vpn configuration you have the Local Group and Remote group are overlapping 

10.0.0.0/10 is from 10.0.0.1 --until -- 10.63.255.254 is contain 10.10.10.0/24 network.

If you can test to change the 10.10.10.0/24 network to 10.64.10.0/24 should work or just to choose another Class of IP such 192.x.x.x/24  or 172.x.x.x/24

 

 

Please rate the post or mark as answered to help other Cisco Customers

 

Best Regards

Mehdi 

 

 

Yes, the local and remote groups overlap.  That is intentional.  That is what makes the routing of packets from 10.10.10.0/24 to 10.20.20.0 work.  And in fact that routing _does_ work, as it should.

The default route to the ISP (0.0.0.0/0) overlaps the route for the local network of 10.10.10.0/24, but that is not a problem; it does not keep NAT loopback from working.

IP renumbering (non-trivial, in this case) as a solution to what should be a legitimate route configuration is not the kind of workaround I was hoping for.

I note that your reply does not mention NAT Loopback, the feature that is broken.

 

ken.johnson1
Level 1
Level 1

I replaced the RV320 with the RV42 we had used previously.  The RV42 works with the configuration described above, including NAT Loopback.

This is not a great long-term solution, as we may someday have upstream internet connection that is faster than the RV42.  (This RV42 has had its capacitors replaced, and is hooked up using a 3rd party regulated power supply, so it may work for some time yet. :-) ) 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: