RV320 to RV320 (GW to GW VPN)

[taaronlee76]

I have a site-to-site VPN tunnel setup between two RV320's, GW to GW.  The tunnel is created and stays up, but I can't ping any of the hosts on the other end.  It's not a FW or ACL issue since I disabled it and tried pinging the distant end, but nothing.  Could it be routing?  Do static routes need to be put into place?

Also, I have configured the tunnel to use the virtual IP range of 172.16.100.100-110.  How can you tell what virtual IP the tunnel is actually using?  Should there a be a static route put in to use the 172.16.100.X range as the GW for the LAN traffic on both sides?

The setup is pretty simple;

LAN A on RV230-1 uses 192.168.1.0/24 and LAN B RV320-2 uses 192.168.2.0/24.

Routing tables for RV320-2:

192.168.2.0	255.255.255.0	*	0	eth0
192.168.1.0	255.255.255.0	*	35	eth1
XXX.XX.XX.X	255.255.255.0	*	0	eth1
default	0.0.0.0	XXX.XX.XX.X	40	eth1

Routing table for RV320-1:

XXX.XXX.XX.XXX	255.255.255.128	*	0	eth1
192.168.2.0	255.255.255.0	XXX.XXX.XX.XXX	35	eth1
192.168.1.0	255.255.255.0	*	0	eth0
default	0.0.0.0	XXX.XXX.XX.XXX	40	eth1

Any ideas?  Thanks!

Tim

[SamirD]

What do you mean by 'use the virtual IP range of 172...'?"  What IP are you pinging from each side?

[taaronlee76]

172.16.100.X is the range (I'm assuming) that the RV320 uses for the virtual IP of the tunnel on each end.  Other than that, there are no other options for configuring the virtual IP. 

I'm ping from one RV320 to 192.168.1.1, and vice versa to 192.168.2.1.

I believe the issue is with the default route that the each RV320 assigns for the 192.168.X.X networks.  Instead of sending to the physical interface of the RV320, it is trying to send it to the DG of the RV320.

Here are some pics of the configs and routes.  Hopefully these will help.  Thanks!

Tim

[SamirD]

Okay, a couple of things.  One, is that 172.16.x.x is not being used anywhere, nor will it be with the way things are currently configured.  Two, is that both rv320s are behind other gateways which is a problem if they do not have public IP addresses.  Third, the routing tables don't need to be messed with since the vpn configuration handles all that.

The only thing I immediately saw in your vpn site configurations that could be causing problems is that one tunnel is defined by IP scope and the other by subnet.  Use one method or the other for both configurations.

A ping from 192.168.1.1 to 192.168.2.1 should work.  If not, something else is wrong.  If that works and a ping from one device on one side to another device on the other side does not, something is still not right in the subnet configuration somewhere.

[taaronlee76]

Samir,

Thanks for the response!  I figured out that the 172.16.X.X is only used when you go client to VPN.

Both side of the tunnel are using subnets 192.168.1.0/24 and 192.168.2.0/24 respectively.  I know the issue is routing, and once the tunnel comes up, both sides should be aware of what network is on each side... for some reason they don't exchange routes and the default route is to the internal network, versus the tunnel.

Any ideas on why the RV320 is doing this or how to fix it?  Even with a static route it I can't pass traffic through the tunnel.

Tim

[SamirD]

Are you able to ping 192.168.1.1 and 192.168.2.1 from each side?  What do you mean by 'don't exchange routes and default route is to the internal network'?

Why have you added a static route?  Don't add any additional routes--the vpn routes will be added automatically.

[taaronlee76 · Accepted solution]

Samir,

I cannot ping 192.168.1.1 or 192.168.2.1 from either side of the tunnel and vice versa.

This is the routing table on the RV320 at SiteA.  I thought for traffic to traverse the tunnel, the default route for 192.168.2.0/24 (SiteB) would be XXX.XXX.144.133, which is the physical interface (eth1) of the RV320 itself.  The XXX.XXX.144.133 IP is a public IP.  Like I said, the tunnel comes up just fine, I just can get routing work.

Does this help?  Thanks!

Tim

XXX.XXX.144.128	255.255.255.128	*	0	eth1
192.168.2.0	255.255.255.0	XXX.XXX.144.129	35	eth1
192.168.1.0	255.255.255.0	*	0	eth0
239.0.0.0	255.0.0.0	*	0	eth0
default	0.0.0.0	XXX.XXX.144.129	40	eth1

[taaronlee76]

Here is a copy of the VPN log, if that helps.

Tim

[ojuarez011]

Hi Taaronlee76!

Can you resolve your issue?

I have a similar problem with RV082 and RV042.

[SamirD]

The tunnel isn't up fine if you can't ping 192.168.1.1 and 192.168.2.1.  That's the first step to solving the problem.

Get rid of any of your static routes.  Clear the vpn settings and start over just creating the two vpn profiles and see if they connect and if you can ping across the tunnel.  This is the step at which we're stuck.

[DeclanJobs47]

Samir,

i encountered similar problem. I have successfully established a gateway to gateway VPN, and i can ping the routers on both side. But i cannot access any other server. How can the two ends be more like transparent to each other?

thank you

[imrshaik]

Did you get this resolved, if so how? 

I am seeing exactly the same issue, VPN seems up via the admin interface however can't seem to ping the default gateway at either side of the tunnel.

[bbrannan]

I realize that this is an old thread. I created a post with my own issues but have not had any replies on it yet. Did anyone ever get this resolved? If so, would you mind sharing what you did? I am having the exact same issues here and am unable to move forward with it. Frustrating to say the least! Thank you!

[vuduballs]

This problem is not "Solved".

I work for a company that has >100 of these routers deployed and I've been seeing this issue periodically for the ~3 years that I've been with them. And it's always the same. It can occur between two RV320s or it can occur between an RV320 and our pfsense router but the common denominator is the RV320. The issue never occurs with our customers that have Sophos or SonicWall routers. I've tried many VPN reconfigurations and can even delete and completely rebuild the VPNs on a router and the issue persists: the VPN shows as 'Connected' but I can't even ping from router to router.

But I've found that I can almost always get the VPN up and running again by turning off both modem and router, leaving them off for at least 30 seconds, and turning them both on again at the same time. Sometimes I have to do this a few times, which doesn't make sense, but I'm not entirely sure that my client is following my instructions and leaving it off for a full 30 seconds or more. I deal with this issue almost weekly for some RV320 or another but the interesting thing is that it tends to occur only at specific sites, almost as if the RV320 isn't cooperating properly with either the ISP or their modem. I probably only have 3 or 4 customers who this occurs for out of the >100 sites that we have them deployed at, but even after replacing the RV320, the new router will inevitably exhibit the same issue somewhere down the road, though it may work flawlessly for months at a time. This suggests that the issue is not in any way a hardware failure.

I don't know if it's the power-cycling of the modem that's fixing it or if it's the RV320 but this is the fix that I found for it and I haven't wanted to cause the excess downtime for my customers that would be required to determine that.