>Hi network gurus,
>according to the IPsec FAQ on www.netbsd.org, the ipf/IPsec
>interaction was recently changed to allow them to work together (at
>least better than before). With the new method, ipfilter always looks
>at the wire format packets.
>
>Even though this allows some filtering it is my understanding that NAT
>will still not work with IPsec, since you are not allowed to change an
>outgoing packet after the IPsec processing. Or am I confused?

	i believe the current packet processing order (as presented on IPsec
	FAQ) is more correct.

	let us look at outbound side of the code path here.
	for VPN usage (which is the major IPsec use today), you never need
	to run tunnel mode IPsec tunnel mode and NAT on the same packet.

	((private address cloud Y))
	  |
	VPN/NAT gateway B
	  |
	The internet --- normal internet destinations Z
	  |
	VPN/NAT gateway A
	  |
	((private address cloud X))

	for traffic coming out from private address cloud X, the traffic will
	be processed like follows:
	- if the packet is destined to private address cloud Y, you need to
	  run a tunnel mode IPsec encapsulation for the traffic, like this:
		original packet: packet looks like "IP payload"
			IP src = X, IP dst = Y
		after encapsulation: "IP ESP IP payload"
			outer IP src = A, outer IP dst = B
			inner IP src = X, inner IP dst = Y (IPsec protected
	- if the packet is destined to outside internet destinations, the
	  packet has to go through NAT.
		original packet: "IP payload"
			IP src = X, IP dst = Z
		after NAT: "IP protocol" (again)
			IP src = A, IP dst = Z

	with ipfilter, NAT hook is combined with packet filter.  by letting
	packet filter code to look at wire-format packet, we can easily
	differentiate between the above two cases.

	yes, the current processing order is somewhat biased to the above
	scenario, and may not be suitable for your VMWare scenario.  but we
	cannot pick both of the orderings.  we really need to pick one of them.
	we had a lot of discussion before on this mailing list, and the current
	ordering is based on the discussion.  that time it seemed that the
	above scenario is the majority need.

	i really hate NAT and IPsec tunnel mode (I hate them both),
	and always avoid configuring those.  they are inherently incompatible,
	it does not worth your time.

>There seems to be an "enc" interface in OpenBSD that allows you to
>look at the packets before/after the IPsec encapsulation. This seems
>to allow NAT. Is there a way to do something similar in NetBSD?

	there's nothing like that.  the rule of thumb is that we shouldn't
	play with additional interfaces, or you will be doomed.

itojun