Improve company productivity with a Business Account.Sign Up


RV042 to RV042 VPN with a NAT firewall on one side.

Posted on 2014-04-24
Medium Priority
Last Modified: 2014-05-05
Somewhere in the dim past I did this and it worked but I've lost the formula it appears.

There was a paper about connecting RV042s site to site.  It said that you can have ONE NATting router in front but not one at each end.  And I got that system working.

I need to do the same thing again and can't find those instructions.  
I've done everything that seems to make sense but the VPN won't connect.
In this case I have this arrangement:

RV042#1..VPN w/public address (dyndns supported) <> cable modem <> internet

internet <> RV042#2 "firewall"  w/public address <> interim private subnet <> RV042#3..VPN with private addresses.

So, RV042#1 and RV042#3 are the VPN terminating devices.
And, RV042#2 is an intervening firewall (only) with IPSEC passthrough at one end in front of the VPN terminator.

I'm getting logs that say:
"We require peer to have ID "[public ip at RV042#2], but peer declares "[private IP at RV042#3]

Obviously, I think, the #1 device has to point to the public address of the #2 device because I don't see any other way to get there from here.
I have to believe that the problem is right there but I can't figure out how to fix it.
Question by:Fred Marshall
  • 7
  • 6
  • 5
LVL 102

Expert Comment

ID: 40021745
I have an RV042G connected to an RV086 and to some Juniper Netscreen boxes.

Here are some settings that work.

You need a Gateway to Gateway setup
Provide a tunnel number
Use WAN1

For the local group settings:
IP Only
Provide the external IP
Security: Subnet
IP: 192.168.1.x or whatever internal
Subnet Mask

For the remote group settings:
IP Only
Prove the remote external IP
Security: Subnet
IP: 192.168.2.x or whatever at the other end
Subnet Mask

IP Sec Setup
IKE Pre-Share
Phase 1 DH: Group 2
Phase 1 Encryption: DES or 3DES
Phase 1 Authentication: SHA1
Phase 1 Life: 28800 sec

PFS: not enabled

Phase 2 DH: Group 2
Phase 2 Encrypt: DES or 3DES (as above)
Phase 2 Authentication: SHA1
Phase 2 Life: 3600 Sec

Pre-shared key:  provide it.

Aggressive: no
Compress: no
Keep Alive: yes
AH Hash: no
Net Bios: no
NAT Traversal: Yes (maybe No, not at both ends, test for what works)
Dead Peer Detect: Yes
LVL 27

Author Comment

by:Fred Marshall
ID: 40022715
John Hurst:  Thanks for the response.  Yes indeed, this is the sort of thing that's set up and I've done this much a number of times before.  But, as I pointed out, RV042#2 is a NATting router in between the two VPN terminations (#1 and #3) .. so that complicates things somewhat.

I'm interested in the trades between Aggressive yes/no and NAT Traversal yes/no but those are easy to play with.  (I have access to both devices in real time).
From the RV042 HELP, it appears that I need NAT Traversal enabled:

"NAT Traversal: Check the box to enable NAT-Traversal protocol. Both IPSec initiator and responder must support the mechanism for detecting the NAT Router in the path and changing to new port defined in RFC 3947."

Perhaps related to this, one thing that concerns me is:
RV042#1 has a public address on WAN1.
RV042#2 has a public address on the WAN1 but is to be a passthrough device.
RV042#3 has a private address on WAN1 and is to be the VPN termination with #1.
So, how is the routing supposed to work at that site?
I have the public addresses entered as the Remote Gateway in each case.
And, I have the inside subnets as the Remote Group (and Local Group) in each case as usual.
How does #2 know to pass VPN traffic to #3?
(I have seen log messages at #1 that complain that stuff is coming back from the public address of #2 when it should be from the private WAN address of #3.)
It's been so long that I've done this configuration of routers (with an interim NAT) that I don't recall how they were set up.  Is there something I'm leaving out?

There was a guide (from Linksys or Cisco I believe) that I used back then that said this would work with an interim router up front at ONE END ONLY.  So that's how it worked then and is supposed to be working here.  I was using RV042s back then as well.  I sure wish I could find that guide now!
LVL 102

Expert Comment

ID: 40022876
I do not put routers in between my two VPN routers because it complicates things.

The variable that affects this is NAT Traversal (and this is true with client VPN applications and double NAT setups).

Aggressive Mode is part of the IPsec setup and does not affect NAT Traversal - the two are separate.

The pass through Router #2 should have no VPN setup.

Router # 3 must have a public IP address on WAN1. That may be why you are not getting connected.

Then try NAT Traversal only on end to test to get through the pass through router.

I connect VPN to VPN to make things as easy as possible in a difficult situation.
The IT Degree for Career Advancement

Earn your B.S. in Network Operations and Security and become a network and IT security expert. This WGU degree program curriculum was designed with tech-savvy, self-motivated students in mind – allowing you to use your technical expertise, to address real-world business problems.

LVL 102

Expert Comment

ID: 40022913
What you might try is using VPN on router 2.

So I have:

Router 1:  Various Clients all with static IP addresses and VPN routers.

Router 2:  My home office RV042G VPN router, dynamic external IP (bad practice), and site to site tunnels.

Router 3: My home office Cisco wireless router.

Machines on wireless can readily use the site to site tunnels.
LVL 27

Author Comment

by:Fred Marshall
ID: 40023466
I'm doing it this way because it's a *requirement*....
LVL 102

Expert Comment

ID: 40023473
Fair enough. But I do not think you can connect Router 1 to Router 3 by VPN where Router 3 has a private IP address. I am fairly sure this is why it does not connect.
LVL 27

Author Comment

by:Fred Marshall
ID: 40023759
Well, I tried to convey at the beginning that I've already done this successfully but can't find the guide that I used at the time.  So it *can* be done.  The question is "how?".
LVL 72

Expert Comment

ID: 40030081
John is not correct about the public IP stuff. You need a different subnet on the WAN interface, that is the "only" requirement.

If #3 is initiating traffic, you don't need IPSec Passthru, as NAT-T will manage that.
If #1 is initiating traffic, you need IPSec Passthru.

In both cases you will have to supply the #2 public IP in the local VPN properties of #3 instead of the interim subnet IP or internal private IP. And that is an requirement only for Aggressive Mode, but I don't know whether Main Mode on RV works with dynamic IP.
LVL 27

Author Comment

by:Fred Marshall
ID: 40030560
Qlemo: Thank you.
I would have said:
You need a different subnets on the LAN interfaces.  Maybe a typo?
The other requirements have to do with the settings.

I do have this working now and intend to write something about it as I've still not found that old Linksys/Cisco (I think it was) paper that told how to do this and included the warning that you can only have a NAT router in front of ONE end of the VPN chain.  I would dearly love to find that reference again.  (HELP!)  Otherwise, my understanding of modern devices is that one might normally expect to have NAT routers at both ends of the tunnel path.

So, to continue the discussion and learning process:

I don't want to know or try to control which end initiates traffic.  I want them to simply connect using symmetrical configurations.  That's much simpler.  But I do acknowledge that IF one were to specify which end initiates traffic then some settings might be different one side to the other.  I don't recommend that.  This is, after all, a site-to-site VPN - unlike a client-to-site VPN.

With the RV042, you cannot enter the WAN address in the VPN setup it fills automatically to the device WAN address.  So, you can't enter the local public address there - it will be what it is.  If the WAN address is private (as in the case of #3) then that's what the local VPN outside address will be.  I was worried about that a LOT.  But I think I'm beginning to understand how that works.

Also, in this case at least some of the time, I was using Dynamic DNS addresses for the public addresses.
While I was using static public addresses in the VPN setups, I had not yet gotten the VPN to connect.
But, I can't prove that switching to DynDNS made a difference in that regard.
Maybe THAT's a requirement for #3's VPN setup but I've not confirmed that.
Dynamic DNS requires Aggressive mode in the VPN setup.

Here is an outline of what worked:
Aggressive mode.
NAT Traversal.
Keep alive.
Everything else was symmetrical / normal VPN settings.

I believe this to be important:
The intervening RV042#2 "firewall" was set:
Open Port 500 incoming from the remote VPN public address
Open Port 4500 incoming from the remote VPN public address

VPN Passthrough enabled

Port forwards:
UDP 500 to the VPN#3 WAN private IP
TCP 443 to the VPN#3 WAN private IP (I have no reason to believe this is necessary)
UDP 4500 WAS NOT on the list / not forwarded to VPN#3 WAN private IP

Some of these settings may be unnecessary.
For example, I'm not sure what VPN passthrough does and whether the firewall needed to be opened in addition.  
BUT, I am rather sure that the Port 500 forward to the specific private IP address WAS necessary.

One of the pressing questions I have at this point is:
"What, by definition, does "VPN Passthrough" for IPSEC actually do?
I get the impression that it's sort of a firewall/port forward set of rules.  But just try to find those rules anywhere!!
I have read that it's only necessary to be set on the sending end but that doesn't make sense to me yet.  It seems a bit out of context.
LVL 72

Expert Comment

ID: 40030873
I would have said:
You need a different subnets on the LAN interfaces.  Maybe a typo?

No typo. You are correct in regard of the end-to-end traffic, which is passed inside the VPN tunnel - those LANs need to be different.
But what I wanted to say is that "outside" and "inside" addresses of a NAT router need to be disjunct. So WAN and LAN IPs have to be from different subnets.
LVL 72

Expert Comment

ID: 40030890
Regarding VPN Passthru, again I don't know for RV type routers, but usually you have to set up a single private IP address for that, which has to point to your VPN gateway. And it enables firewall rules to allow VPN related traffic (both inbound and outbound). So, indeed, it is both firewall setup and port forwarding, as you assumed correctly.
The firewall aspect applies to both initiator and responder. The passthru/port forwarding is only necessary for "unsolicited" incoming traffic, i.e. the responder.

Port 4500/udp does not need to be forwarded, as the the NAT-T device (VPN #3) initiates that after both partners negotiated NAT-T.
Port 443/tcp is not related to IPSec VPN - it is for SSL/TLS, needed for HTTPS or SSL VPNs.
LVL 102

Expert Comment

ID: 40030905
With the RV042, you cannot enter the WAN address in the VPN setup it fills automatically to the device WAN address.  So, you can't enter the local public address there - it will be what it is.

That is the way my own RV042 works for site to site, which is why I had originally suggested an external IP. I know that is not what you need.

Internal (local and remote) subnets, however, can be set up differently from each other.
LVL 72

Expert Comment

ID: 40030923

as I read it, the issue is with the Aggressive Mode - Local ID negotiation in Phase 1, used to identify the remote end. We both know (at least I do) that setting that Local ID isn't an issue at all with Juniper ScreenOS :D. But those Linksys type of routers, ...
LVL 72

Expert Comment

ID: 40030933

Are you able to omit the identification part ("IP only", "Provide the external IP") on #3, or replace it with something you can set up manually? EMail addresses, DNS names, subnets are common IDs.
LVL 102

Expert Comment

ID: 40030937
Juniper boxes are much more flexible and I have not used Cisco Linksys RV042 / RV082 / RV016 in pass through.
LVL 27

Author Comment

by:Fred Marshall
ID: 40031106
Heh.  I've also been using Juniper boxes. First Screen OS SSG-5s and now a Junos SRX240H2.  They seem to be good machines once one has figured out how they have things layered/structured.  The RV0xx series is much simpler and has bee a great workhorse for me - even with its limitations and quirks.  

In this case I've been confronted with the need to stick an existing 3rd party VPN box behind a firewall.  Up to now it worked fine with its own public IP address.  But, this is to be no longer.  I started trying to run it through the SRX into a new VLAN and on to the existing LAN but that became a bit daunting for a near-term solution.  I was able to add the new VLAN but now I'm wading through the security policies necessary.  And, since I'm a great believer in partitioning things, I figured that I could simply plug in a familiar RV042 as the needed firewall and be done with it.  But, I didn't remember how to do a VPN behind a NAT box.  Well, that's done now and I'm wanting to be smarter about it moving forward.

I could also stick one of the now-unused SSG-5s in the VPN firewall role but that's yet another learning experience that I have very little opportunity to leverage.  So I don't know that I want to go there....  I have set up VPNs with the SSG-5 but not lately and not often.  I'm happy to learn but put my time toward learning that looks like it will have more payoff rather than less.  Of course, sometimes that's hard to know.

Back to my current question:
What does VPN Passthrough do (in a technical sense).  Not how to do it, that's easy. But, what does it do in terms we've now started discussing?

I did know about port 443 but the setting was there at the time so I recorded it just for completeness.

My assumption is that VPN Passthrough is a more or less standard set of features.
What's in the black box?
Forward ports 500 and 4500?
Open the firewall for ports 500 and 4500 as well?
What about protocols 50 and 51?  Are they embedded in packets directed to port 4500?
I'd like to write it all down in a rather definitive way .. even if not all mfr's meet the same list.  It remains murky.
LVL 102

Assisted Solution

John earned 800 total points
ID: 40031123
In the RV042, in the web interface, you can look at Firewall, Access Rules, and under ADD, there is service management where you can define ports.  If Firewall is Enabled (and it should be) the access rules may allow the traffic you want to pass through, but I do not know for sure.
LVL 72

Accepted Solution

Qlemo earned 1200 total points
ID: 40031624
I've answered the "What is VPN Passthru technically" already in http:#a40030890.

You can't tell exactly in general what ports and protocols are permitted and forwarded, as each device defines a different set of services for VPN. Most include PPTP/GRE (= 1723/tcp & protocol 47), L2TP/IPSec (1701/udp & 500/udp), IPSec.

AH and ESP do not need to be forwarded/allowed, as they are embedded into the IPSec packets. There is a lot of confusion about ports and protocols in discussion threads, and which one to forward or not - it doesn't harm if a protocol is forwarded unnecessarily though.

Featured Post

The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

A new hacking trick has emerged leveraging your own helpdesk or support ticketing tools as an easy way to distribute malware.
This article is about building a site to site VPN tunnels in Cisco CSR1000V router with IOS XE. There are two Policy Based IPsec VPN tunnels configured on CSR1000V router one with NAT and another without NAT.
We’ve all felt that sense of false security before—locking down external access to a database or component and feeling like we’ve done all we need to do to secure company data. But that feeling is fleeting. Attacks these days can happen in many w…
When cloud platforms entered the scene, users and companies jumped on board to take advantage of the many benefits, like the ability to work and connect with company information from various locations. What many didn't foresee was the increased risk…

579 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question