Closed meatballs closed 4 years ago
I can't see anything obvious.
For strongswan, I would recommend using the exclamation mark with phase 1 & 2, i.e. 3des-sha1-modp1024!
and 3des-sha1!
, otherwise you are not overriding the phase 1 & 2 proposals, merely concatenating with the existing ones.
Although it has received NAT-T (RFC 3947) vendor ID, so I believe strongswan should automatically be doing RFC 3947 encapsulation (i.e. UDP Encapsulated Transport) for NAT traversal, you could try explicitly enabling "Enforce UDP encapsulation" in the IPsec Options dialog box.
Some people have had luck switching from strongswan to libreswan (but be sure to remove the exclamation marks from phase 1 & 2 as it is a syntax error and not required). To switch to libreswan, the following should be enough:
sudo killall -TERM nm-l2tp-service
sudo apt install libreswan
Many thanks for the very swift response.
I can't see anything obvious.
Well, it's always good to know I'm not being a complete idiot!
For strongswan, I would recommend using the exclamation mark with phase 1 & 2, i.e. 3des-sha1-modp1024! and 3des-sha1!, otherwise you are not overriding the phase 1 & 2 proposals, merely concatenating with the existing ones.
I've now tried that and it still fails at the same point.
Although it has received NAT-T (RFC 3947) vendor ID, so I believe strongswan should automatically be doing RFC 3947 encapsulation (i.e. UDP Encapsulated Transport) for NAT traversal, you could try explicitly enabling "Enforce UDP encapsulation" in the IPsec Options dialog box.
I've now tried this too. It still fails at the same point.
Some people have had luck switching from strongswan to libreswan (but be sure to remove the exclamation marks from phase 1 & 2 as it is a syntax error and not required).
This still fails at the same point, but the debug has slightly more info:
nm-l2tp[12455] <info> starting ipsec
Redirecting to: systemctl restart ipsec.service
002 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: deleting state (STATE_MAIN_I3) aged 32.515s and NOT sending notification
002 listening for IKE messages
002 forgetting secrets
002 loading secrets from "/etc/ipsec.secrets"
002 loading secrets from "/etc/ipsec.d/ipsec.nm-l2tp.secrets"
opening file: /run/nm-l2tp-320808d3-4a33-4036-badd-cda84d5a5e12/ipsec.conf
debugging mode enabled
end of file /run/nm-l2tp-320808d3-4a33-4036-badd-cda84d5a5e12/ipsec.conf
Loading conn 320808d3-4a33-4036-badd-cda84d5a5e12
starter: left is KH_DEFAULTROUTE
loading named conns: 320808d3-4a33-4036-badd-cda84d5a5e12
seeking_src = 1, seeking_gateway = 1, has_peer = 1
seeking_src = 0, seeking_gateway = 1, has_dst = 1
dst via 192.168.1.1 dev enp34s0 src table 254
set nexthop: 192.168.1.1
dst 169.254.0.0 via dev enp34s0 src table 254
dst 192.168.1.0 via dev enp34s0 src 192.168.1.224 table 254
dst 127.0.0.0 via dev lo src 127.0.0.1 table 255 (ignored)
dst 127.0.0.0 via dev lo src 127.0.0.1 table 255 (ignored)
dst 127.0.0.1 via dev lo src 127.0.0.1 table 255 (ignored)
dst 127.255.255.255 via dev lo src 127.0.0.1 table 255 (ignored)
dst 192.168.1.0 via dev enp34s0 src 192.168.1.224 table 255 (ignored)
dst 192.168.1.224 via dev enp34s0 src 192.168.1.224 table 255 (ignored)
dst 192.168.1.255 via dev enp34s0 src 192.168.1.224 table 255 (ignored)
seeking_src = 1, seeking_gateway = 0, has_peer = 1
seeking_src = 1, seeking_gateway = 0, has_dst = 1
dst 192.168.1.1 via dev enp34s0 src 192.168.1.224 table 254
set addr: 192.168.1.224
seeking_src = 0, seeking_gateway = 0, has_peer = 1
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" modecfgdns=<unset>
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" modecfgdomains=<unset>
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" modecfgbanner=<unset>
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" mark=<unset>
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" mark-in=<unset>
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" mark-out=<unset>
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" vti_iface=<unset>
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" redirect-to=<unset>
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" accept-redirect-to=<unset>
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" esp=3des-sha1
conn: "320808d3-4a33-4036-badd-cda84d5a5e12" ike=3des-sha1-modp1024
002 added connection description "320808d3-4a33-4036-badd-cda84d5a5e12"
nm-l2tp[12455] <info> Spawned ipsec auto --up script with PID 13296.
002 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: initiating Main Mode
104 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I1: initiate
106 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I3: sent MI3, expecting MR3
010 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I3: retransmission; will wait 0.5 seconds for response
010 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I3: retransmission; will wait 1 seconds for response
010 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I3: retransmission; will wait 2 seconds for response
010 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I3: retransmission; will wait 4 seconds for response
010 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I3: retransmission; will wait 8 seconds for response
nm-l2tp[12455] <warn> Timeout trying to establish IPsec connection
nm-l2tp[12455] <info> Terminating ipsec script with PID 13296.
nm-l2tp[12455] <warn> Could not establish IPsec tunnel.
(nm-l2tp-service:12455): GLib-GIO-CRITICAL **: 15:20:20.917: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
010 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I3: retransmission; will wait 16 seconds for response
010 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I3: retransmission; will wait 32 seconds for response
031 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: STATE_MAIN_I3: 60 second timeout exceeded after 7 retransmits. Possible authentication failure: no acceptable response to our first encrypted message
000 "320808d3-4a33-4036-badd-cda84d5a5e12" #1: starting keying attempt 2 of an unlimited number, but releasing whack
I have noticed that PSK in /etc/ipsec.d/ipsec.nm-l2tp.secrets
is not what I entered via the GUI and the same is true at the beginning of the debug log in the 'vpn' section.
I was expecting that to be in plaintext just like the l2tp password. Is that just my misunderstanding?
With newer versions of NetworkManager-l2tp the PSK is base64 encoded and has a 0s
prefix. You could try decoding it (minus the 0s
prefix) to confirm it is correct, e.g.:
$ echo Zm9vCg== | base64 -d
foo
base64 encoding allows PSKs that contain quotes.
It is like the Meraki stops responding during the Phase 1 (main mode) negotiations part way through because it didn't like something. Perhaps there might be something in the logs on the Meraki side.
With libreswan, PFS (perfect forward secrecy) is part of the proposals (but can't remember if it is for phase 1 - main mode or phase 2 - quick mode). You could try disabling PFS (in the IPsec options dialog box), especially if the Meraki was configured not to use PFS. With strongswan there is no way to disable PFS as it tries to determine if it is used.
You could try using libreswan direct from the command-line . The /run/nm-l2tp-320808d3-4a33-4036-badd-cda84d5a5e12/ipsec.conf
file should still be there if you have used sudo /usr/lib/NetworkManager/nm-l2tp-service --debug
(it would normally get deleted if you don't use ---debug
).
Doing a libreswan command-line connection would be like the following :
sudo ipsec restart
sleep 2
sudo ipsec auto --config /run/nm-l2tp-320808d3-4a33-4036-badd-cda84d5a5e12/ipsec.conf --verbose --add 320808d3-4a33-4036-badd-cda84d5a5e12
sudo ipsec auto --up 320808d3-4a33-4036-badd-cda84d5a5e12
sudo ipsec status
When using the command-line, you could replace the base64 encoded PSK in /etc/ipsec.d/ipsec.nm-l2tp.secrets
with plain text, but pretty sure it won't make a difference.
You could try submitting to libreswan issues with the ipsec.conf
file that is being used (but maybe obfuscate any public IP addresses in ipsec.conf) :
they are pretty helpful and know their stuff. I'm really not sure what else to suggest to try..
I forgot to correct you regarding the plaintext l2tp password comment. NetworkManager uses the GNOME Secret Service (libsecret) for VPN passwords, A nm-l2tpd pppd plugin is used to provide pppd the user credentials via D-Bus. (note: xl2tpd starts an instance of pppd).
So if you were to try to do a command-line xl2tpd connection with the the generated xl2tpd.conf
and ppp-options
files (located in /run/nm-l2tp-320...5e1
), it wouldn't work. You would need to strip out the nm-l2tpd pppd plugin in ppp-options
and replace it with user credential lines.
Many thanks for your help. It seems clear that the problem is not with network-manager-l2tp, so I'll close this and follow up elsewhere.
I'm struggling to connect my Ubuntu 19.10 machine to a Meraki VPN. I'm on version 1.2.16 of this library.
Output from
sudo /usr/lib/NetworkManager/nm-l2tp-service --debug
(with the ip address of the vpn server redacted):I've tried using no specification of the Phase 1 and Phase 2 algorithms. I've also checked the advertised algorithms from the server with
ike-scan
:and then explicitly specified
3des-sha1-modp1024
for Phase 1 and3des-sha1
for Phase 1.In each case, it fails at the same point where there is no response to the third packet that's sent.
I've also run a wireshark capture and I can see the first two packets being sent and the response packets coming back.
For the third packet, I can see it being sent, and then being sent again. I can also see (what looks like) a response packet coming back, but it takes much longer to arrive than the previous responses and network manager has already given up by then.
The connection works perfectly from my MacBook, so I'm confident in the user name, password and PSK (and I don't think we're getting that far here anyway).
Does anyone have any pointers on where I go next to troubleshoot this? (My apologies if this is posted in entirely the wrong place).