Cisco RV042 gateway to gateway - routers not even trying to connect?

hardware_failure

hardware_failure

[H]ard|Gawd
Joined
Mar 21, 2008
Messages
1,370
I have 2 RV042's in a lab that Im trying to get a gateway to gateway tunnel setup.

I have 2x comcast connections in the lab for testing, each with static IP's.

Ive set these up before with no problem.

The setup is very simple. Ive gone over it practically 100 times.

At this point its just stuck at waiting for connection.

Heres the stange part:

The VPN logs in both devices are EMPTY. Its like they are not even trying. In the past when I have set these up, it took a few minutes to get everything working perfectly, but the VPN logs were full with all kinds of stuff. (long before I got the tunnel to connect)

Is this normal?

I made sure that the "disable firewall for true static ip subnet only" is checked on both comcast gateways and tested opening a few ports in access rules, and traffic passes fine.

:edit: I know it looks like the public IP's might be the same but they are not. The static blocks are very close to each other but they are different. In fact the first 3 octets are the same. Would that be a possible issue? :edit:

Beating my head on the wall on this one.:banghead:







 
I've had that before setting up a tunnel between a customer's RV082 and their customer who I think had Cisco equipment on their side.
Was replacing a D-Link router with the RV082 at the time (tunnel was up on the D-Link). Now I'm replacing the RV082 with a ERL3 but that's another story.

First of all, re-power everything including the Comcast modems. Don't know why that made a difference one time but it did.
Second, even if the tunnel is down, try doing something like RDP from one side to the other. It may need to see "interesting traffic" to establish the tunnel.

The other thing is to go over the firewall rules... I don't remember if I had to do rules to allow one subnet to the other or not.
I can check the config later tonight remotely to see what the rules are if you need me to.

Make sure no typos in IPs or the key.

ETA: Turn off key complexity and try with a very simple key until you get it working.
I chased my tail for a long time figuring out the Cisco Quick VPN won't work with a "#"
in the password. The PPTP works fine with that character though.

It might be choking on a special character.

.
 
Last edited:
You may need rules to allow IKE and the IPSEC suite too.

I'm not remembering if the RV series routers do those rules for you automatically or not.
Like I said, let me know and I'll check the rules on that router if needed.

ETA: Just checked it for the fun of it.... no manual rules for that tunnel at all.

The only thing I have is forwarding to an internal PPTP server for a few users but nothing
related to the IPSEC tunnel or traffic.

Tunnel is up and works great, they use it every day.

ETA#2: I have Aggressive & Perfect Forward off and NAT Traversal on.

ETA(yet again):

>>In fact the first 3 octets are the same. Would that be a possible issue?

I'm thinking yes, that could very well be the problem. That would put the WAN side of both
routers on the same subnet correct? You could try changing the mask to 255.255.255.252
but not sure that would fix it. Try taking one of the routers to a different location with more
unique WAN side IP and see if it will work. (Turn on remote admin)

You could always try using your own WAN side IPs across a switch for testing too.

.
 
Last edited:
I'm guessing this is just for the fun of it or to teach someone? The RV042 is a really old product, and you may as well send your data in clear text if your encryption is using DES and MD5.
 
bman212121 said:
I'm guessing this is just for the fun of it or to teach someone? The RV042 is a really old product, and you may as well send your data in clear text if your encryption is using DES and MD5.
Click to expand...

While technically true that it may be running low end encryption by today's standards, wouldn't it require physical on site
access to one end of the VPN connection to attempt to compromise the security?

If you have physical access, then you have access to unencrypted data anyway.

You can setup any scenario you want to in a lab and show it's not secure in some way. But in real life, it's not really very
practical for a bad guy to actually be able to use most theoretical VPN security flaws.

Social engineering and guessing wireless keys are way more profitable for a bad guy than trying to hack a VPN.

.
 
Spartacus said:
>>In fact the first 3 octets are the same. Would that be a possible issue?

I'm thinking yes, that could very well be the problem. That would put the WAN side of both
routers on the same subnet correct? You could try changing the mask to 255.255.255.252
but not sure that would fix it. Try taking one of the routers to a different location with more
unique WAN side IP and see if it will work. (Turn on remote admin)
Click to expand...

This is my next step, will try it tonight. Thanks.
 
I got it working after updating their firmwares.

I guess thats a simple thing I should have tried earlier, but it was never an issue before.

I dont like to update firmware/bios unless absolutely necessary. And, low and behold, the 2nd one actually bricked after the firmware update. I had to use a "firmware rescue recovery" tool to unbrick it, it took it fine after that.

Finicky little things. There not even a cisco product, just rebadged linksys

Thank you for all of the help.
 
Cool, glad you got it going.

Yep, it's good to stay current on the router firmware.
Nice job getting it un-bricked!

.
 
Spartacus said:
While technically true that it may be running low end encryption by today's standards, wouldn't it require physical on site
access to one end of the VPN connection to attempt to compromise the security?
Click to expand...

Nope, you'd just need to be able to capture the packets anywhere in the path from A to B. If you needed physical access to get at the data, then there wouldn't be a point in running the VPN at all.
 
bman212121 said:
Nope, you'd just need to be able to capture the packets anywhere in the path from A to B. If you needed physical access to get at the data, then there wouldn't be a point in running the VPN at all.
Click to expand...

Ok, so they'd have to somehow capture a packet stream, decrypt their captured encrypted data (taking who knows how long), and then somehow make use of what is probably RDS data or something pointless.
I'm not going to stay awake at night worrying about that.

.
 
You must log in or register to reply here.
Back
Top