Re: Problem with IPSEC tunnel mode

[jamal <hadi@cyberus.ca>]

On Sat, 2005-23-04 at 23:03 +0200, Wolfgang Walter wrote:

> 
> SPD is indeed also a sort of firewall. You can use it to construct i.e. a 
> vpn-gateway and forbid any non-vpn-traffic entering or leaving.
> 

So i think design intent must have been to map these to the
netfilter/iptables hooks - fwd/in/out hooks. 

> How the SPD is implemented is of course not specified. I think KLIPS use a 
> mixing of routing and netfilter and "ipsec-netdevices" to realise the SPD.
> 

It could certainly be any applicable classifier that can map at least
the 6 tuples {src/dst IP, src/dst port, proto, netdevice}. 

> My personal view is that 2.6 native SPD is better. Its easier to understand 
> and protect i.e. vpn-gateways.

Except it introduces yet another firewall scheme. We should look at
unifying these schemes. Both the input/fwding can be derived at the
ingress. 

> Using selectors other than src, dst in the SPD is tricky, by the way, because 
> of fragments. Say a rule selects packets from a to b with protocol tcp and 
> dst-port 80 to be sent through a tunnel you must have an extra rule (and 
> tunnel) for the fragments (and all fragments are tunneled then).
> 
>
> Maybe more complex selectors should be realised by netfilter, a module which 
> can mark packets. And SPD uses that mark. Then statefull policies are 
> possible, i.e.
> 

I think that it is probably the best path forward - i suppose this being
the first incarnation of native ipsec this could be seen as a lesson.
 
> I don't know if linux handles ICMP traffic well, often one must check the 
> payload against the SPD. I had no time yet to do some tests.
> 

from the code it should work just fine.

cheers,
jamal