[Openswan Users] Tunnel goes down then never comes back up

Michael Hubbard michaelh at laine.co.za
Wed Dec 14 04:50:04 EST 2016


Hi,

I'm running OpenSwan on Ubuntu 14.04 for a site-to-site VPN. We have twice managed to get the tunnel up and working but each time it has gone down again shortly after (30-90 minutes after coming up) and then never come back up.

The 2nd time it came up after completely removing and purging Openswan from the system and reinstalling, at which point it wasn't coming up (failing at Phase 2) and after some changes in xl2tpd based on the OpenSwan wiki it suddenly came. Without further input it went down and now won't come up anymore.

It appears to be failing in Phase 2. We've triple checked the config and the remote host is a live system and are adamant their config is correct. The tunnel has come up at some point so it shouldn't be an issue with a config mismatch.

To explain the network topography remote host A sits in front of remote host B, A is connected to the internet. Our server C needs to connect to B. So our server is both establishing the connection and also the system using it, no further subnet. There is no NAT traversal required. If I restart ipsec it just show no tunnels up. If I check the logs there are no errors. If I run ipsec auto -up conn-name it just gets stuck at STATE_QUICK_I1: retransmission.

If I first run ipsec auto -down conn-name and then ipsec auto -verbose -up conn-name I can see what looks to me like Phase 1 is successful. Here is the output:

root at dev ~ # ipsec auto --verbose --up conn-name
002 "easypay-ipsec-vpn" #11: initiating Main Mode
104 "easypay-ipsec-vpn" #11: STATE_MAIN_I1: initiate
003 "easypay-ipsec-vpn" #11: received Vendor ID payload [Dead Peer Detection]
002 "easypay-ipsec-vpn" #11: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
106 "easypay-ipsec-vpn" #11: STATE_MAIN_I2: sent MI2, expecting MR2
002 "easypay-ipsec-vpn" #11: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
108 "easypay-ipsec-vpn" #11: STATE_MAIN_I3: sent MI3, expecting MR3
002 "easypay-ipsec-vpn" #11: Main mode peer ID is ID_IPV4_ADDR: '111.111.111.85'
002 "easypay-ipsec-vpn" #11: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
004 "easypay-ipsec-vpn" #11: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
002 "easypay-ipsec-vpn" #12: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+DONTREKEY+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#11 msgid:dbb4aee3 proposal=3DES(3)_192-SHA1(2)_160 pfsgroup=OAKLEY_GROUP_MODP1024}
117 "easypay-ipsec-vpn" #12: STATE_QUICK_I1: initiate
010 "easypay-ipsec-vpn" #12: STATE_QUICK_I1: retransmission; will wait 20s for response

The IPSec Conf file (removed comments and changed IPs):

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup

        plutodebug=all
        plutostderrlog=/var/log/openswan.log
        dumpdir=/var/run/pluto/
        interfaces=%defaultroute
        nat_traversal=yes
        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=off
        protostack=netkey

conn easypay-ipsec-vpn
        authby=secret
        auto=start
        aggrmode=no
        ike=3des-sha1;modp1024
        ikelifetime=1440m
        ## phase 1 ##

        keyexchange=ike
        rekey=no
        rekeymargin=3m
        keyingtries=%forever

        ## phase 2 ##
        phase2=esp
        phase2alg=3des-sha1;modp1024
        compress=no
        # Perfect Forward Secrecy
        pfs=yes
        type=tunnel
        left=321.321.321.82
        leftsubnet=321.321.321.82/32
        right=123.123.123.85
        rightsubnet=123.123.123.28/24

Output of ipsec verify:

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.38/K3.13.0-105-generic (netkey)
Checking for IPsec support in kernel                            [OK]
SAref kernel support                                           [N/A]
NETKEY:  Testing XFRM related proc values                      [OK]
        [OK]
        [OK]
Checking that pluto is running                                  [OK]
Pluto listening for IKE on udp 500                             [OK]
Pluto listening for NAT-T on udp 4500                          [OK]
Two or more interfaces found, checking IP forwarding        Checking NAT and MASQUERADEing                                      [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]


Syslog from restarting ipsec:

Dec 14 11:47:36 dev ipsec_setup: Stopping Openswan IPsec...
Dec 14 11:47:37 dev kernel: [86214.880112] NET: Unregistered protocol family 15
Dec 14 11:47:37 dev ipsec_setup: ...Openswan IPsec stopped
Dec 14 11:47:37 dev kernel: [86214.938903] NET: Registered protocol family 15
Dec 14 11:47:37 dev ipsec_setup: Starting Openswan IPsec U2.6.38/K3.13.0-105-generic...
Dec 14 11:47:37 dev ipsec_setup: Using NETKEY(XFRM) stack
Dec 14 11:47:37 dev kernel: [86215.022321] Initializing XFRM netlink socket
Dec 14 11:47:37 dev kernel: [86215.088946] AVX2 instructions are not detected.
Dec 14 11:47:37 dev kernel: [86215.114049] AVX2 or AES-NI instructions are not detected.
Dec 14 11:47:37 dev ipsec_setup: ...Openswan IPsec started
Dec 14 11:47:37 dev pluto: adjusting ipsec.d to /etc/ipsec.d
Dec 14 11:47:37 dev ipsec__plutorun: 002 added connection description "conn-name"
Dec 14 11:47:37 dev ipsec__plutorun: 104 "conn-name" #1: STATE_MAIN_I1: initiate

Pluto log is just full of retransmits. No PSK error, nothing else.
The current status is that I am unable to even get the tunnel up, let alone understand why it won't stay up. Any assistance would be greatly appreciated, if any other info is required I will be happy to supply.

Cheers,

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20161214/15e5f47b/attachment-0001.html>


More information about the Users mailing list