Re: [SLUG] Why does IPsec cause NAT to fail?

From: Ian C. Blenke (icblenke@nks.net)
Date: Wed Jun 11 2003 - 14:57:55 EDT


On Wednesday 11 June 2003 12:49, Vanessa May wrote:
> Hi,
>
> I've just been a lurker for awhile, but now I have a question and I'm
> hoping someone can help. Trying to create a VPN server using Free Swan on
> a RH firewall for XP clients. When I turn on IPsec the internal clients can
> no longer get to the internet. Is there something I need to do with IPsec
> or NAT?

This is a bit complicated to explain, but I'll try a brief summary.

TCP and UDP are both types of packets (proto 6 and 17) sent via IP. The
easiest place to see this is by looking in your /etc/protocols file.

IPSEC uses two *new* types of packets, ESP and AH (proto 50 and 51).

While TCP and UDP are commonly NATted and filtered through firewalls, most
other protocols are typically stripped.

Most TCP and UDP protocols are "NAT friendly", and the IP header information
can be safely rewritten without regards to the contents of the streams.

Some TCP based streams like FTP, and UDP based flows like RTP (ala RTSP
video/audio streaming and telephony) include information *inside* the control
channel that assign ports dynamically. These protocols are deemed NAT
unfriendly, and require active manipulation by the firewall to "NAT" proxy
the connections. Linux has "IP Masquerading" modules that do exactly this.

To allow IPSEC, you can permit ESP and AH packets to traverse a firewall and
relay to a specific address on the other side.

Unfortunately, AH packets *encrypt the IP header*, which means you cannot muck
with them - AH (or "host to host") have Authenticated Headers, and cannot be
NATted.

ESP packets, on the other hand, have no problem with NATting as long as your
NATting firewall knows how to handle/forward IP protocol 50 packets. With
older firewalls, it's often enough to relay all IP protocol 50 traffic to an
endpoint behind the firewall. The problem with this is that you can only
relay to one endpoint. To do more than this, your firewall must know how to
handle ESP connection states and relay traffic to the appropriate host.

There is an ip_masq_ipsec module that knows how to statefully handle ESP
connections. If you find, build, and install this kernel module, you may
safely establish ESP mode (aka "tunnel mode") IPSEC sessions through your
firewall.

Newer IPSEC implementations have started using UDP as well. Even the latest
Freeswan version supports this transport. With UDP encapsulation, you may
traverse any firewall capable of statefully relaying UDP sessions.

PPTP's GRE encapsulation suffers the same fate as IPSEC's ESP - you need to
use an ip_masq_pptp masquerading module *or* relay all IP protocol 47 packets
to a single endpoint behind the firewall. PPTP is essentially PPP over GRE,
with some god-aweful encryption (all MSCHAP is broken IMHO, even v2).

-- 
- Ian C. Blenke <icblenke@nks.net>

(This message bound by the following: http://www.nks.net/email_disclaimer.html)



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:27:42 EDT