Re: NAT before IPsec with 2.6

[Valentijn Sessink <valentyn+netfilter-users@nospam.openoffice.nl>]

Hello,

At Tue, Jan 27, 2004 at 11:39:18AM +0100, Harald Welte wrote:
> I also disagree that an ESP packet should be trated as locally
> generated (and thus iterate over OUTPUT).

This is what happens with incoming packets: they hit INPUT twice.

>   From my perspective, locally
> generated means more something like: sent via a local userspace process
> using PF_INET sockets.  If we consider a packet after any kind of change 
> as locally-generated, we could argue doing this with NAT'ed packets,
> too.  Please try to convince me, if I'm missing some point.

You are missing the point that the netfilter code changes the packets here,
thus if you would want netfilter to do something else, you could code that
in netfilter rules.

Now let's review an IPsec tunnel. On the input side, everything works as
expected: an ESP packet hits PREROUTING, then INPUT, gets unencrypted, then
the new packet (that has different from and to, and may be a different
protocol altogether) hits PREROUTING again, then INPUT (or FORWARD).

On output, however, things are not so transparant. A packet hits OUTPUT,
then gets encrypted. A totally different packet hits POSTROUTING. This makes
no sense.

> One of the fundamental principles behind netfilter/iptables, especially
> NAT, is it's symmetric behaviour (between incoming and outgoing packets,
> between the hooks, ...).   So with any possible solution, this should be
> kept in mind.

There's no symmetric behaviour now. And from an "input" perspective, I think
a decapsulated packet that has a locally ending payload should hit INPUT
again. Same with output: a locally generated packet hits output, then should
hit OUTPUT again if it was really destined for the outside world.

V.
-- 
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  valentyn+sessink@nospam.openoffice.nl