FWIW, some VPN devices including Cisco's line of "Concentrators" (from the aquisition of Altiga), conquer this problem by encapsulating the IPSEC data in UDP. It's hackish, but is a good solution for VPNs to telcommuters behind hotel PAT and little Linksys dsl devices. According to our vendors, these Cisco devices are currently "special order" items, meaning they take a long time to stock. They're also relatively new, so open box/dying dotcom/ebay hardware is hard to come by. Regards- Adam On Thu, 13 Sep 2001, Steven M. Bellovin wrote:

In message <912A91BC69F4D3119D1B009027D0D40C01BB459C@exchange1.secure.insweb.co m>, Vandy Hamidi writes:

...

I know that in Tunnel Mode, IPsec can be NATed and PATed (without IKE on UDP 500 being used), but as I'm trying to break down the process of how it is working, I've been stumped by this: NAT - Changes source IP during translation PAT - Changes source IP and TCP/UDP port to another to track multiple to one translations. My question is, how does PAT track the packets with their internal hosts when there is not a TCP/UDP header to translate. How does it know which "internal" host a returning ESP packet must be forwarded to after it un PATs the incoming packet? thanks and I hope this isn't a totally stupid question. If it is, humor me ;),

IPsec can't be PATted, because the TCP and UDP port numbers are in the protected part of the packet.

--Steve Bellovin, http://www.research.att.com/~smb http://www.wilyhacker.com