Cannot connect to Meraki Server

[meatballs]

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):

nm-l2tp[13306] <info>  starting ipsec
Stopping strongSwan IPsec failed: starter is not running
Starting strongSwan 5.7.2 IPsec [starter]...
Loading config setup
Loading conn '320808d3-4a33-4036-badd-cda84d5a5e12'
found netkey IPsec stack
nm-l2tp[13306] <info>  Spawned ipsec up script with PID 13886.
initiating Main Mode IKE_SA 320808d3-4a33-4036-badd-cda84d5a5e12[1] to xxx.xxx.xxx.xxx
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.1.224[500] to xxx.xxx.xxx.xxx[500] (236 bytes)
received packet: from xxx.xxx.xxx.xxx[500] to 192.168.1.224[500] (156 bytes)
parsed ID_PROT response 0 [ SA V V V V ]
received XAuth vendor ID
received NAT-T (RFC 3947) vendor ID
received DPD vendor ID
received FRAGMENTATION vendor ID
selected proposal: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.1.224[500] to xxx.xxx.xxx.xxx[500] (244 bytes)
received packet: from xxx.xxx.xxx.xxx[500] to 192.168.1.224[500] (228 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH ]
sending packet: from 192.168.1.224[4500] to xxx.xxx.xxx.xxx[4500] (68 bytes)
sending retransmit 1 of request message ID 0, seq 3
sending packet: from 192.168.1.224[4500] to xxx.xxx.xxx.xxx[4500] (68 bytes)
nm-l2tp[13306] <warn>  Timeout trying to establish IPsec connection
nm-l2tp[13306] <info>  Terminating ipsec script with PID 13886.
Stopping strongSwan IPsec...
destroying IKE_SA in state CONNECTING without notification
establishing connection '320808d3-4a33-4036-badd-cda84d5a5e12' failed
nm-l2tp[13306] <warn>  Could not establish IPsec tunnel.

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:

Main Mode Handshake returned HDR=(CKY-R=2e1ba94e817e803c) SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)

and then explicitly specified 3des-sha1-modp1024 for Phase 1 and 3des-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).

[dkosovic]

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

[meatballs]

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

[meatballs]

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?

[dkosovic]

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.

[dkosovic]

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) :

• https://github.com/libreswan/libreswan/issues

they are pretty helpful and know their stuff. I'm really not sure what else to suggest to try..

[dkosovic]

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.

[meatballs]

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.