[Openswan Users] NETKEY/KLIPS (was Re: Is OpenSwan 2.6.33 supporting kernel 2.4?)

[Michael Smith]

Michael H. Warfield wrote:
> Trying to tcpdump or wireshark ipsec traffic is a bit ambiguous,
> confusing, and unfortunately incomplete.  With KLIPS you have the
> encrypted packets on the ipsecX interface and the unencrypted packets on
> the normal interface.  With NETKEY, they're all should be on the normal
> interface.  I've heard some complaints about that but I would argue
> that's where they really should be.  We can have philosophical debates
> on that point.  What IS a problem (for some) is that they are not all
> there.  I think it's either the encrypted received packet or the
> unencrypted received packet which is missing.

With NETKEY it's the unencrypted transmit packet that is not shown in 
tcpdump.

The other result of this is that the interface's inbound byte counters 
may be doubled, but I've never confirmed this.

My other beef with NETKEY is that the reverse path filter 
(rp_filter/martian logging) applies to packets after decryption. If I've 
got a default route on eth0 and a private WAN link on eth1, and packets 
from my WAN peer come in eth1, they get dropped by rp_filter unless I 
have a route to the tunneled subnet via eth1. This is easy to handle 
except with dynamic routing: if I have an alternate route to my WAN peer 
on eth0 and my eth1 link fails, suddenly my packets start getting 
dropped as martians.

IMHO rp_filter should not apply to IPsec packets after decryption. They 
already have a much stronger security guarantee than rp_filter provides. 
But I don't like to turn off rp_filter completely for an interface as it 
still provides protection for non-IPsec traffic.

> My main reason for going with NETKEY was simply the fact that it is
> integrated into the kernel in the upstream sources and well maintained.

Same here.

Mike