cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Welcome to the Cisco Small Business Community

Have a question? Click on a topic board below to get started in the community.
Get the latest news in this issue of the Cisco Small Business Monthly Newsletter

3370
Views
5
Helpful
13
Replies
Highlighted
Beginner

RV320 to RV320 (GW to GW VPN)

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.0255.255.255.0*0eth0 
192.168.1.0255.255.255.0*35eth1 
XXX.XX.XX.X255.255.255.0*0eth1 
default0.0.0.0XXX.XX.XX.X40eth1

 

Routing table for RV320-1:

XXX.XXX.XX.XXX255.255.255.128*0eth1 
192.168.2.0255.255.255.0XXX.XXX.XX.XXX35eth1 
192.168.1.0255.255.255.0*0eth0 
default0.0.0.0XXX.XXX.XX.XXX40eth1

 

Any ideas?  Thanks!

Tim

 

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

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.128255.255.255.128*0eth1 
192.168.2.0255.255.255.0XXX.XXX.144.12935eth1 
192.168.1.0255.255.255.0*0eth0 
239.0.0.0255.0.0.0*0eth0 
default0.0.0.0XXX.XXX.144.12940eth1

 

 

    

View solution in original post

13 REPLIES 13
Highlighted
Contributor

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

Huntsville's Premiere Car and Bike e-magazine: www.huntsvillecarscene.com
Highlighted

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

 

Highlighted

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.

Huntsville's Premiere Car and Bike e-magazine: www.huntsvillecarscene.com
Highlighted

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

Highlighted

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.

Huntsville's Premiere Car and Bike e-magazine: www.huntsvillecarscene.com
Highlighted

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.128255.255.255.128*0eth1 
192.168.2.0255.255.255.0XXX.XXX.144.12935eth1 
192.168.1.0255.255.255.0*0eth0 
239.0.0.0255.0.0.0*0eth0 
default0.0.0.0XXX.XXX.144.12940eth1

 

 

    

View solution in original post

Highlighted

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

Tim

Highlighted

Hi Taaronlee76!

Can you resolve your issue?

I have a similar problem with RV082 and RV042.

Highlighted

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.

Huntsville's Premiere Car and Bike e-magazine: www.huntsvillecarscene.com
Highlighted

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

Highlighted

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.

Highlighted

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!

Highlighted
Beginner

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.