> > 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