• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1323
  • Last Modified:

Can't communicate through a VPN tunnel between 2 LinkSys RV042

This has been a long and harrowing journey.  It started off with trying to connect an RV4042 to a WRV54G, but I was having so much trouble getting that to work that I gave up and went out and bought another RV042, figuring that the same hardware on both ends should simplify matters.

Fat chance.

So here's what I'm trying to do for testing purposes:

WRK1 --- VPN1 --- SWITCH --- VPN2 --- WRK2

VPN1 Settings:
WAN IP: 214.213.212.1, 255.255.255.0
LAN IP: 192.168.1.1, 255.255.255.0
DHCP'ing: 192.168.1.100-149, 255.255.255.0

VPN2 Settings:
WAN IP: 214.213.212.2, 255.255.255.0
LAN IP: 10.4.132.1, 255.255.255.0
DHCP'ing: 10.4.132.100-149, 255.255.255.0

The VPN settings on each are set to point to the other VPN as the Secure Gateway and the other range as the Remote Group (inclusive of the entire range).  Changing NO OTHER SETTINGS from the factory default, I press the "connect" button on the VPN Summary page and it says it's connected.  Fine so far.

I try from the Diagnostics page on each device to ping the other device.  I get no responses from the other device.  I disable "Block WAN Request" on each side and I get responses from the WAN IP on each device, but not the LAN IP.  Running ping from each workstation produces similar results: I'm able to ping the WAN address of each device, and the LAN address of the local device, but nothing in the other LAN.

As part of my test setup the Default Gateway for each machine is set to 214.213.212.99...meaningless, I believe, since they're both on the same network.  If I change the Default Gateway for each to point to the WAN address of the other device then I'm able to ping, map drives, etc, etc, but I realize that this is just ordinary IP traffic that's not being blocked by the normal private-IP-router-blockage because the devices aren't in router mode they're in gateway mode; at any rate, it's not going through the VPN tunnel, because disconnecting the VPN tunnel has no affect on this.

WHAT AM I MISSING?  I've contacted LinkSys tech support, who are absolutely no help.  (They actually tried to tell me that the devices had to be connected to the Internet, for some unspecified reason.  I tried putting one of them at a friend's house, no difference...able to connect the tunnel, unable to communicate through the tunnel.)  I've checked, double-checked, and re-double-checked the settings on each device.  I'm pulling my hair out.  This is supposed to be consumer-level technology, and I, with my gigantic brain and 15-plus years of networking experience can't get it to work, so I presume there is something painfully simple that I'm overlooking.  TIA
0
bozcrow
Asked:
bozcrow
  • 6
  • 5
  • 2
2 Solutions
 
Rob WilliamsCommented:
Very odd. If you have configured identically, except reversing remote and local groups, it should be straight forward. A few points:
-when configuring remote and local security groups use subnet rather than range. I have had problems with the latter
-are you sure they are connected? the "button" actually displays Disconnect when they are connected. The idea being you can disconnect the session. When it says Connect the VPN is not established
-any chance the first RV042 is defective. I have heard of that a couple of times, and the fact that you couldn't connect to the WRV54G either, might indicate a problem. I would recommend updating the firmware, or if you have already done that, re-install the same version, at least on the first RV042. You could also try, as a test, connecting to each router with the Linksys QuickVPN client.
-When testing, a good first test is to try pinging the LAN side of the remote router. Seems you have tried this, but it just avoids any problems, should they exist, with the remote network or software firewalls.
0
 
bozcrowAuthor Commented:
Yeah, I've reloaded firmware, I'm using subnets, and I'm sure they're connected (the "Disconnect" button appears).  I've also tried connecting with the QuickVPN client to each, with no problem.

Last night I tried manually setting the MTU to 1400.  No change.

Should this test setup work, both devices connected to a switch with a non-existent default gateway entered?  I was looking at the routing table on each device, and for some reason the Gateway for the VPN Tunnel traffic seems to get set to the Default Gateway, which seems peculiar to me.  I also noticed that one isn't able to force a path through the VPN interface.
0
 
Rob WilliamsCommented:
Very odd.
MTU should not be an issue where you are connected via a switch.
As for your scenario, with the switch, I have ever tried it but it should work. I would be tempted to leave the gateways empty, but it shouldn't matter where the gateway is only used when the packets are destined for a different subnet. Both of yours are on the same 214.213...

Any chance you can post a screen shot of the VPN configuration of one of the units? (block out part of any public IP's and security keys)
0
A Cyber Security RX to Protect Your Organization

Join us on December 13th for a webinar to learn how medical providers can defend against malware with a cyber security "Rx" that supports a healthy technology adoption plan for every healthcare organization.

 
bozcrowAuthor Commented:
[quote]I would be tempted to leave the gateways empty, but it shouldn't matter where the gateway is only used when the packets are destined for a different subnet.[/quote]

The RV042 firmware won't allow you to leave the gateways empty.  And, that's what I'd think, too, but it seems that the "automatic" entry that's made in the routing table when you connect the VPN points packets for the other LAN to the default gateway!  I would expect them to get directed to the unit itself, and then the VPN firmware to take over from there.

This is unbelievably frustrating and convoluted, it seems to me, given how simple it's supposed to be.
0
 
Rob WilliamsCommented:
Didn't realize that with the gateways, but then again I haven't tried.
Are you able to post a screenshot?
0
 
lrmooreCommented:
>both devices connected to a switch with a non-existent default gateway entered?
It makes all the difference in the world.
On RV042 #1, put RV042 #2's IP as the DG and #1's IP as #2's DG

0
 
bozcrowAuthor Commented:
>>both devices connected to a switch with a non-existent default gateway entered?
>It makes all the difference in the world.
>On RV042 #1, put RV042 #2's IP as the DG and #1's IP as #2's DG

Ok, if I do that it works fine, but that brings up 2 questions:

1. How do I know that the traffic is being carried through the VPN tunnel?  In fact, when I have it configured that way and I manually disconnect the tunnel, I'm still able to ping, map drives, etc, which makes me think the traffic ISN'T going through the tunnel.

2. How is this impacted when I set the whole thing up on the Internet and I have an actual DG?
0
 
lrmooreCommented:
Question 1 will be answered easily enough when you put them on the Internet and there is absolutely no other path between the two private IP subnets.

>I manually disconnect the tunnel, I'm still able to ping, map drives, etc, which makes me think the traffic ISN'T going through the tunnel.
This would lead me to question the physical setup of your test lab.

Switch  ---- R1LAN--R1WAN----switch----R2WAN--R2LAN---- switch
   |                                                                                      |
 Test PC                                                                          Test PC
192.168.1.x                                                                     10.4.132.x

Did you enable the VPN tunnel, or VPN Gateway? Only need Tunnel, leave Gateway disabled.
Remote Secure Gateway = Public WAN IP of remote router?

0
 
bozcrowAuthor Commented:
That's it, only the tunnel is enabled, and the RSG = Public WAN opposite.

Since the RV's are operating in Gateway rather than Router mode, would they stop private IP traffic?  i.e. If the DG for each is the other, if presented with a packet destined for an "unknown" subnet (the LAN on the other side) wouldn't each just forward the traffic on to the DG, which would recognize a LAN-side address for itself and forward it on?
0
 
bozcrowAuthor Commented:
Ok, further information available!

I checked it out again this morning...turns out I wasn't giving the smartware enough credit.  When I disconnected the tunnel by pressing the disconnect button, it was automatically reconnecting itself when the router detected traffic for the remote LAN.  If I disabled the tunnel and tried to ping, with the routers pointing at each other for DG, everything timed out.  As soon as I enabled the tunnel, and tried the ping, the routers connected to each other and everything was fine.

So, now I need to try it connected to the Internet.  I'll check back in.

Oh, and RobWill: I have a graphic of the setup (which seems kind of moot, now), but can't figure out how to post it.  Is there a way to attach it to my post, or do I just need to host it and post a link?
0
 
Rob WilliamsCommented:
Sounds good.
Looks like you probably don't need to post the screen shot, but if you would like to, you need to upload somewhere else, and place a pointer here. You cannot add attachments of any sort on Experts-Exchange. If you need a place to put it you can use:
  ftp://test1.dnsalias.net/
This temporary site I was playing with this morning. Will not likely exist more than 24 hours and zero security but feel free.
--Rob
0
 
bozcrowAuthor Commented:
Ok, got it working between the two RV042's, on the Internet.  Once I tried it with the matching hardware, it worked like a charm.

So, now I just need to figure out how to make the RV042 work with the WRV54G...a separate issue.

Thanks for the help.
0
 
Rob WilliamsCommented:
Thanks bozcrow. Glad to hear.
RV042 <==> WRV54G is almost identical, you shouldn't have any problem.
--Rob
0

Featured Post

What Security Threats Are We Predicting for 2018?

Cryptocurrency, IoT botnets, MFA, and more! Hackers are already planning their next big attacks for 2018. Learn what you might face, and how to defend against it with our 2018 security predictions.

  • 6
  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now