Server Fault Asked by Tymur Gubayev on January 1, 2022
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.
/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.
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)
Answered by Tymur Gubayev on January 1, 2022
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP