[strongSwan] site-to-site vpn tunnel drops exactly every 6 hours : StrongSwan <-> Cisco ASA + 5.1.1 patch did not fix problem

Mon Oct 28 22:27:24 CET 2013

My apologies to basically repost this, but I was hoping someone could double-check my config files below.  I have used the patched dev releases and am experiencing the same behavior as before.

Thanks again.

Izz Abdullah
Senior Systems Engineer
www.wepanow.com<http://www.wepanow.com>

________________________________

From: Izz Abdullah <izz.abdullah at wepanow.com><mailto:izz.abdullah at wepanow.com>
Sent: Tuesday, October 22, 2013 09:21
To: users at lists.strongswan.org<mailto:users at lists.strongswan.org> <users at lists.strongswan.org><mailto:users at lists.strongswan.org>
Subject: Re: [strongSwan] site-to-site vpn tunnel drops exactly every 6 hours : StrongSwan <-> Cisco ASA + 5.1.1 patch did not fix problem

I received an email that issue #317 was fixed in 5.1.1.  I checked out the patch(es) below and although the official release isn't slated until Nov 1, I see those patches in 5.1.1dr4 and decided to remove 5.0.2 rpm and compile dr4 from source to test it that is going to work for us.  I am still getting the same issue.  Here are the logs when it drops (right Public IP has been obscured for privacy reasons):

Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[NET] received packet: from A.B.C.D[4500] to 10.201.1.121[4500] (172 bytes)
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[ENC] parsed ID_PROT request 0 [ SA V V V V ]
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[IKE] received NAT-T (RFC 3947) vendor ID
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[IKE] received FRAGMENTATION vendor ID
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[IKE] A.B.C.D is initiating a Main Mode IKE_SA
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[ENC] generating ID_PROT response 0 [ SA V V V ]
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 15[NET] sending packet: from 10.201.1.121[4500] to A.B.C.D[4500] (140 bytes)
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[NET] received packet: from A.B.C.D[4500] to 10.201.1.121[4500] (304 bytes)
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[ENC] parsed ID_PROT request 0 [ KE No V V V V NAT-D NAT-D ]
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[IKE] received Cisco Unity vendor ID
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[IKE] received XAuth vendor ID
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[ENC] received unknown vendor ID: c9:59:52:a7:a5:50:6f:32:9c:cf:c6:a4:23:ab:26:52
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[ENC] received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[IKE] local host is behind NAT, sending keep alives
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 10[NET] sending packet: from 10.201.1.121[4500] to A.B.C.D[4500] (244 bytes)
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[NET] received packet: from A.B.C.D[4500] to 10.201.1.121[4500] (92 bytes)
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[ENC] parsed ID_PROT request 0 [ ID HASH V ]
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[IKE] received DPD vendor ID
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[CFG] looking for pre-shared key peer configs matching 10.201.1.121...A.B.C.D[A.B.C.D]
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[CFG] selected peer config "univ-tunnel03"
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[IKE] IKE_SA univ-tunnel03[28] established between 10.201.1.121[wepa]...A.B.C.D[A.B.C.D]
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[IKE] scheduling reauthentication in 89400s
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[IKE] maximum IKE_SA lifetime 89940s
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[ENC] generating ID_PROT response 0 [ ID HASH ]
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[NET] sending packet: from 10.201.1.121[4500] to A.B.C.D[4500] (76 bytes)
Oct 22 04:45:49 vpc2-ipsec-1-121 charon: 12[IKE] detected reauth of existing IKE_SA, adopting 1 children
Oct 22 04:45:52 vpc2-ipsec-1-121 charon: 02[NET] sending packet: from 10.201.1.121[4500] to 130.132.2.20[4500] (92 bytes)
Oct 22 04:45:55 vpc2-ipsec-1-121 charon: 01[NET] received packet: from A.B.C.D[4500] to 10.201.1.121[4500] (92 bytes)
Oct 22 04:45:55 vpc2-ipsec-1-121 charon: 01[ENC] parsed INFORMATIONAL_V1 request 3820753939 [ HASH D ]
Oct 22 04:45:55 vpc2-ipsec-1-121 charon: 01[IKE] received DELETE for IKE_SA univ-tunnel03[28]
Oct 22 04:45:55 vpc2-ipsec-1-121 charon: 01[IKE] deleting IKE_SA univ-tunnel03[28] between 10.201.1.121[wepa]...A.B.C.D[A.B.C.D]
Oct 22 04:45:55 vpc2-ipsec-1-121 vpn: - A.B.C.D 172.27.7.0/24 == A.B.C.D -- 10.201.1.121 == 10.201.0.0/22

Here are the relative portions of my ipsec.conf and strongswan.conf files:

#ipsec.conf
config setup
    # I thought I had this set previously to yes...but with the patch, it shouldn't matter right?  worst case it would duplicate the tunnel temporarily during reauth
    uniqueids = no

conn univ-tunnel03
        type=tunnel
        auto=start
        keyexchange=ikev1
        ikelifetime=25h
        lifetime=24h
        margintime=9m
        rekeyfuzz=100%
        authby=secret
        auth=esp
        ike=aes-sha1-modp1024!
        esp=3des-md5!
        left=10.201.1.121
        leftid=wepa
        leftsubnet=10.201.0.0/22
        leftfirewall=yes
        right=A.B.C.D
        rightid=A.B.C.D
        rightsubnet=172.27.7.0/24

# strongswan.conf - strongSwan configuration file which is default - I left the comments for completeness
charon {
        # number of worker threads in charon
        threads = 16
        # send strongswan vendor ID?
        # send_vendor_id = yes
        plugins {
                sql {
                        # loglevel to log into sql database
                        loglevel = -1
                        # URI to the database
                        # database = sqlite:///path/to/file.db
                        # database = mysql://user:password@localhost/database
                }
        }
        # ...
}
pluto {

}
libstrongswan {
        #  set to no, the DH exponent size is optimized
        #  dh_exponent_ansi_x9_42 = no
}

I would greatly appreciate any assistance you can be.  For whatever reason, this is still an issue with me and I am not 100% confident on the configuration except for the ecryption, etc.  When it comes to the lifetime, dpd, rekeyfuzz, I've read the documentation, but am not sure what the best practice would be.  I can open another ticket, but am afraid that I am actually not doing something correct in the above config.  Please note I do not have access to the remote site as our remote endpoint is a customer.  I did assist over the phone on the config so that we could get the PSK set and tunnel up initially, so I may be able to provide some information on the remote.  I do know it is an ASA on the other side, but unsure of the model.  Considering this particular customer, I would like to think it is in the 5500 series.

Izz Abdullah
Senior Systems Engineer
www.wepanow.com<http://www.wepanow.com>

________________________________

From: Martin Willi <martin at strongswan.org><mailto:martin at strongswan.org>
Sent: Monday, September 23, 2013 08:21
To: Izz Abdullah <izz.abdullah at wepanow.com><mailto:izz.abdullah at wepanow.com>
Cc: users at lists.strongswan.org<mailto:users at lists.strongswan.org> <users at lists.strongswan.org><mailto:users at lists.strongswan.org>
Subject: Re: [strongSwan] site-to-site vpn tunnel drops exactly every 6 hours : StrongSwan <-> Cisco ASA

Due to your unique policy and a limitation of our new IKEv1
implementation, this leads to a problem: The uniqueness policy deletes
the old ISAKMP during re-authentication before it can complete.

This is a know issue, and I hope I'll find some time to fix this.

I've pushed a few changes to [1] that should fix the issue when
reauthenticating an IKE_SA having a keep or replace unique policy.

I have tried this but end up with what appears to be multiple tunnels
to the same endpoint after renegotiating the initial tunnel.

With IKEv1, overlapping ISAKMP are hard to avoid. We keep it in certain
situations (reauthentication) where deleting them explicitly can lead to
problems. The ISAKMP SA should get deleted once the hard lifetime times
out; having congruent rekeying parameters on both ends can certainly
help.

Regards
Martin

[1]http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/ikev1-reauth

_______________________________________________
Users mailing list
Users at lists.strongswan.org<mailto:Users at lists.strongswan.org>
https://lists.strongswan.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20131028/9fec696d/attachment.html>