Hi Michael,

> How did you handle integrating IPSec with NAT?
>
> We've had to use NATD on the 'inside' interface for this to work, are you
> using NATD or IPNAT?

m0n0wall uses ipnat; there don't seem to be any issues with NAT and IPsec,
but this is probably because the NAT rule generator specifies the source
address (LAN and DMZ subnet) instead of just 0/0 in the ipnat map rules...

> I looked at modifying the BSD kernel to switch the ordering on when IPNAT
> and IPSEC process packets to get it working correctly.

Well, I can tell you that I'm absolutely sick of fixed processing orders -
when you have ipfw, ipfilter, ipnat, IPsec and dummynet and use them all
at once, you have to keep inventing workarounds... Add to the fact that
the processing order is not well documented. I had to add pass rules for
ESP packets on WAN to ipfilter when IPsec is enabled - OK, that's what one
would expect. What nobody tells you is that the packets reappear on the
WAN interface after having been decrypted, but this time as ipencap
packets (IPv4-in-IPv4), so you have to pass those, too. This only seems to
happen with FAST_IPSEC and not with KAME IPSEC, though. Then they appear
on WAN once more with the real/internal source/destination addresses. And
finally, you have to pass (or keep state) them out of the LAN interface.
So IPsec packets go through ipfilter 4 times, and that doesn't help the
(IMHO bad) performance much...

- Manuel