IPSec through NAT

[deeno]

Here’s my situation:

We are trying to make it possible for traveling employees to access the office LAN through VPN. The VPN device at the office that we are using is a Linksys RV082. Installed on the laptops of the traveling employees is “TheGreenBow VPN Client.”

Everything works surprising well unless one of the traveling employees is behind NAT. This is a problem since the most of the places they go use NAT.

[LAN]==[RV082 VPN Server]==[Internet]==[NAT]==[Remote Employee]

When a VPN connection is attempted by a traveling employee that is behind NAT, the following error is generated on the RV082 log:

Cannot respond to IPsec SA request because no connection is known for 10.1.1.0/24===24.X.X.X[secret]...209.X.X.X[secret]===10.1.3.1/32

Any thoughts on this would be very helpful. I am not sure whether a configuration is needed on the RV082 at the home office, or whether something is needed in the configuration of the client software.

Thanks,

deeno

 

[AlexIT]

I have never seen this travelling widely on my own. If your client is set to "IPAddr" in the shared key encryption then I could understand this, what key settings are you using?

In most cases the VPN "follows" the traffic so if the remote user can ping your public ip then they should be able to VPN.

Is this right for your problem:
CorpLan - RV082 - public Ip - public Ip - unknownLan - RemoteUser

Your remote user is getting assigned an Ip on the unknownLan and now their VPN doesn't connect?

Alex

 

[deeno]

Alex,

Yes, your diagram is correct for the problem we're having.

The interesting thing is that a remote employee (I'm actually on the road right now) can connect to the web setup page of the RV082. If pinging were allowed through the firewall, a ping would work as well.

Another interesting thing is that the Phase 1 of the IPSec goes through without a problem. There is no error until Phase 2, which is when the "Cannot respond to IPSec SA request..." error happens. This error is generated on the CorpLan side (RV082).

The client isn't set to IPAddr in the shared key encryption. If this is the same thing that I think you're talking about, we are using "USER FQDN" for that setting. The information in that section should be correct since a tunnel can be established when the remote employee (myself, for now) connects directly to the internet (bypassing the router/firewall).

I used google to look up the error message I'm getting, but the majority of the results are dealing with FreeS/WAN and have been unhelpful in resolving this for our setup.

Thanks again. Any advice would be helpful,

deeno

 

[AlexIT]

Ipsec SA is secure authorization, so you are connecting but not able to answer the shared key request. There is a setting somewhere that expects your remote machine to have IP address in a range other than what you have. Check the RV082 for something like:

LAN IP = your.corp.lan.range
WAN IP = your.public.ip.addr
Remote IP = fixed.range.ip.addr

I am not familiar with the RV082 so I am shooting in the dark here, but Netgear requires an IP range that is permitted to VPN...try 0.0.0.0 (for any IP address.)

Alex

 

[deeno]

Alex

I went through the RV082 VPN setup and it appears to be correct. I have to believe that it is correct since the connection works when the remote client isn’t behind a NAT device. In other words, if I plug directly into my cable modem or DSL line, the connection succeeds.

There is an option like you mentioned that will accept incoming connections from a specific IP address. However, since the IP address of a traveling employee changes often, I have chosen to accept a connection from a dynamic IP address. With this option, you must provide some other means to authenticate the user. I am using the [USER FQDN] option for this, where the VPN server and the VPN client have an email address entered. When a connection is attempted, the values are checked against each other. If there is a discrepancy between the values, it is my understanding that Phase 1 will not complete. (I could be wrong, this is just my understanding of how this works)

So, I’m almost positive it is a result of the client going through a NAT device. I just don’t know why there is a problem.

Thanks for the ideas. Be sure to let me know if you have any more. In the mean time I’ll keep fiddling with this and will let you and everyone know what I come up with, if anything

deeno

 

[chicocouk]

There is a problem because IpSec uses ESP, which is a portless protocol. NAT in the sense you're describing it is probably PAT (port address translation). In this case the NAT device keeps a table (on a cisco device this is called an xlate table) which maps internal port numbers and ip addresses to external ips and port numbers. So the NAT device knows to route traffic from a certain ip and port back to it's source properly. This is how NAT generally works when devices "share" a public ip address (or range of public addresses). The problem is that because ESP (protocol 50) doesn't have ports, the NAT table has no way to correctly list where it came from. Some NAT devices get around this with a feature called IpSec pass-through, where the first device to initiate an ipsec tunnel from behind the nat device is noted in the table, then any ESP traffic is routed back to them. This falls over when there are more than one device trying to create ipsec tunnels from behind the NAT device, as the second tunnel will not work, the ESP traffic will be routed back to the first host.

Enough theory, how do you get around this? An emerging standard called NAT-t is being ratified, or perhaps already is, not been keeping up to date, and using that ESP traffic is encapsulated under UDP port 4500. So it PATs through the NAT device no problem.

For this to work both sides of the vpn tunnel must support NAT-T. Check with Linksys support if their RV028 device supports NAT-t, if so find out how to turn it on. Also check for a setting on the VPN client software to enable it, or if there isn't one, ask if there is a newer version of the client.

Otherwise, it simply won't work.

Chico

 

[deeno]

Chico,

Thanks for the great information! I still haven't been able to get this working, but I'm going to do a little more research on the NAT-T that you're talking about. Since the RV082 has the IPSec Pass Through option, and since the NAT device (at home) has the IPSec Pass Through option, I'm doubting that I'll find anything relating to these products.

Thanks for the info...