|
Originally Posted by wooch
|
|
We had to enable IPSec NAT Traversal (Port 10001) on our Contivity servers due to NAT Router connection issues. So, it appears that this NAT issues can occur with IPSec. Also, I believe XP SP2's IPv6 improved VPN connections from behind NAT routers. What are your thoughts on this DL?
|
All VPN concentrators call these terms something slightly different. There is first what I prefer to call pure IPSec. This sends and outbound UDP 500 and the concentrator replies back with either IP protocal 50 or 51.
For this to work through NAT, the device needs to support IPSec pass through. If you are using a version of NAT called PAT (Port Address Translation), then there is still another issue. If two or more clients tried to connect to the same concentrator via the same router, then there is a problem. The device doing the address translation can not tell the streams apart. We got this all the time when several people from our company all attended the same conference and stayed in the same hotel.
The next version I like to call IPSec via TCP port 10000 for Cisco. It looks like Contivity uses port 10001. This fixed two problem. First if the device doing NAT was old and did not support IPsec pass through, then this option would get around it. It also gets around the more that one user problem, because it will create data streams the NAT device can tell apart.
The last version I like to call IPSec via L2TP which is what Microsoft VPN does. Even with Contivity, they make there own client that most people use. The problem with L2TP is the same problem you can run into with several applications when you go through NAT, the source IP address is included in the packet. For most things, this is not a problem. As an example, if you are behind a Linksys Cable/DLS router your PC will have a 192.168.1.XXX IP address. When you go through the Linksys router, the source address gets changed to the IP address the router got from the IPS. With other applications, they just fix that in the packet during the address translation.
The problem is that most IPSec traffic is encrypted, so it is not possible to change it. I have heard that changes are being made to L2TP by Microsoft to correct this. We do not use it, so I have not checked into it though. All that is needed is to remove the source IP address reference from the encrypted payload. It might be as easy as just having the VPN concentrator ignore the fact that the source address of the packet is different from the source address of the encrypted packet. The best way to find if this has been corrected is to check with someone who actually uses IPSec via L2TP.