[Openswan Users] Packets show up twice in tcpdump

[Andy Gay]

On Tue, 2006-08-22 at 17:58 -0400, Michael Smith wrote:
> Hi,
> 
> I've been using the kernel 2.6 stack with Openswan 2.4.x for a while now, 
> and something's been nagging me. I just found out there's some crossover 
> between the tcpdump and openswan maintainers so I figured I'd post here.
> 
> With the old KLIPS stack and the virtual interface hack in kernel 2.4, 
> I could see bandwidth usage very clearly in tcpdump, iptraf, and traffic 
> shaping (tc). Unencrypted packets showed up only on ipsec0 and what I saw 
> in tcpdump for physical interfaces was exactly what was on the wire.
> 
> In 2.6, incoming packets show up twice when I tcpdump the physical 
> interface: once as ESP, then again after decryption. Outgoing packets 
> don't show up at all if they're being encrypted (!!). iptraf is 
> double-counting incoming bandwidth on the physical interfaces, too. 
> (outgoing is OK.)
> 
> I'm running kernel 2.6.11.11, Openswan 2.4.4, libpcap 0.7.1, and tcpdump 
> 3.7.2 and before I start upgrading I am curious if anyone else sees the 
> same things with later versions.
Seeing the incoming packet twice is normal. It passes the hook that
tcpdump sees twice, before and after decryption. But you should
certainly see the outgoing esp packet. It works for me - this is a trace
of 2 pings and their replies, using 2.6.17.6, tcpdump version 3.9.4,
libpcap version 0.9.4

19:23:47.299126 IP myoutside > thatoutside: ESP(spi=0x1941ec73,seq=0x9), length 132
19:23:47.333392 IP thatoutside > myoutside: ESP(spi=0x088cfcc1,seq=0x1), length 132
19:23:47.333392 IP thatinside > myinside: ICMP echo reply, id 2101, seq 1, length 64
19:23:48.300479 IP myoutside > thatoutside: ESP(spi=0x1941ec73,seq=0xa), length 132
19:23:48.332220 IP thatoutside > myoutside: ESP(spi=0x088cfcc1,seq=0x2), length 132
19:23:48.332220 IP thatinside > myinside: ICMP echo reply, id 2101, seq 2, length 64

I've used earlier versions in the past, never noticed a problem.

>  Does anyone understand how it will work 
> with traffic shaping? With KLIPS I used to give outgoing ESP packets 
> priority over normal Internet traffic on the physical interface. I haven't 
> been doing that in 2.6 because I'm not sure it'll work.
So try it and find out :)
Anyway, why shouldn't it work? You can still select ESP as protocol 50.

>  Ingress policing 
> would probably work even less unless I can find a way to exclude the 
> post-decryption packets from the bandwidth counters.
Match those as (not protocol 50)....
Doesn't seem that hard. Maybe I'm missing something.

> 
> Thanks,
> Mike
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan: 
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>