On 2014-02-27, Josh <[email protected]> wrote: > On Thu, Feb 27, 2014 at 11:00 AM, Stuart Henderson <[email protected]> > wrote: >> >> Try tcpdumping packets going over the ipsec tunnel, do you see those packets >> which should be local actually being sent over the tunnel? If so, I don't >> have >> an answer for this, but I've seen it myself, though only with manually >> configured ipsec rather than IKE (though I've only really tried IKEv1 with >> isakmpd, not IKEv2). I've mentioned it to a few people but haven't heard any >> possible explanations yet. >> > > Hi Stuart, > > It seems to be what I am facing: (tcpdump output on box1 when > performing a telnet box1_ip (192.168.150.16) to port 22 on box1) > box1:~# tcpdump -envps 1500 -i enc0 -l > tcpdump: listening on enc0, link-type ENC > 11:18:15.258255 (authentic,confidential): SPI 0xf704e810: > 192.168.150.13 > 192.168.150.16: 192.168.150.16.33636 > > 192.168.150.16.22: S [tcp sum ok] 724448283:724448283(0) win 16384 ><mss 33152,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 2973607861 0> > (DF) [tos 0x10] (ttl 64, id 47660, len 64) (DF) [tos 0x10] (ttl 64, id > 59798, len 84, bad cksum 0!) > 11:18:15.258422 (authentic,confidential): SPI 0xf704e810: > 192.168.150.13 > 192.168.150.16: 192.168.150.16.33636 > > 192.168.150.16.22: S [tcp sum ok] 724448283:724448283(0) win 16384 ><mss 33152,nop,nop,sackOK,nop,wscale 3,nop,nop,timestamp 2973607861 0> > (DF) [tos 0x10] (ttl 64, id 47660, len 64) (DF) [tos 0x10] (ttl 64, id > 59798, len 84) > > Is that a bug or just normal behavior and is there any way to get around it? > > Cheers, > Josh > >
I'm sure it's a bug, I suspect possibly in some dark corner of radix.c. I haven't heard of anybody else hitting this same problem so in a way I'm quite glad it's not just me :) On box1 you have these flows 192.168.150.13/32 0 192.168.150.16/32 0 0 192.168.150.13/esp/use/in 192.168.150.16/32 0 192.168.150.13/32 0 0 192.168.150.13/esp/require/out which ought to only match "proto esp" traffic between 192.168.150.13 and 192.168.150.16, but it actually matches "proto tcp port 22" traffic between 192.168.150.16 and itself (192.168.150.16). This is at least a potentially useful extra data point that it happens with iked as well as manual keying. The common factor between your case and mine is that the flow which is attracting traffic which it shouldn't, uses "proto esp". Workaround, well, it only seems to affect the local address in the flow (i.e. in your case 192.168.150.16) so if you have another locally configured address that you can change the flow to use, you might be able to get around it...not nice though.
