[Ipsec-tools-devel] tcpdump, iptables and ipsec. Which order?

[Matthew S. <ma...@ap...>]

Hello List,

I'm trying to figure out the order in which the linux kernel
encapsulates and decapsulated ipsec packets in relation to when iptables
sees them and when tcpdump sees them.

Specifically, why do I see tcpdump output like this on my ppp0 interface
(dsl) when pinging a host over the ipsec tunnel.

IP 192.168.1.1 > 192.168.2.1: icmp 64: echo reply seq 12
IP 1.1.1.1 > 2.2.2.2: ESP(spi=0xbba6746d,seq=0x127)

As you can see my tcpdump output shows my ping request being sent as an
ESP packet where 1.1.1.1 is one side of the tunnel and 2.2.2.2 is the
other side, however the return ICMP packet is already decapsulated by
the time tcpdump sees it. If I sniff eth1 (the physical interface my
pppoe session lives on) I can see that both are ESP packets so I know
it's coming over the tunnel, but I thought tcpdump was supposed to show
you raw packets on the interface, and thus ppp0 should be getting icmp
replies inside of ESP packets.

The other thing that I'm finding really confusing is setting up my
firewall to allow packets thought the tunnel (FORWARD chain) but
blocking packets from going to the Internet if the tunnel is down.

For example, if I have these rule:

iptables -A FORWARD -s 192.168.1.1 -d 192.168.2.1 -j ACCEPT
iptables -A FORWARD -s 192.168.2.1 -d 192.168.1.1 -j ACCEPT

Then I can ping though the tunnel, but if the policy gets whacked for
some reason, then packets destined to 192.168.1.1 get sent to the
default gateway (public Internet).

I'm trying to get a rule together that would drop these packets if they
are not tunneled, however this rule drops tunneled traffic:

iptables -t mangle -A POSTROUTING -p all -d 192.168.0.0/16 -j DROP

This leads me to believe that the packet isn't being matched by the
policy and encapsulated until after netfilter is done with the packet.
If that is the case then writing a rule to drop packets that aren't
encapsulated would be impossible and I am forced to rely on ipsec
dropping packets that match a policy when the tunnel is not up.

Anyway, if anyone has information about the order that the packets
traverse the kernel in, or what order the packets are processed before I
see them in tcpdump it would be greatly appreciated.

Thanks,
schu