[Swan] Valid packets dropping in the kernel

[Paul Wouters]

On Fri, 2 Nov 2018, Dharma Indurthy wrote:

> Hey, folks.
> I have a conundrum.  It looks very similar to https://lists.libreswan.org/pipermail/swan/2018/002834.html, which doesn't have an outcome yet, I don't think.

That one looks a bit unexplained. It should not cause problems, but the
poster did not add "ip xfrm" output for us to see anything.

> We have the following connection, one of a couple hundred -- the rest of which seem to work fine as far as we can tell.  I can't be sure, because I can't detect the issue from my side.
> 
> conn customer
>     type=tunnel
>     authby=secret
>     left="172.20.109.76"
>     leftid=52.205.166.91
>     leftsourceip="172.20.109.76"
>     leftsubnets=" 10.253.1.53/32 10.253.0.1/32 "

Do not use leftsourceip= if you specify more then one leftsubnet. Also,
leftsourceip= must be an IP address within the (single) leftsubnet=

>     right=12.131.93.13
>     rightsubnets=" 10.50.32.166/32 10.50.32.239/32 10.50.36.4/32 "
>     rightsourceip=12.131.93.13

The same applies here.

> SAs come up, and we can ping their side.

> 000 #3166924: "orthooklahoma3937/1x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 918s; newest IPSEC; eroute owner; isakmp#3166786; idle; import:admin initiate
> 000 #3166924: "orthooklahoma3937/1x1" esp.815a3ae9 at 12.131.93.13 esp.618dd3ad at 172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
> 000 #3167825: "orthooklahoma3937/1x2":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 1148s; newest IPSEC; eroute owner; isakmp#3166786; idle; import:admin initiate
> 000 #3167825: "orthooklahoma3937/1x2" esp.73c12328 at 12.131.93.13 esp.b76a1e64 at 172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
> 000 #3165167: "orthooklahoma3937/1x3":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 82s; newest IPSEC; eroute owner; isakmp#3136241; idle; import:admin initiate
> 000 #3165167: "orthooklahoma3937/1x3" esp.33a967a1 at 12.131.93.13 esp.72596d49 at 172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
> 000 #3166787: "orthooklahoma3937/2x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 891s; newest IPSEC; eroute owner; isakmp#3166786; idle; import:admin initiate
> 000 #3166787: "orthooklahoma3937/2x1" esp.970dcc23 at 12.131.93.13 esp.207c2a70 at 172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
> 000 #3166964: "orthooklahoma3937/2x2":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 602s; newest IPSEC; eroute owner; isakmp#3166786; idle; import:admin initiate
> 000 #3166964: "orthooklahoma3937/2x2" esp.61180b3 at 12.131.93.13 esp.50ff9d05 at 172.20.109.76 ref=0 refhim=0 Traffic: ESPin=1KB ESPout=1KB! ESPmax=4194303B
> 000 #3162278: "orthooklahoma3937/2x3":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 437s; isakmp#3136241; idle; import:admin initiate
> 000 #3162278: "orthooklahoma3937/2x3" esp.e4c24f90 at 12.131.93.13 esp.cadf8591 at 172.20.109.76 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
> 000 #3162955: "orthooklahoma3937/2x3":4500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 399s; newest IPSEC; eroute owner; isakmp#3136241; idle; import:admin initiate
> 000 #3162955: "orthooklahoma3937/2x3" esp.d783e492 at 12.131.93.13 esp.1d0a885d at 172.20.109.76 ref=0 refhim=0 Traffic: ESPin=42KB ESPout=0B! ESPmax=4194303B
> 000 #3166786: "orthooklahoma3937/2x3":4500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 26486s; newest ISAKMP; nodpd; idle; import:admin initiate
> 
> We have duplicate SAs for some reason -- you can see that for 2x3, not sure if that matters.

It should not matter. What seems to have happened is that when you
established the IKE SA, and you were in the process of establishing all
the IPsec SA's, the other end also started doing the same IPsec SA's.
So you ended up with one connection which was initiated by you and
responded to by you. One of them should vanish after a little while.

> It's the 1x1 SA that's pertinent.  We NAT the source and target ips via PREROUTING and POSTROUTING rules, and I
> can see traffic initiated by the customer hitting PREROUTING but never hitting POSTROUTING and never leaving the box.

Are you using the policy matching for ipsec? See:

https://libreswan.org/wiki/FAQ#NAT_.2B_IPsec_is_not_working

Paul