Re: NAT before IPsec with 2.6

[Harald Welte <laforge@netfilter.org>]

[-- Attachment #1: Type: text/plain, Size: 3838 bytes --]

On Wed, Jan 28, 2004 at 11:21:34AM +0100, Andreas Jellinghaus wrote:
> On Wed, 2004-01-28 at 09:58, Harald Welte wrote:
> > However, it doesn't reset the skb->nfct pointer,
> 
> the tunnels do. 

yes, I'm well aware of that.

> In summary it looks to me, like you want to have everything that a
> real tunnel with an interface offers, but for some reason you don't
> want the tunnel with the interface. right?
> so, why?

Because it's needed for interoperability with other IPsec
implementations, in other words if you are not running Linux on both
ends.  Yes, I know... in an ideal world everybody would run linux on
both ends... but if you do: Why use IPsec at all, if not for
interoperability.

> > - no working connection tracking in any kind of ipsec scenario

s/ipsec scen/plain non-tunnel ipsec scen/

> > Did anybody propose ugly hacks in the routing table?
>
> if you don't use an interface, you need them in real world setups.

oh well, what you are describing are entries in the routing table,
that's fine.  I thought you were talking about hacking the routing code.

> and swithcing from wlan0 to eth0 does not only require
> the tunnel to be reconfigured (local and remote ip), but
> also changes in the routing table. that is horrible.

well, this is just like the 2.6.x ipsec implementation is like.  It's
not the netfilter project's will or task to change that implementation.
We just want to get the same netfilter/iptables functionality,
independent of somebody using ipsec or not.

> > So we absolutely _need_ a symmetric-to-incoming behaviour like:
> 
> use an tunnel interface and you have that.

yes, but as stated above, other implementations might not be able to
work with that implementation.

> sure, you can archive the same thing without using tunnel interfaces.
> But i wonder if that creates a simple solution, easy to understand.

Unfortunately there is no simple or easy solution.  We just want to get
it working at all.

> my basic question is: how will these changes affect setups with tunnel
> interfaces? 

I think you would see the packet even more often:

1) LOCAL_OUT of original packet 
2) POST_ROUTING of original packet
3) LOCAL_OUT of tunnelled packet
4) POST_ROUTING of tunneled packet
5) LOCAL_OUT of ESP/AH packet
6) POST_ROUTING of ESP/AH packet

> [other issue]
> if we are to look at the calls to xfrm anyway: would it be possible to
> add a debugging facility for dropped packets? I know, that is not a
> netfilter issue, but I guess many people will find it problematic,
> if they cannot see what packets are dropped by the xfrm logic.
> I'm only rasing the issue, because that code is most likely put
> to the same places we are discussiong right now (ah, esp, ipip_rcv,
> ipip_xmit, ...).

yes, but I'd rather don't put both of them into one patch.

> > I'm not proposing to route before encapsulating.
> 
> that is currently done. I'm glad if that "feature" is removed.

Again, I misunderstood you.  I do not intend to change the IPsec
implementation in any way, I just want netfilter to acommodate it. 

> an interface, but avoiding the interface. but please keep
> tunnel with interface and tunnel without interface in sync.

What do you mean by that?  From my point of view, it should be like
(1-6) above.   This way anybody can filter on any kind of header bit at
any layer of the encapsulation. 

> Regards, Andreas

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]