[strongSwan] Tunnel failure when bringing interface up/down
Aleksey
unite at openmailbox.org
Thu Apr 16 17:08:05 CEST 2015
Hi guys!
I have two sites using strongswan. Both sites run Debian 7.8, however
SITE1 runs strongswan 4.5.2 and SITE2 runs strongswan 5.2.1. SITE1 has
multiple ikev1,ikev2 VPNs to other sites and also there are 3 ikev2
tunnels between SITE1 and SITE2. I noticed the following behaviour -
when I bring up/down an interface (not the one, from which tunnels are
built, just another vlan interface which does not participate in any way
in tunnels) on SITE1, tunnels to SITE2 fail instantly. Other tunnels
built from SITE1 to other sites remain OK (other sites use plenty of
different hardware - mainly mikrotik, cisco, hp. The only ikev2 tunnels
to other site (there are also several tunnels to the same peer with
different subnet) also remains fine - with HP 20-21 Router on the other
side - if it is important).
Three (not one) tunnels are needed because I need to have strict
separation of traffic flowing through all these three tunnels. One of
these three tunnels has two subnets on each side, others two have only
one subnet on left/right side.
So, when I try bringing the tunnel (one of them) back up from SITE1 I
get the following (I'll explain why 5.5.5.5 is used below a bit later):
ipsec down SITE1-SITE2
ipsec up SITE1-SITE2
establishing CHILD_SA SITE1-SITE2
generating CREATE_CHILD_SA request 34 [ SA No TSi TSr ]
sending packet: from 5.5.5.5[4500] to 2.2.2.2[4500]
received packet: from 2.2.2.2[4500] to 5.5.5.5[4500]
parsed CREATE_CHILD_SA response 34 [ N(TS_UNACCEPT) ]
received TS_UNACCEPTABLE notify, no CHILD_SA built
If I try to reestablish it from the SITE2 I get:
ipsec up SITE2-SITE1
establishing CHILD_SA SITE2-SITE1
generating CREATE_CHILD_SA request 36 [ SA No TSi TSr ]
sending packet: from 2.2.2.2[4500] to 5.5.5.5[4500] (348 bytes)
received packet: from 5.5.5.5[4500] to 2.2.2.2[4500] (252 bytes)
parsed CREATE_CHILD_SA response 36 [ SA No TSi TSr ]
unable to install policy 10.100.60.0/24 === 192.168.60.0/24 out (mark
0/0x00000000) for reqid 7, the same policy for reqid 2 exists
unable to install policy 192.168.60.0/24 === 10.100.60.0/24 in (mark
0/0x00000000) for reqid 7, the same policy for reqid 2 exists
unable to install policy 192.168.60.0/24 === 10.100.60.0/24 fwd (mark
0/0x00000000) for reqid 7, the same policy for reqid 2 exists
unable to install policy 10.100.60.0/24 === 192.168.60.0/24 out (mark
0/0x00000000) for reqid 7, the same policy for reqid 2 exists
unable to install policy 192.168.60.0/24 === 10.100.60.0/24 in (mark
0/0x00000000) for reqid 7, the same policy for reqid 2 exists
unable to install policy 192.168.60.0/24 === 10.100.60.0/24 fwd (mark
0/0x00000000) for reqid 7, the same policy for reqid 2 exists
unable to install IPsec policies (SPD) in kernel
failed to establish CHILD_SA, keeping IKE_SA
sending DELETE for ESP CHILD_SA with SPI c454c5b4
generating INFORMATIONAL request 37 [ D ]
sending packet: from 2.2.2.2[4500] to 1.1.1.1[4500] (76 bytes)
received packet: from 1.1.1.1[4500] to 2.2.2.2[4500] (76 bytes)
parsed INFORMATIONAL response 37 [ D ]
deleting policy 10.100.60.0/24 === 192.168.60.0/24 out failed, not found
deleting policy 192.168.60.0/24 === 10.100.60.0/24 in failed, not found
deleting policy 192.168.60.0/24 === 10.100.60.0/24 fwd failed, not found
deleting policy 10.100.60.0/24 === 192.168.60.0/24 out failed, not found
deleting policy 192.168.60.0/24 === 10.100.60.0/24 in failed, not found
deleting policy 192.168.60.0/24 === 10.100.60.0/24 fwd failed, not found
deleting policy 10.100.60.0/24 === 10.0.0.0/16 out failed, not found
deleting policy 10.0.0.0/16 === 10.100.60.0/24 in failed, not found
deleting policy 10.0.0.0/16 === 10.100.60.0/24 fwd failed, not found
deleting policy 10.100.60.0/24 === 10.0.0.0/16 out failed, not found
deleting policy 10.0.0.0/16 === 10.100.60.0/24 in failed, not found
deleting policy 10.0.0.0/16 === 10.100.60.0/24 fwd failed, not found
deleting policy 10.100.0.0/24 === 192.168.60.0/24 out failed, not found
deleting policy 192.168.60.0/24 === 10.100.0.0/24 in failed, not found
deleting policy 192.168.60.0/24 === 10.100.0.0/24 fwd failed, not found
deleting policy 10.100.0.0/24 === 192.168.60.0/24 out failed, not found
deleting policy 192.168.60.0/24 === 10.100.0.0/24 in failed, not found
deleting policy 192.168.60.0/24 === 10.100.0.0/24 fwd failed, not found
deleting policy 10.100.0.0/24 === 10.0.0.0/16 out failed, not found
deleting policy 10.0.0.0/16 === 10.100.0.0/24 in failed, not found
deleting policy 10.0.0.0/16 === 10.100.0.0/24 fwd failed, not found
deleting policy 10.100.0.0/24 === 10.0.0.0/16 out failed, not found
deleting policy 10.0.0.0/16 === 10.100.0.0/24 in failed, not found
deleting policy 10.0.0.0/16 === 10.100.0.0/24 fwd failed, not found
deleting policy 10.100.22.0/24 === 192.168.60.0/24 out failed, not found
deleting policy 192.168.60.0/24 === 10.100.22.0/24 in failed, not found
deleting policy 192.168.60.0/24 === 10.100.22.0/24 fwd failed, not found
deleting policy 10.100.22.0/24 === 192.168.60.0/24 out failed, not found
deleting policy 192.168.60.0/24 === 10.100.22.0/24 in failed, not found
deleting policy 192.168.60.0/24 === 10.100.22.0/24 fwd failed, not found
deleting policy 10.100.22.0/24 === 10.0.0.0/16 out failed, not found
deleting policy 10.0.0.0/16 === 10.100.22.0/24 in failed, not found
deleting policy 10.0.0.0/16 === 10.100.22.0/24 fwd failed, not found
deleting policy 10.100.22.0/24 === 10.0.0.0/16 out failed, not found
deleting policy 10.0.0.0/16 === 10.100.22.0/24 in failed, not found
deleting policy 10.0.0.0/16 === 10.100.22.0/24 fwd failed, not found
To bring the tunnels up again I just do "ipsec restart" on the SITE2 and
all three tunnels are brought up again instantly.
I've searched through the web and have found the bug #397
(https://wiki.strongswan.org/issues/397) and feature #129
(https://wiki.strongswan.org/issues/129). I guess I have an issue
described at this docs, don't I? Is there any workaround? I plan to
update strongswan on SITE1 soon to 5.2.1 but I am afraid that is won't
help in this issue and also am afraid that it might affect other tunnels
which work fine.
Tunnel configuration of SITE1:
conn SITE1-SITE2_3
ikelifetime=8h
keylife=1h
type=tunnel
authby=secret
left=1.1.1.1
leftsubnet=172.16.66.0/24
right=2.2.2.2
rightsubnet=172.24.51.0/24
dpdaction=hold
dpddelay=30
dpdtimeout=150
ike=aes128-sha1-modp1024
esp=aes128-sha1
keyexchange=ikev2
auto=start
conn SITE1-SITE2_2
ikelifetime=8h
keylife=1h
type=tunnel
authby=secret
left=1.1.1.1
leftsubnet=172.16.77.0/24
right=2.2.2.2
rightsubnet=172.24.52.0/24
dpdaction=hold
dpddelay=30
dpdtimeout=150
ike=aes128-sha1-modp1024
esp=aes128-sha1
keyexchange=ikev2
auto=start
conn SITE1-SITE2
ikelifetime=8h
keylife=1h
type=tunnel
authby=secret
left=1.1.1.1
leftsubnet=192.168.60.0/24,10.0.0.0/16
right=2.2.2.2
rightsubnet=10.100.60.0/24,10.100.0.0/24,10.100.22.0/24
dpdaction=hold
dpddelay=30
dpdtimeout=150
ike=aes128-sha1-modp1024
esp=aes128-sha1
keyexchange=ikev2
auto=start
Tunnel configuration of SITE2 is the same except left/right and
leftsubnets/rightsubnets are mirrored.
I know that it might be quite confusing but probably it might be
important. SITE1 box is used as a border router at the same time and has
connection to two ISPs and maintains BGP AS. So, practically, IP address
of 1.1.1.1 is virtual IP assigned to one of non-ISP connected VLANs. The
real IPs that are used to reach ISP's gateway are, let's say 5.5.5.5 for
ISP1 (main) and 172.16.5.5 (connection between my box and second ISP is
built on private IPs) for ISP2 (backup). I've noticed that logs on SITE2
say the following at times of normal operation:
Apr 16 16:32:07 SITE2 charon-custom: 06[NET] sending packet: from
2.2.2.2[4500] to 1.1.1.1[4500] (204 bytes)
Apr 16 16:32:07 SITE2 charon-custom: 09[NET] received packet: from
1.1.1.1[4500] to 2.2.2.2[4500] (76 bytes)
just before tunnels tear up, SITE2 starts receiving the packets from
5.5.5.5 and also receives a notification from SITE1 that IP address is
changed from 1.1.1.1 to 5.5.5.5.
After restart of strongswan tunnels are being initiated using correct IP
of 1.1.1.1.
Any ideas? If some additional logs are needed I can post them here.
Thanks in advance.
--
With kind regards,
Aleksey
More information about the Users
mailing list