Re: NAT before IPsec with 2.6

Re: NAT before IPsec with 2.6

[Harald Welte]

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

Cc'ing netdev, since this is now a very clear proposal and not some
internal netfilter rambling.

On Tue, Jan 27, 2004 at 10:13:33PM +0100, Andreas Jellinghaus wrote:
> > This is what happens with incoming packets: they hit INPUT twice.
> 
> yes, but once before and once after decryption. use either fwmark
> or an ipip tunnel interface to destinguish between already decrypted
> and was-never-encrypted packets. 

yes, and this is desired.   However, the packets also hit PREROUTING
twice, which is exactly what we want (and get it for free, since
xfrm4_input.c calls netif_rx() again).  

However, it doesn't reset the skb->nfct pointer, so connection tracking
sees both encapsulated and decapsulated packet as belonging to the same
connection.  This is wrong, and dangerous (application helpers might be
called for the encapsulated traffic, which now has a completely
different layer 4 protocol.

So with stock 2.6.x you have 

- no working connection tracking in any kind of ipsec scenario
- conntrack and NAT helpers trying to find readable application data
  within already-encrypted packets
- no working DNAT/SNAT, mainly because of not-working connection
  tracking

> > 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.
> 
> use an interface, and you will see the packet twice, plus the interface
> does the route lookup on the encrypted packet. so no ugly hacks in the
> routing table are necessary.

Did anybody propose ugly hacks in the routing table?

> [symetry]
> 
> that does not work:
> netfilter wants NAT to be the first thing for incoming packets
> and the last thing for outgoing packets. thats symetry.

yes, it is symmetric.  As is the symmetry between prerouting/postrouting
and input/output hooks. As well as the symmetry between SNAT and DNAt,
...

> but you want ipsec encryption and decryption as soon as possible:
> both before looking at the routing table.

Yes, that's why what IPsec is doing for incoming ESP/AH packets the
right thing: go through PRE_ROUTING, route to LOCAL_IN, decapsulate,
and start over again.

However, for outgoing ESP/AH packets (locally-encapsulated), it doesn't
show the symmetric behaviour of what it does on the input side: go
through FORWARD, encapsulate, route, POST_ROUTING.  No starting over.

So we absolutely _need_ a symmetric-to-incoming behaviour like:

a) for locally-originated packets
LOCAL_OUT, POST_ROUTING, encapsulate, LOCAL_OUT, POST_ROUTING.

b) for forwarded, locally-encapsulated packets
PRE_ROUTING, FORWARD, POST_ROUTING, encapsulate, LOCAL_OUT, POST_ROUTING.

No, we don't achieve this by manipulating the routing code, but by
placing the respective hooks in ah{4,6}.c and esp{4,6}.c
{ah,esp}_output() function respectively. We also need to (again) reset
the skb->nfct and drop the conntrack reference again.

This way we 
	1) make connection tracking work again
	2) do not change any routing of the current implementation
	3) enable users to
		a) filter unencapsulated, encapsulated and decapsulated
		   packeets at their 'expected' place
		b) do DNAT on the incoming decapsulated packets
		   (which doesn't work right now, but should)
		c) do SNAT on the outgoing/forwarded to-be-encapsualated
		   packets (which doesn't work right now, but should)

> mixing those two will never result in symetry. if you try it
> (routing before encapsulation), the result has problems.

I'm not proposing to route before encapsulating.  I just propose of
calling the same netfilter functions that we usually call before/after
routing at different places :)

> 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 --]

Re: NAT before IPsec with 2.6

[Andreas Jellinghaus]

On Wed, 2004-01-28 at 09:58, Harald Welte wrote:
> However, it doesn't reset the skb->nfct pointer,

the tunnels do. 

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?

> - no working connection tracking in any kind of ipsec scenario
that is not true. ipip_rcv:
                nf_conntrack_put(skb->nfct);
                skb->nfct = NULL;
ipip_xmit:
        nf_conntrack_put(skb->nfct);
        skb->nfct = NULL;

the only problem is stability and scheduling in atomic with xfrm+ipip
(i guess a bug, I hope someone who understands the code could take a
look at it).

> > use an interface, and you will see the packet twice, plus the interface
> > does the route lookup on the encrypted packet. so no ugly hacks in the
> > routing table are necessary.
> 
> Did anybody propose ugly hacks in the routing table?

if you don't use an interface, you need them in real world setups.
with an interface both gw and client put the route to each others
static vpn ip on ipsec0 and then configure the tunnel ips, and
those ip will be used to lookup the interface where to send the
encrypted packet.

with the current code without using interfaces, the ip of the
vpn tunnel needs to be moved to the interface that will be used
to reach the vpn gateway. even worse, you need to play with
source address selection to make sure an outgoing packet has
your static vpn ip, and not the dynamic ip of whatever net
you are currently using. 

example:
      up ip addr add 192.168.3.1 dev wlan0
      up ip route del default dev wlan0
      up ip route add default via 192.168.1.1 src 192.168.3.1 dev wlan0
      down ip addr del 192.168.3.1 dev wlan0

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.

and yes, of course you want static ip addresses for "road warrior"
clients! for example smtp servers need to these to allow relaying
or not.


> So we absolutely _need_ a symmetric-to-incoming behaviour like:

use an tunnel interface and you have that.
(adding pre_/post_ routing is very simple, simply cut&paste to the
_rcv and _xmit functions.

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

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


[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, ...).

> I'm not proposing to route before encapsulating.

that is currently done. I'm glad if that "feature" is removed.


>   I just propose of
> calling the same netfilter functions that we usually call before/after
> routing at different places :)

fine. I don't understand what the benefit of doing everything like with
an interface, but avoiding the interface. but please keep
tunnel with interface and tunnel without interface in sync.

Regards, Andreas

Re: NAT before IPsec with 2.6

[Harald Welte]

[-- 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 --]

Re: NAT before IPsec with 2.6

[Andreas Jellinghaus]

Hi Harald,

The userland could be improved to be more flexible,
then it could configure the same issue with and
without interface, depending on the needs. From
protocol perspective that wouldn't be visible, 
so I realy don't see any interoperability issues here.

ip, esp, inner ip, tcp/udp, payload.
the packet can look the same, whether you use some
interface to assemble it or not. ike and setting
spd plus tunnel is the issue, but thats userspace.

ok, but thats not a netfilter topic.

> 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

one change you want to add is POST_ROUTING before
encapsilating. add that hook at the start of ipip_xmit,
too (renameing ipip_xmit to ipip_xmit_finish
and a new ipip_xmit with only the hook), and things
should be in sync. same for the other tunnels.

the other change you want to make is set the interface
to some other value after encapsulation. what value?
will it be possible to specify the value?
I'm still thinking about that and in what scenario you
would need to differ say ipsec0 and ipsec1.
but such scenarios could exist. 

maybe one vpn/gateway/router shared by two small companies,
both want to keep their network private ?

[setkey debugging]
> yes, but I'd rather don't put both of them into one patch.

sure. are there netfilter routines that can be reused,
or are they somehow tied to the NF core? netfilter formats
the packets nicely for debugging.

> > an interface, but avoiding the interface. but please keep
> > tunnel with interface and tunnel without interface in sync.
> 
> What do you mean by that? 

if you add a hook in ah/esp, add the same hooks to ipip, ipgre,
ip6_tunnel etc. Currently netfilter/tunneling is more or
less consistent - without interface there are some issues,
but the tunnelling fits fine into the big netfilter picture
(the one with 5 hooks explained). 

if ah/esp used different hooks than the real tunnels,
that would make the situation less easy.

also, what is the status of the new hooks?
dropped or do you still plan to add a different
hook, even if it calls the same table?
POST_XFRM is a bad name, better something
like POST_ENCAP or POST_DECAP, because IMO
tunnels should call that hook, too, so it
should be a generic name, not tied to xfrm.


>  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. 

ah, wait. it will be only 4 steps,
3+5 and 4+6 are merged, because the tunnel calls xfrm itself,
so it does both at once. that could be changed of course,
if you want that flexibility.

but i wonder:
if you want to change the untunneld packet, you can do that
in 1/2. if you want to change the encrypted packet, you can
do that i 5/6. 3/4 has the same (as payload) you see in 1/2,
and the same header that has 5/6. so what is the benefit
of two additional steps?

Regards, Andreas

Re: NAT before IPsec with 2.6

[David S. Miller]

On Wed, 28 Jan 2004 09:58:31 +0100
Harald Welte <laforge@netfilter.org> wrote:

> No, we don't achieve this by manipulating the routing code, but by
> placing the respective hooks in ah{4,6}.c and esp{4,6}.c
> {ah,esp}_output() function respectively. We also need to (again) reset
> the skb->nfct and drop the conntrack reference again.

Why not just do this right when we pop into the dst_output() call
in ip_output.c  This way we don't have to add all of this stuff
for every new encapsulator we ever implement.

Maybe not like this precisely, but something like it.