I've wondered why IPSec VPNs do that for a while, but hadn't taken the time to figure out why that is. I recently took the time.
The major reason comes down to one very big problem: NAT traversal.
When IPSec VPNs came out originally, I remember there being many problems with the NAT gateways most houses (and hotels) had. It eventually cleared up but I didn't pay attention; it wasn't a problem that was in my area of responsibility, so I didn't do any troubleshooting for it.
There are three problems IPSec VPNs encounter with NAT gateways. One is intrinsic to NAT, the other two are specific to some implementations of NAT.
The major reason comes down to one very big problem: NAT traversal.
When IPSec VPNs came out originally, I remember there being many problems with the NAT gateways most houses (and hotels) had. It eventually cleared up but I didn't pay attention; it wasn't a problem that was in my area of responsibility, so I didn't do any troubleshooting for it.
There are three problems IPSec VPNs encounter with NAT gateways. One is intrinsic to NAT, the other two are specific to some implementations of NAT.
- IPv4 IPSec traffic uses IP Protocol 50, which is neither TCP (proto 6) or UDP (proto 17), and protocol 50 uses no ports on the packet. Therefore, a VPN concentrator can only support a single VPN client behind a specific NAT gateway. This can be a problem if four people from the same company are staying in the same hotel for a conference.
- IPv4 IPSec traffic uses IP Protocol 50, which is neither TCP or UDP. Some NAT gateways drop anything that isn't TCP or UDP, which will be a problem for IPSec VPNs.
- NAT gateways rewrite certain headers and play games with packet checksums, which IPSec doesn't like. So if IPSec is going to tunnel via TCP or UDP, there will be issues.
These are some of the reasons SSL VPNs became popular.
This is where RFC 3751 comes in. It's titled, "IPsec-Network Address Translation (NAT) Compatibility Requirements" oddly enough. It turns out that packet checksums are not required for IPv4 UDP packets, which makes them a natural choice to tunnel an IPSec VPN through a stupid NAT gateway. The VPN concentrator pulls the IPSec packet out of the UDP packet, and thanks to the cryptographic nature of IPSec it already has ways to detect packet corruption and will handle that (and any required retransmits) at the IPSec layer.
But IPv6 UDP packets are required to have checksums, RFC 2460 Section 2.1 says so. How does this impact IPv6?
A good question to ask, since non-corporate IPv6 deployments are not anything close to common so it probably hasn't come up much yet.
The biggest thing helping IPv6 is that NAT should be much less common, so NAT traversal should be much less of an impediment.
The second thing helping IPv6 is time. Most home routers these days do have the ability to pass IPv4 IPSec traffic now, which should extend to IPv6 support as well.
A good question to ask, since non-corporate IPv6 deployments are not anything close to common so it probably hasn't come up much yet.
The biggest thing helping IPv6 is that NAT should be much less common, so NAT traversal should be much less of an impediment.
The second thing helping IPv6 is time. Most home routers these days do have the ability to pass IPv4 IPSec traffic now, which should extend to IPv6 support as well.
I use openvpn over UDP when I have an unstable internet connection. This allows me to keep an ssh session (or any long-lived TCP session) over the VPN where over the normal connection (witout a VPN) my ssh sessions would normally hang (which is *really* annoying).
Just my $0.02.
also this: http://sites.inka.de/~W1011/devel/tcp-tcp.html