> > The reason is that NAT changes the source address, and the > checksum in > > AH will no longer match. Search for NAT traveral and ipsec > on google, > > and you'll find out more of the reasons it won't work without NAT-T. > > Which is why I punched holes - I know what ports my IPSec > client claims to use, and I'M NOT DOING NAT ON THOSE PORTS! > Therefore, the IP address stays constant. That's what > 'punching holes' means - at least, that's the term that I've > seen and heard from multiple sources. So you have a public IP on the machine on the inside which is the same as the NAT address on your firewall? "Punching holes" usually means you just open a port let that traffic pass into your network, but NAT still happens on it. Your IPSec client on the inside is going to use the IP assigned to your machine in the IPSec traffic it sends out, which is most likely private. Your firewall will still NAT it, but won't be able to change anything in the application layer (like the checksum), hence your tunnel will fail. Plus, IPsec only uses UDP port 500, but also uses IP types AH and ESP (50 and 51 if I remember correctly). AH and ESP are portless protocols. I guarantee that it won't work unless *both* endpoints support NAT-T. But, as in all things, the best way to find out is to try it. :) Jay