[strongSwan] Tunnel failure when bringing interface up/down
Aleksey
unite at openmailbox.org
Fri Apr 17 16:01:57 CEST 2015
On 2015-04-16 18:08, Aleksey wrote:
> 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.
Today I have noticed that in some way the tunnel drop doesn't happen
always - peer ip on SITE2 changes anyway, but tunnels stay up. I have
tested two times - one time tunnels did drop and the other one - did
not. So probably it does not depend on IP address change...
--
With kind regards,
Aleksey
More information about the Users
mailing list