l2tp-ipsec-vpn-client icon indicating copy to clipboard operation
l2tp-ipsec-vpn-client copied to clipboard

IKE support not working

Open shankscoder opened this issue 5 years ago • 5 comments

So the shift to libreswan is breaking connections that were previously working with IKE1 support.

We've deployed a few clients using an IPSEC server that exposes only ports 500 and 4500, and they're working fine using the older build.

With the new update, these connections don't work. When I roll back to using the strongswan config, it works out of the box.

I think the libreswan ipsec.conf config is missing something to allow it to connect with existing VPN setups.

shankscoder avatar Jan 07 '19 18:01 shankscoder

Hrm, thanks for letting me know! I don't have access to my old VPN appliance and updated it to work with the new one. The new appliance is still working with IKEv1.

Your setup may need this line explicitly defined to match the handshake expected by the server:

ike=3des-sha1;modp1024

https://github.com/ubergarm/l2tp-ipsec-vpn-client/blob/master/ipsec.conf#L16

In the meantime if you're in a pinch feel free to checkout the older version from this repo and build it from there.

TODO:

  • [x] Me: I'll setup my dockerhub to provide the old version under the tag :strongswan
  • [ ] You: Can you provide a gist of the output and see if it works with modified ipsec.conf?

Thanks!

EDIT: You can now pull the previous strongswan version that is autobuilt from the strongswan github tag from docker hub here:

docker pull ubergarm/l2tp-ipsec-vpn-client:strongswan

ubergarm avatar Jan 10 '19 15:01 ubergarm

I set the default IKEv1 handshake to something common for compatibility but weaker than other IKEv1 supported ciphers/hashes/algorithms.

You can use the ike-scan.sh script to test your VPN server and I recommend using the newest/strongest available and especially disabling aggressive mode if possible (on the server).

Hope one of these options works for your setup!

ubergarm avatar Jan 10 '19 17:01 ubergarm

Hello,

Other options is map de ipsec.conf like that

  • Writte this
$vim /tmp/ipsec.conf
conn L2TP-PSK
    authby=secret
    pfs=no
    auto=add
    rekey=no
    left=%defaultroute
    type=transport
    leftprotoport=17/1701
    rightprotoport=17/1701
    dpddelay=15
    dpdtimeout=30
    dpdaction=clear
    # optionally specify specific IKEv1 encryption/authentication handshake supported by your VPN server e.g:
**#    ike=3des-sha1;modp1024**
    # set this to the ip address of your vpn server:
    right=xxx.xxx.xxx.xxx
  • Writte remote address on "right" and comment "black" line

  • Now, start docker and add this parameter "-v /tmp/ipsec.conf:/etc/ipsec.conf"

  • Set route

And enjoy!

asterissco avatar Jan 31 '19 11:01 asterissco

Cool, thanks @ubergarm @asterissco will check try these out and get back. Closing the issue for now. Will reopen if I have any issues.

shankscoder avatar Feb 03 '19 12:02 shankscoder

Ok, so I tried this out, and here's what's happening.

I cloned the repo and modified the ipsec.conf file as follows:

config setup

conn L2TP-PSK
    authby=secret
    pfs=no
    auto=add
    rekey=no
    left=%defaultroute
    type=transport
    leftprotoport=17/1701
    rightprotoport=17/1701
    dpddelay=15
    dpdtimeout=30
    dpdaction=clear
    # optionally specify specific IKEv1 encryption/authentication handshake supported by your VPN server e.g:
    # ike=3des-sha1;modp1024
    # set this to the ip address of your vpn server:
    right=xxx.xxx.xxx.xxx

I basically took @asterissco's advice and commented out the ike line to avoid explicit definitions of protocols.

I then built the container and ran it. What's weird is that it seems to establish a connection but it's terminating. I suspect there's something going on with the L2TPD config.

Here's my output from Docker logs:

xl2tpd[1]: setsockopt recvref[30]: Protocol not available
xl2tpd[1]: L2TP kernel support not detected (try modprobing l2tp_ppp and pppol2tp)
xl2tpd[1]: xl2tpd version xl2tpd-1.3.10.1 started on pp-smartdns-1 PID:1
xl2tpd[1]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
xl2tpd[1]: Forked by Scott Balmos and David Stipp, (C) 2001
xl2tpd[1]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[1]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016
xl2tpd[1]: Listening on IP address 0.0.0.0, port 1701
xl2tpd[1]: Connecting to host xx.xx.xx.xx, port 1701
xl2tpd[1]: Connection established to xx.xx.xx.xx, 1701.  Local: 7344, Remote: 20100 (ref=0/0).
xl2tpd[1]: Calling on tunnel 7344
xl2tpd[1]: Call established with xx.xx.xx.xx, Local: 44329, Remote: 55019, Serial: 1 (ref=0/0)
xl2tpd[1]: start_pppd: I'm running:
xl2tpd[1]: "/usr/sbin/pppd"
xl2tpd[1]: "/dev/pts/1"
xl2tpd[1]: "passive"
xl2tpd[1]: "nodetach"
xl2tpd[1]: ":"
xl2tpd[1]: "debug"
xl2tpd[1]: "file"
xl2tpd[1]: "/etc/ppp/options.l2tpd.client"
xl2tpd[1]: control_finish: Connection closed to xx.xx.xx.xx, serial 1 ()
xl2tpd[1]: Terminating pppd: sending TERM signal to pid 38
^Cxl2tpd[1]: death_handler: Fatal signal 2 received
xl2tpd[1]: Connection 20100 closed to xx.xx.xx.xx, port 1701 (Server closing)

The VPN service appliance I'm using is this: https://github.com/mobilejazz/docker-ipsec-vpn-server

Here's what we see on the Server end:

xl2tpd[1]: Connection established to xx.xx.xx.xx, 1701.  Local: 20100, Remote: 7344 (ref=0/0).  LNS session is 'default'
xl2tpd[1]: control_finish: Warning: Peer did not specify transmit speed
xl2tpd[1]: start_pppd: I'm running:
xl2tpd[1]: "/usr/sbin/pppd"
xl2tpd[1]: "passive"
xl2tpd[1]: "nodetach"
xl2tpd[1]: "192.168.42.1:192.168.42.11"
xl2tpd[1]: "refuse-pap"
xl2tpd[1]: "auth"
xl2tpd[1]: "require-chap"
xl2tpd[1]: "name"
xl2tpd[1]: "l2tpd"
xl2tpd[1]: "file"
xl2tpd[1]: "/etc/ppp/options.xl2tpd"
xl2tpd[1]: "/dev/pts/1"
xl2tpd[1]: Call established with xx.xx.xx.xx, Local: 55019, Remote: 44329, Serial: 1
xl2tpd[1]: child_handler : pppd exited for call 44329 with code 11
xl2tpd[1]: call_close: Call 55019 to xx.xx.xx.xx disconnected
xl2tpd[1]: Terminating pppd: sending TERM signal to pid 912

I just setup a fresh instance of the VPN server, and my other clients are connecting without any trouble. It's only these Ubuntu server clients that aren't establishing a PPP tunnel. Any help is much appreciated.

~~Strange behaviour now. This isn't working with both the strongswan or the latest tagged versions.~~

Only an issue with Libreswan now.

shankscoder avatar Feb 10 '19 19:02 shankscoder