How does this config work?

[Paul Cardon]

"Shaw, Dale" wrote:
> 
> Thanks for the reply. Sorry if this is redundant, but re-reading my
> original message I could've made the scenario clearer. The PC/IPSec
> -client- is *behind* the PIX, on its 'inside' network and is making a
> connection through it, outwards, to a peer on the Internet. There are
> no restrictions on outgoing traffic and there is no requirement for
> connections originating from the Internet to connect to a VPN gateway
> behind the PIX.

Which side of the firewall the ipsec "client" and "server" are on and
type of NAT are really not relevant to what is going on.  The fact is
you are traversing a NAT device which modifies packet headers causing
problems with AH and transport mode ESP.

> Looking at the PIX example on the HOW-TO page, I'm not sure if this
> example is for my scenario or for a situation where clients connect to
> a VPN gateway located behind the PIX. In either scenario, I can
> understand why I would need the conduit for ESP, but why is it that a
> conduit for UDP/ISAKMP is required? Shouldn't the PIX take care of
> setting up a state entry for outgoing destination udp/500 so that only
> source udp/500 packets from the peer in question can come back?

The PIX does what you are describing as far as keeping state entries but
your client is doing ESP in UDP encapsulation so that the ESP can
survive NAT.  It must also do UDP encapsulation on the ISAKMP.  The
association is being created for the original ESP packet not the
encapsulated ESP.  The original ISAKMP packet also needs to be preserved
so that IP addresses and such in the IKE and ESP packets match.  The
Cisco client works this way.

> Back to the original issue - I thought Transport-mode ESP was
> troublesome with NAT. The page;
> http://www.linuxdoc.org/HOWTO/VPN-Masquerade-HOWTO-6.html lists
> some/all of the drawbacks. Here's the paragraph that makes me wonder
> how my setup is working at all..
> 
> "IPsec traffic using transport-mode ESP also cannot be reliably
> masqueraded. Transport mode ESP essentially encrypts everything after
> the IP header. Since, for example, the TCP and UDP checksums include
> the IP source and destination addresses, and the TCP/UDP checksum is
> within the encrypted payload and thus cannot be recalculated after the
> masquerade gateway alters the IP addresses, the TCP/UDP header will
> fail the checksum test at the remote gateway and the packet will be
> discarded. Protocols that do not include information about the source
> or destination IP addresses may successfully use masqueraded transport
> mode."

The UDP encapsulation avoids that problem because the NAT affects only
the UDP header and there is no modification of the original ESP packet. 
It will still have your non-translated, private side IP address in its
header so that the encrypted TCP checksum is not affected.

If you want a reference that describes how it works in gory detail,
check out:

http://www.ietf.org/internet-drafts/draft-ietf-ipsec-udp-encaps-00.txt

Dale, I hope I've explained it reasonably clearly.

-paul

VPN is sponsored by SecurityFocus.com