itojun@iijlab.net writes:

> 	unfortunately, even with the above setup it doesn't work.  it is just
> 	impossible for IPsec to work with NAT, *by nature*.

    Given that I've extensively used netbsd's ipsec implementation
through a NAT setup that sounds just like the above users question,
this does not seem to be a true statement.  Why do you say this?  Am I
missing something?

    There's nothing a specification level that prevents an ESP based
tunnel from working with one-to-one NAT in the middle.  It's just
fugly.

>       for instance,
> 	NAT needs to rewrite packet content for FTP and other traffic,
> 	however IPsec ESP is designed to make it impossible to look at the
> 	content by encryption.

    Only if your NAT has been so configured.  You don't have to do so.
Any protocol that *requires* an ALG (ftp not being one of them) is one
you can expect to have trouble with in day to day environments, let
alone with ipsec.


    The only "unusual" thing I've found in configuring setups like
this is that the host with real connectivity is configured as if it
were talking to the public address of the NAT box, but the host
behind the NAT box is configured in the obvious way that never
mentions that public address.

    I'm pretty sure I've even gotten racoon working through this
setup; I'd have to check my CVS logs tho because I'm fortunately
dealing with a more straightforward setup now.