0

I'm setting up VPN connection from firm network to clients. Currently: L2TP VPN. My first step was cloning current router-VM (it's a Hyper-V machine). I then proceeded to configure and experiment with the clone. Once I got the result I wanted, I redid necessary steps on the original. The setup is now identical (beside IP-Address). But for some reason only the clone can connect (and does so consistently), while the original fails almost always -- but did connect once for some reason.

The setup is like this.

  • OS: Debian GNU/Linux 10 (buster)
  • ipsec: Linux strongSwan U5.7.2/K4.19.0-9-amd64
  • xl2tpd: xl2tpd-1.3.12

/etc/ipsec.conf

conn %default
  ikelifetime=60m
  keylife=20m
  rekeymargin=3m
  keyingtries=1
  keyexchange=ikev1
  authby=secret
  ike=3des-sha1-modp1024
  esp=3des-sha1-modp1024

conn vpnTheClient
  keyexchange=ikev1
  left=%defaultroute
  auto=add
  authby=secret
  type=transport
  leftprotoport=17/%any
  rightprotoport=17/%any
  right=10.20.30.40

/etc/ipsec.secrets

  %any 10.20.30.40 : PSK "somestrongstring"

/etc/xl2tpd/xl2tpd.conf

[global]
debug tunnel = yes
debug avp = yes
debug network = yes
debug packet = yes
debug state = yes

[lac vpnTheClient]
lns = 10.20.30.40
ppp debug = yes
pppoptfile = /etc/ppp/options.TheClient.l2tpd
length bit = yes

/etc/ppp/options.TheClient.l2tpd

ipcp-accept-local
ipcp-accept-remote
refuse-eap
require-chap
noccp
noauth
noaccomp
mtu 1280
mru 1280
noipdefault
#defaultroute
nodefaultroute
#usepeerdns
unit 3
connect-delay 5000
name vpnusername
password vpnPasswrd!

Now I do sudo xl2tpd -D from one session and sudo /bin/sh -c 'echo "c vpnTheClient" > /var/run/xl2tpd/l2tp-control' from another.

The original one first failed try looks like following.

xl2tpd[11360]: Not looking for kernel SAref support.
xl2tpd[11360]: Using l2tp kernel support.
xl2tpd[11360]: xl2tpd version xl2tpd-1.3.12 started on debian-router PID:11360
xl2tpd[11360]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
xl2tpd[11360]: Forked by Scott Balmos and David Stipp, (C) 2001
xl2tpd[11360]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[11360]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016
xl2tpd[11360]: Listening on IP address 0.0.0.0, port 1701
xl2tpd[11360]: get_call: allocating new tunnel for host 10.20.30.40, port 1701.
xl2tpd[11360]: Connecting to host 10.20.30.40, port 1701
xl2tpd[11360]: control_finish: message type is (null)(0).  Tunnel is 0, call is 0.
packet dump:
HEX: { C8 02 00 6E 00 00 00 00 00 00 00 00 80 08 00 00 00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 03 80 0A 00 00 00 04 00 00 00 00 00 08 00 00 00 06 06 90 80 13 00 00 00 07 64 65 62 69 61 6E 2D 72 6F 75 74 65 72 00 13 00 00 00 08 78 65 6C 65 72 61 6E 63 65 2E 63 6F 6D 80 08 00 00 00 09 47 7A 80 08 00 00 00 0A 00 04 }
ASCII: {    n                                                          debian-router      xelerance.com      Gz        }
xl2tpd[11360]: control_finish: sending SCCRQ
xl2tpd[11360]: network_thread: select timeout with max retries: 5 for tunnel: 18298
xl2tpd[11360]: network_thread: select timeout with max retries: 5 for tunnel: 18298
xl2tpd[11360]: network_thread: select timeout with max retries: 5 for tunnel: 18298
xl2tpd[11360]: network_thread: select timeout with max retries: 5 for tunnel: 18298
xl2tpd[11360]: network_thread: select timeout with max retries: 5 for tunnel: 18298
xl2tpd[11360]: Maximum retries exceeded for tunnel 18298.  Closing.

Now from clone, the very same settings:

xl2tpd[2299]: Not looking for kernel SAref support.
xl2tpd[2299]: Using l2tp kernel support.
xl2tpd[2299]: xl2tpd version xl2tpd-1.3.12 started on debian-router-copy PID:2299
xl2tpd[2299]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
xl2tpd[2299]: Forked by Scott Balmos and David Stipp, (C) 2001
xl2tpd[2299]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[2299]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016
xl2tpd[2299]: Listening on IP address 0.0.0.0, port 1701
xl2tpd[2299]: get_call: allocating new tunnel for host 10.20.30.40, port 1701.
xl2tpd[2299]: Connecting to host 10.20.30.40, port 1701
xl2tpd[2299]: control_finish: message type is (null)(0).  Tunnel is 0, call is 0.
packet dump:
HEX: { C8 02 00 73 00 00 00 00 00 00 00 00 80 08 00 00 00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 03 80 0A 00 00 00 04 00 00 00 00 00 08 00 00 00 06 06 90 80 18 00 00 00 07 64 65 62 69 61 6E 2D 72 6F 75 74 65 72 2D 63 6F 70 79 00 13 00 00 00 08 78 65 6C 65 72 61 6E 63 65 2E 63 6F 6D 80 08 00 00 00 09 9C 82 80 08 00 00 00 0A 00 04 }
ASCII: {    s                                                          debian-router-copy      xelerance.com
}
xl2tpd[2299]: control_finish: sending SCCRQ
xl2tpd[2299]: network_thread: recv packet from 10.20.30.40, size = 96, tunnel = 40066, call = 0 ref=0 refhim=0
packet dump:
  <etc now everything is working>

Then I tried adding noaccomp to the options, and all of a sudden the original worked.

xl2tpd[11881]: Not looking for kernel SAref support.
xl2tpd[11881]: Using l2tp kernel support.
xl2tpd[11881]: xl2tpd version xl2tpd-1.3.12 started on debian-router PID:11881
xl2tpd[11881]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
xl2tpd[11881]: Forked by Scott Balmos and David Stipp, (C) 2001
xl2tpd[11881]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[11881]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016
xl2tpd[11881]: Listening on IP address 0.0.0.0, port 1701
xl2tpd[11881]: get_call: allocating new tunnel for host 10.20.30.40, port 1701.
xl2tpd[11881]: Connecting to host 10.20.30.40, port 1701
xl2tpd[11881]: control_finish: message type is (null)(0).  Tunnel is 0, call is 0.
packet dump:
HEX: { C8 02 00 6E 00 00 00 00 00 00 00 00 80 08 00 00 00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00 00 03 00 00 00 03 80 0A 00 00 00 04 00 00 00 00 00 08 00 00 00 06 06 90 80 13 00 00 00 07 64 65 62 69 61 6E 2D 72 6F 75 74 65 72 00 13 00 00 00 08 78 65 6C 65 72 61 6E 63 65 2E 63 6F 6D 80 08 00 00 00 09 64 83 80 08 00 00 00 0A 00 04 }
ASCII: {    n                                                          debian-router      xelerance.com      d         }
xl2tpd[11881]: control_finish: sending SCCRQ
xl2tpd[11881]: network_thread: recv packet from 10.20.30.40, size = 96, tunnel = 25731, call = 0 ref=0 refhim=0
packet dump:
  <etc now everything is working>

But only this one time.

Question: how do I debug this thing (I'm only very novice Linux user)? What could possibly be the reason for this? I want to accentuate, the clone has never had any issues connecting -- with exact same config as far as I am aware.

Tymur Gubayev
  • 131
  • 5
  • please may you provide the MTU from both network cards? This is often issue, try to lower the values in your your l2tpd config if it helps. Use one of the commands to find out MTU: ```ipconfig -all``` or ```ip a``` possibly check your network cards using ```ethtool eth0``` i.e. – Geeky Masters Jul 24 '20 at 17:44
  • @GeekyMasters mtu on both `eth0` is 1500. Halving mtu and mru to 640 in the options didn't help. – Tymur Gubayev Jul 24 '20 at 18:03
  • Common places are ```/var/log/daemon```, ```/var/log/syslog```, or ```/var/log/messages``` depends on distribution, for systemd use command ```journalctl -xaf```. You may find good hit in this [answer](https://stackoverflow.com/questions/57547835/strongswan-not-establishing-connection) ensure ports 500 and 4500 are opened on firewall. And check your forwarding as is suggested [here](https://serverfault.com/questions/472111/openswan-and-xl2tpd-tunnel-not-working) – Geeky Masters Jul 24 '20 at 18:14
  • You shall get an answer from the logs or some message which reset or close the connection. Compare your configuration to [this](https://serverfault.com/questions/178309/ipsec-l2tp-vpn-with-osx-client-xl2tpd-reports-maximum-retries-exceeded), you can find there how to add ```debug``` in ```/etc/ppp/options.TheClient.l2tpd``` the client and there are few other things. And may you please double check on both servers (ikev1 is obsolete) in your ipsec.conf: ```ike=3des-sha1-modp1024 esp=3des-sha1-modp1024 keyexchange=ikev1``` – Geeky Masters Jul 24 '20 at 18:30
  • @GeekyMasters ports seem open, `strongswan` sends keepalive packages; `ipsec ip vpnTheClient` also reports "connected". `/proc/sys/net/ipv4/ip_forward` is 1; `accept_redirects` and `send_redirects` are identical between original and should be working... Interestingly in `/var/log/messages` there are no entries from `pppd` after I initiate connection, while on the clone there are. For me it looks like for some reason `xl2tpd` can't start `pppd`. – Tymur Gubayev Jul 24 '20 at 18:30
  • for now main thing is to enable debugging in all services, than you shall get the error message in logs and it shall be "easy" from there. – Geeky Masters Jul 24 '20 at 18:31
  • `xl2tpd`-debugging is done via those `debug xxx = yes` and `ppp debug = yes` -- I did this. It fills `xl2tpd -D` with more info; I don't know where else could I look. The cryptography setting in `ipsec.conf` may be obsolete, but they do work on the clone. The thing is, `xl2tpd` doesn't get to the `start_pppd` point (it happens few packet exchanges later from the SCCRQ). – Tymur Gubayev Jul 24 '20 at 18:40
  • in the options.l2tpd.client the values ```refuse-eap``` and ```require-chap```, try to add ```refuse-chap``` and ```require-mschap-v2```. May you provide the OS on your client and on your server (is it WIndows to where you are trying to connect?). – Geeky Masters Jul 24 '20 at 18:44
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/110991/discussion-between-geeky-masters-and-tymur-gubayev). – Geeky Masters Jul 24 '20 at 18:45

1 Answers1

0

From https://linux.die.net/man/5/ipsec.conf :

leftprotoport allowed protocols and ports over connection, also called Port Selectors. The argument is in the form protocol, which can be a number or a name that will be looked up in /etc/protocols, such as leftprotoport=icmp, or in the form of protocol/port, such as tcp/smtp. Ports can be defined as a number (eg. 25) or as a name (eg smtp) which will be looked up in /etc/services. A special keyword %any can be used to allow all ports of a certain protocol.

It turns out, it's not working as expected (by me).

With leftprotoport=17/%any in ipsec.conf the ipsec connection comes up, but subsequent ppp doesn't.

Replacing it with leftprotoport=17/1701 fixes the issue (after mandatory restart of ipsec).

I also find it interesting, that in ipsec output with %any port it looks like

1.2.3.4/32[udp] === 10.20.30.40/32[udp]

while with 1702 like this

1.2.3.4/32[udp/l2f] === 10.20.30.40/32[udp]

(the port is explicitly specified by name l2f)

Tymur Gubayev
  • 131
  • 5