[strongSwan] routing issue with strongswan and Ubuntu 16

Kseniya Blashchuk ksyblast at gmail.com
Mon Feb 18 13:55:41 CET 2019

Hi all!

We have ipsec (ikev1) + ipip configured on Ubuntu 16, kernel
4.15.0-45-generic, strongswan. Our peer has a strange strict security
policy making rekey every two minutes (crazy but they don't want to change
that). Sometimes after rekey our machine does not route packets coming from
the peer for the time=lifetime of the SA (2 minutes in this case).
Also need to mention that we have SNAT configured to ipip interface.

Tcpdump analysis results:
1) on ipip interface: I can see replies from the remote side with tcpdump,
so I guess the traffic is decrypted successfully
2) on physical interface: I have checked initiator and responder SPIs and
compared them with those in strongswan logs and those in ip -s xfrm state.
ip -s xfrm state showed just 2 SPIs for that source and destination, so I'm
sure there was no mistake. Everything matched.

I turned on iptables logging in every chain and table (except raw), and I
see these incoming packets in the mangle prerouting chain, but nothing in
forward (during the issue). AFAIK the next step is routing decision (I
checked this pic http://inai.de/images/nf-packet-flow.png), that's why I
tried "ip route flush cache" command, and it helped (I was surprized).

So, it seems like the packets are dropped for some reason, they are not
routed. At the same time everything works fine from the server itself (when
there is no routing via it). After the next rekey everything works fine.
I have tried to tune /proc/sys/net/ipv4/route/* parameters reducing
timeouts and so, however the problem still exists.
I have compared ip ro get, ip rule commands output and output of lnstat and
lnstat -f rt_cache, and /proc/net/fib_trie and /proc/net/fib_triestat at
working and non-working time, - there is nothing that could give me a clue
what's going on. I also need to mention that this traffic loss during a
specific SA seems to be totally random, but it always starts with some
particular rekey and ends with the next rekey.

Does anybody have any idea about that?


BR, Kseniya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20190218/cd208edc/attachment.html>

More information about the Users mailing list