[Swan] Packets dropped strangely

libreswan91 at iotti.biz libreswan91 at iotti.biz
Tue Oct 9 08:35:03 UTC 2018


Hi all

I have a CentOS 7 box with libreswan. It has libreswan-3.23-5.el7_5 and
kernel-3.10.0-514 from CentOS.
I have two conns in my ipsec.conf, both go to the same remote vpn gateway. I
split the two conns for simplicity, see below:

config setup
        protostack=netkey
 
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0
.0.0/8,%v4:100.64.0.0/10,%v6:fd00::/8,%v6:fe80::/10

conn vpn
        left=10.255.255.2
        leftsubnet=10.250.14.0/24
        right=1.1.2.12
 
rightsubnets={172.16.78.0/24,172.20.129.0/24,10.250.0.0/19,172.21.160.0/23}
        keyexchange=ike
        ike=aes256-sha2_256;modp1536
        sha2-truncbug=no
        ikelifetime=28800s
        authby=secret
        phase2=esp
        phase2alg=aes256-sha2_256;modp1536
        salifetime=3600s
        pfs=yes
        auto=start

conn vpn174
        left=10.255.255.2
        leftsubnet=10.250.14.0/24
        right=1.1.2.12
        rightsubnet=172.16.74.0/24
        keyexchange=ike
        ike=aes256-sha2_256;modp1536
        sha2-truncbug=no
        ikelifetime=28800s
        authby=secret
        phase2=esp
        phase2alg=aes256-sha2_256;modp1536
        salifetime=3600s
        pfs=yes
        auto=start

The problem is that despite the conns being regularly established, in
erouted state, with STATE_QUICK_[IR]2 (IPsec SA established), the packets
coming from 172.16.74.0/24 (hence belonging to the second conn) are silently
dropped by the kernel. I checked with the remote side admin, and my packets
arrive to him, and he replies.
The really _stunning_ thing about this scenario is that if I switch the
order of the two conns, writing vpn174 before vpn in ipsec.conf, then the
problem disappears (I think the problem possibly moves to another of the
rightsubnets in conn vpn, but I am not able to test them all in a reliable
way, since I do not own the remote gateway).

Note, I made the tests with absolutely no iptables rules. I used the
dropwatch tool to investigate the problem, and when I make a simple "nc -v
-s 10.250.14.254 172.16.74.193 5681" I regularly get:
1 drops at tcp_v4_rcv+87 (0xffffffffb6e5d247)

Obviously, when I switch the two sections, I have no drops.  I had a look in
tcp_v4_rcv, but there are much cases when a drop occurs.

Do you have some advice to solve and/or further investigate the problem?

Thanks in advance, 
Luigi



More information about the Swan mailing list