Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IKE support not working #6

Open
shankscoder opened this issue Jan 7, 2019 · 5 comments
Open

IKE support not working #6

shankscoder opened this issue Jan 7, 2019 · 5 comments

Comments

@shankscoder
Copy link

shankscoder commented Jan 7, 2019

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.

@ubergarm
Copy link
Owner

ubergarm commented Jan 10, 2019

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:

  • 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
Copy link
Owner

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!

@asterissco
Copy link

asterissco commented Jan 31, 2019

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!

@shankscoder
Copy link
Author

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
Copy link
Author

shankscoder commented Feb 10, 2019

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 shankscoder reopened this Feb 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants