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.

quoted

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