[Openswan Users] Annoying and intermittent VPN disconnection with Cisco ASA.

Tue May 19 07:20:21 EDT 2015

Hi guys.

Firstly, I would really appreciate some help with this - its something I've been trying to deal with for the last week or so, so here goes.

I have a server hosted in Amazon, it details below.
root at ip-10-99-0-240:/var/log# ipsec --version
Linux Openswan U2.6.43/K3.13.0-44-generic (netkey)
See `ipsec --copyright' for copyright information.

root at ip-10-99-0-240:/var/log# uname -a
Linux ip-10-99-0-240 3.13.0-44-generic #73-Ubuntu SMP Tue Dec 16 00:22:43 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
root at ip-10-99-0-240:/var/log# cat /etc/issue.net 
Ubuntu 14.04.2 LTS

We have a tunnel established to a third party which is a Cisco ASA 55xx device using 3des-md5.  the config i've included at our side the end of the mail. Every day or so the tunnel drops with the ASA (seemingly on our side) for no apparent reason apart from a re-keying issue on the SA /phase 2 side.  this is happening at least every day, if not randomly at no exact time. I have spoken to our third party who are looking into this again, and with Amazon last friday who helped me identify the re-key issue originally which was due to the phase 2 lifetime not matching with the ASA config.  The tunnel facilitates connectivity via an application we use on our network and we get a report from the app (by email alert) as to when the connection to the third party side times out ( The application tries to re-establish the tcp connection for a few minutes but partially fails to reconnect to one of the two servers at the remote end.. 

I have also got bandwidth/snmp monitoring going into Cacti on the same hosts and i do not see any issues with max bandwidth usage (infact its not showing much usage until the tunnel drops at around 9am (pictured)

However since I modified the phase2 SA lifetime issue yesterday (supposedly) the problem has still remained and I'm really none the wiser about how to fix this. I've attached the logs from today's vpn drop (at 08:01 UTC/   9:01 BST)  Is there anything else i can do to identify whats causing the issue ?  

Our third party who administer the Cisco Asa, are going to email me screen shots of the tunnel configs because they have around 50 third party tunnels in place.

Thanks very much in advance.

##### ipsec status ####
000  
000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,1,64} trans={0,1,3072} attrs={0,1,2048} 
000  
000 "idc-dr/1x1": 10.99.0.0/16===10.99.0.240[52.17.104.250]---10.99.0.1...10.99.0.1---198.202.190.103<198.202.190.103>===192.168.30.0/24; erouted; eroute owner: #42
000 "idc-dr/1x1":     myip=10.99.0.240; hisip=unset;
000 "idc-dr/1x1":   ike_life: 86400s; ipsec_life: 86400s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; force_encaps: yes 
000 "idc-dr/1x1":   policy: PSK+ENCRYPT+TUNNEL+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 16,24; interface: eth0; 
000 "idc-dr/1x1":   dpd: action:clear; delay:0; timeout:0;  
000 "idc-dr/1x1":   newest ISAKMP SA: #41; newest IPsec SA: #42; 
000 "idc-dr/1x1":   aliases: idc-dr 
000 "idc-dr/1x1":   IKE algorithm newest: 3DES_CBC_192-MD5-MODP1024
000  
000 #42: "idc-dr/1x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 71259s; newest IPSEC; eroute owner; isakmp#41; idle; import:admin initiate
000 #42: "idc-dr/1x1" esp.e947a46f at 198.202.190.103 esp.f58e8811 at 10.99.0.240 tun.0 at 198.202.190.103 tun.0 at 10.99.0.240 ref=0 refhim=4294901761
000 #41: "idc-dr/1x1":4500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 71519s; newest ISAKMP; lastdpd=8761s(seq in:0 out:0); idle; import:admin initiate
000  
000 10.99.101.90/32:49059 -6-> 192.168.30.26/32:8200 => %hold 0    %acquire-netlink

#######  CPU and RAm usage ######

root at ip-10-99-0-240:/var/log# cat /proc/cpuinfo  |egrep "core|proc|Mhz"
processor	: 0
core id	: 0
cpu cores	: 2
processor	: 1
core id	: 1
cpu cores	: 2
root at ip-10-99-0-240:/var/log# free -h
                   total       used       free     shared    buffers     cached
Mem:          3.9G       1.2G       2.7G       6.2M       196M       685M
-/+ buffers/cache:       337M       3.5G
Swap:           0B         0B         0B

####### Our side. Amazon Ubuntu box, externally nat'd to a public IP.

config setup
#interfaces=%defaultroute
#
plutodebug=all
# This is required for abrtd to work properly
# Note: incorrect SElinux policies might prevent pluto writing the core
dumpdir=/var/run/pluto/
#
# NAT-TRAVERSAL support, see README.NAT-Traversal
nat_traversal=yes
# exclude networks used on server side by adding %v4:!a.b.c.0/24
# It seems that T-Mobile in the US and Rogers/Fido in Canada are
# using 25/8 as "private" address space on their 3G network.
# This range has not been announced via BGP (at least upto 2010-12-21)
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,%v6:fd00::/8,%v6:fe80::/10
# OE is now off by default. Uncomment and change to on, to enable.
#oe=off
# which IPsec stack to use. auto will try netkey, then klips then mast
protostack=netkey
# Use this to log to a file, or disable logging on embedded systems (like openwrt)
#plutostderrlog=/dev/null

    force_keepalive=yes

    keep_alive=60
nhelpers=0
# Add connections here

conn idc-dr
    type=tunnel
#    connaddrfamily=ipv4
    authby=secret
    auto=start
    compress=no
#    ike=3des-md5
#    phase2alg=3des-md5
#    phase2=esp
    ikelifetime=86400s
#    keyexchange=ike
    keylife=28800s
   ## was## keylife=86400s
    keyingtries=%forever
    left=%defaultroute
    leftid=ex.tern.al.250
    leftsubnets=10.99.0.0/16
    leftsourceip=10.99.0.240

    right=198.202.190.103
    rightsubnets=192.168.30.0/24
    rightid=198.202.190.103
    rightnexthop=%defaultroute
    forceencaps=yes
    pfs=no

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20150519/4f8e3c50/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipsec-pluto-Authlog-19thMay.log.zip
Type: application/zip
Size: 228428 bytes
Desc: not available
URL: <http://lists.openswan.org/pipermail/users/attachments/20150519/4f8e3c50/attachment-0001.zip>