Closed alkazap closed 1 year ago
I would try switching from strongswan to libreswan with :
sudo apt install libreswan
I would have thought it was a PSK issue if you didn't mention the PSK was correct, you might have more luck with libreswan.
Edit: removed my comments about using the nm-l2tp PPA which you are already using.
I have tried installing libreswan
but it does not seem to resolve the issue, is there any additional setup needed?
7월 27 21:09:31 NetworkManager[885]: <info> [1627387771.2613] audit: op="connection-activate" uuid="3795692a-8468-49c3-9fde-c0c59c213d16" name="..." pid=1811 uid=1000 result="success"
7월 27 21:09:31 NetworkManager[885]: <info> [1627387771.3014] vpn-connection[0x55bb921da100,3795692a-8468-49c3-9fde-c0c59c213d16,"...",0]: Started the VPN service, PID 3745
7월 27 21:09:31 NetworkManager[885]: <info> [1627387771.3079] vpn-connection[0x55bb921da100,3795692a-8468-49c3-9fde-c0c59c213d16,"...",0]: Saw the service appear; activating connection
7월 27 21:09:31 NetworkManager[885]: <info> [1627387771.3763] vpn-connection[0x55bb921da100,3795692a-8468-49c3-9fde-c0c59c213d16,"...",0]: VPN connection: (ConnectInteractive) reply received
7월 27 21:09:31 nm-l2tp-service[3745]: Check port 1701
7월 27 21:09:31 NetworkManager[3754]: whack: Pluto is not running (no "/run/pluto/pluto.ctl")
7월 27 21:09:31 NetworkManager[3758]: Redirecting to: systemctl restart ipsec.service
7월 27 21:09:32 NetworkManager[885]: <info> [1627387772.3998] manager: (ip_vti0): new Generic device (/org/freedesktop/NetworkManager/Devices/5)
7월 27 21:09:32 NetworkManager[4175]: 002 listening for IKE messages
7월 27 21:09:32 NetworkManager[4175]: 002 Kernel supports NIC esp-hw-offload
7월 27 21:09:32 NetworkManager[4175]: 002 adding interface wlo1/wlo1 (esp-hw-offload=no) 172.30.1.12:500
7월 27 21:09:32 NetworkManager[4175]: 002 adding interface wlo1/wlo1 172.30.1.12:4500
7월 27 21:09:32 NetworkManager[4175]: 002 Kernel supports NIC esp-hw-offload
7월 27 21:09:32 NetworkManager[4175]: 002 adding interface lo/lo (esp-hw-offload=no) 127.0.0.1:500
7월 27 21:09:32 NetworkManager[4175]: 002 adding interface lo/lo 127.0.0.1:4500
7월 27 21:09:32 NetworkManager[4175]: 002 Kernel supports NIC esp-hw-offload
7월 27 21:09:32 NetworkManager[4175]: 002 adding interface lo/lo (esp-hw-offload=no) ::1:500
7월 27 21:09:32 NetworkManager[4175]: 002 loading secrets from "/etc/ipsec.secrets"
7월 27 21:09:32 NetworkManager[4175]: 002 loading secrets from "/etc/ipsec.d/ipsec.nm-l2tp.secrets"
7월 27 21:09:32 NetworkManager[4180]: debugging mode enabled
7월 27 21:09:32 NetworkManager[4180]: end of file /run/nm-l2tp-3795692a-8468-49c3-9fde-c0c59c213d16/ipsec.conf
7월 27 21:09:32 NetworkManager[4180]: Loading conn 3795692a-8468-49c3-9fde-c0c59c213d16
7월 27 21:09:32 NetworkManager[4180]: starter: left is KH_DEFAULTROUTE
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" modecfgdns=<unset>
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" modecfgdomains=<unset>
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" modecfgbanner=<unset>
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" mark=<unset>
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" mark-in=<unset>
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" mark-out=<unset>
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" vti_iface=<unset>
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" redirect-to=<unset>
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" accept-redirect-to=<unset>
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" esp=aes256-sha1,aes128-sha1,3des-sha1
7월 27 21:09:32 NetworkManager[4180]: conn: "3795692a-8468-49c3-9fde-c0c59c213d16" ike=aes256-sha2_256-modp2048,aes256-sha2_256-modp1536,aes256-sha2_256-modp1024,aes256-sha1-modp2048,aes256-sha1-modp15>
7월 27 21:09:32 NetworkManager[4180]: opening file: /run/nm-l2tp-3795692a-8468-49c3-9fde-c0c59c213d16/ipsec.conf
7월 27 21:09:32 NetworkManager[4180]: loading named conns: 3795692a-8468-49c3-9fde-c0c59c213d16
7월 27 21:09:32 NetworkManager[4180]: seeking_src = 1, seeking_gateway = 1, has_peer = 1
7월 27 21:09:32 NetworkManager[4180]: seeking_src = 0, seeking_gateway = 1, has_dst = 1
7월 27 21:09:32 NetworkManager[4180]: dst via 172.30.1.254 dev wlo1 src table 254
7월 27 21:09:32 NetworkManager[4180]: set nexthop: 172.30.1.254
7월 27 21:09:32 NetworkManager[4180]: dst 169.254.0.0 via dev wlo1 src table 254
7월 27 21:09:32 NetworkManager[4180]: dst 172.30.1.0 via dev wlo1 src 172.30.1.12 table 254
7월 27 21:09:32 NetworkManager[4180]: dst 127.0.0.0 via dev lo src 127.0.0.1 table 255 (ignored)
7월 27 21:09:32 NetworkManager[4180]: dst 127.0.0.0 via dev lo src 127.0.0.1 table 255 (ignored)
7월 27 21:09:32 NetworkManager[4180]: dst 127.0.0.1 via dev lo src 127.0.0.1 table 255 (ignored)
7월 27 21:09:32 NetworkManager[4180]: dst 127.255.255.255 via dev lo src 127.0.0.1 table 255 (ignored)
7월 27 21:09:32 NetworkManager[4180]: dst 172.30.1.0 via dev wlo1 src 172.30.1.12 table 255 (ignored)
7월 27 21:09:32 NetworkManager[4180]: dst 172.30.1.12 via dev wlo1 src 172.30.1.12 table 255 (ignored)
7월 27 21:09:32 NetworkManager[4180]: dst 172.30.1.255 via dev wlo1 src 172.30.1.12 table 255 (ignored)
7월 27 21:09:32 NetworkManager[4180]: seeking_src = 1, seeking_gateway = 0, has_peer = 1
7월 27 21:09:32 NetworkManager[4180]: seeking_src = 1, seeking_gateway = 0, has_dst = 1
7월 27 21:09:32 NetworkManager[4180]: dst 172.30.1.254 via dev wlo1 src 172.30.1.12 table 254
7월 27 21:09:32 NetworkManager[4180]: set addr: 172.30.1.12
7월 27 21:09:32 NetworkManager[4180]: seeking_src = 0, seeking_gateway = 0, has_peer = 1
7월 27 21:09:32 NetworkManager[4182]: 002 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: initiating Main Mode
7월 27 21:09:32 NetworkManager[4182]: 104 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: STATE_MAIN_I1: initiate
7월 27 21:09:32 NetworkManager[4182]: 106 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: STATE_MAIN_I2: sent MI2, expecting MR2
7월 27 21:09:32 NetworkManager[4182]: 108 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: STATE_MAIN_I3: sent MI3, expecting MR3
7월 27 21:09:32 NetworkManager[4182]: 002 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: byte at offset 1 (29) of 'ISAKMP Hash Payload'.'reserved' is 0x88 but should have been zero (ignored)
7월 27 21:09:32 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: length of ISAKMP Hash Payload is larger than can fit
7월 27 21:09:32 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: malformed payload in packet
7월 27 21:09:33 NetworkManager[4182]: 010 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: STATE_MAIN_I3: retransmission; will wait 0.5 seconds for response
7월 27 21:09:33 NetworkManager[4182]: 002 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: byte at offset 1 (29) of 'ISAKMP Hash Payload'.'reserved' is 0x8b but should have been zero (ignored)
7월 27 21:09:33 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: length of ISAKMP Hash Payload is larger than can fit
7월 27 21:09:33 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: malformed payload in packet
7월 27 21:09:33 NetworkManager[4182]: 010 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: STATE_MAIN_I3: retransmission; will wait 1 seconds for response
7월 27 21:09:33 NetworkManager[4182]: 002 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: byte at offset 1 (29) of 'ISAKMP Hash Payload'.'reserved' is 0x15 but should have been zero (ignored)
7월 27 21:09:33 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: length of ISAKMP Hash Payload is larger than can fit
7월 27 21:09:33 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: malformed payload in packet
7월 27 21:09:34 NetworkManager[4182]: 010 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: STATE_MAIN_I3: retransmission; will wait 2 seconds for response
7월 27 21:09:34 NetworkManager[4182]: 002 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: byte at offset 1 (29) of 'ISAKMP Hash Payload'.'reserved' is 0xea but should have been zero (ignored)
7월 27 21:09:34 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: length of ISAKMP Hash Payload is larger than can fit
7월 27 21:09:34 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: malformed payload in packet
7월 27 21:09:36 NetworkManager[4182]: 010 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: STATE_MAIN_I3: retransmission; will wait 4 seconds for response
7월 27 21:09:36 NetworkManager[4182]: 002 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: byte at offset 1 (29) of 'ISAKMP Hash Payload'.'reserved' is 0x91 but should have been zero (ignored)
7월 27 21:09:36 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: length of ISAKMP Hash Payload is larger than can fit
7월 27 21:09:36 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: malformed payload in packet
7월 27 21:09:40 NetworkManager[4182]: 010 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: STATE_MAIN_I3: retransmission; will wait 8 seconds for response
7월 27 21:09:40 NetworkManager[4182]: 002 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: byte at offset 1 (29) of 'ISAKMP Hash Payload'.'reserved' is 0x62 but should have been zero (ignored)
7월 27 21:09:40 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: length of ISAKMP Hash Payload is larger than can fit
7월 27 21:09:40 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: malformed payload in packet
7월 27 21:09:42 nm-l2tp-service[3745]: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
7월 27 21:09:42 NetworkManager[885]: <info> [1627387782.8831] vpn-connection[0x55bb921da100,3795692a-8468-49c3-9fde-c0c59c213d16,"...",0]: VPN plugin: state changed: stopped (6)
7월 27 21:09:42 NetworkManager[885]: <info> [1627387782.8897] vpn-connection[0x55bb921da100,3795692a-8468-49c3-9fde-c0c59c213d16,"...",0]: VPN service disappeared
7월 27 21:09:42 NetworkManager[885]: <warn> [1627387782.8909] vpn-connection[0x55bb921da100,3795692a-8468-49c3-9fde-c0c59c213d16,"...",0]: VPN connection: failed to connect: 'Message recipient>
7월 27 21:09:48 NetworkManager[4182]: 010 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: STATE_MAIN_I3: retransmission; will wait 16 seconds for response
7월 27 21:09:48 NetworkManager[4182]: 002 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: byte at offset 1 (29) of 'ISAKMP Hash Payload'.'reserved' is 0x98 but should have been zero (ignored)
7월 27 21:09:48 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: length of ISAKMP Hash Payload is larger than can fit
7월 27 21:09:48 NetworkManager[4182]: 003 "3795692a-8468-49c3-9fde-c0c59c213d16" #1: malformed payload in packet
Seems like its still a PSK issue but same PSK works with Win10 VPN and worked on Ubuntu 18.04, I am not a server admin, but if you give any suggestions I will talk to the admin about VPN server settings. I don't really know much about it and they didn't seem to know what could be causing this issue on Ubuntu...
Could you try clicking "Enforce UDP encapsulation" in the IPsec advanced options?
Still same issue and same output, could a special character &
in PSK cause it? [Edit: it should be fine]
By the way, thank you for replying so fast
When I look into /etc/ipsec.d/ipsec.nm-l2tp.secret
there's a line
: PSK ...
But the string doesn't match my PSK, is it encrypted or should I overwrite it? how is this file generated?
The string is base64 encoded and should start with 0s
, the base64 encoding should handle special characters. You could try the following on the command-line but with your PSK to see what the base64 encoding looks like :
echo -n 'my-psk' | base64
base64 --decode
can be used to do the reverse.
Thank you for explaining... and ugh it matches... lol hmmm could it be NT Domain problem or do I need to enter Remote ID (not sure what either one should be, I put the group name in NT Domain, which worked before...)
The NT Domain field is equivalent to entering DOMAIN\username
for the username. It is not use for the IPsec connection, but later with the L2TP connection after the IPsec connection is established first.
If you use Remote ID, /etc/ipsec.d/ipsec.nm-l2tp.secret
will look like :
Remote-ID : PSK ...
Generally the Remote ID is used if there is some error about Peer ID.
From the logs it looks at the following two files for the PSK:
/etc/ipsec.secrets
/etc/ipsec.d/ipsec.nm-l2tp.secrets
The /etc/ipsec.d/ipsec.nm-l2tp.secrets
file gets overwritten/re-created every time the VPN connection is attempted.
You can add a new PSK to the /etc/ipsec.secrets
file without worrying if it will be overwritten.
The PSK format in clear text is just:
: PSK "MyPSK"
Thank you. Since the PSK is correct I have no idea what could cause a mismatch error...
I can't see anything obvious that could be wrong.
One other thing you could try is to enable IKEv2 in the IPsec advance config.
Actually I've been reading the following and got some ideas :
Where they claim it is a misconfiguration of the IKE parameter (i.e. phase 1), it might be offering too many proposals for the VPN server. After reverting the other IPsec advanced options, you could try setting phase 1 algorithms to only offer a few algorithms, e.g. if using libreswan, try:
3des-sha1-modp2048,3des-sha1-modp1024
Thank you once again, just tried but still no luck
With libreswan, you could try running sudo ipsec verify
which performs some checks on your computer to see if there are any IPsec issues. You might need to run sudo ipsec start
first.
Being Ubuntu, could be a AppArmor issue, could try temporarily stopping AppArmor. journalctl
might show some non-NetworkManager errors.
Could be a firewall issue if you enabled a firewall.
I'm at a loss as to what else to try.
sudo ipsec verify
gives me this output:
Verifying installed system and configuration files
Version check and ipsec on-path [OK]
Libreswan 3.29 (netkey) on 5.8.0-63-generic
Checking for IPsec support in kernel [OK]
NETKEY: Testing XFRM related proc values
ICMP default/send_redirects [NOT DISABLED]
Disable /proc/sys/net/ipv4/conf/*/send_redirects or NETKEY will act on or cause sending of bogus ICMP redirects!
ICMP default/accept_redirects [NOT DISABLED]
Disable /proc/sys/net/ipv4/conf/*/accept_redirects or NETKEY will act on or cause sending of bogus ICMP redirects!
XFRM larval drop [OK]
Pluto ipsec.conf syntax [OK]
Checking rp_filter [OK]
Checking that pluto is running [OK]
Pluto listening for IKE on udp 500 [OK]
Pluto listening for IKE/NAT-T on udp 4500 [OK]
Pluto ipsec.secret syntax [OK]
Checking 'ip' command [OK]
Checking 'iptables' command [OK]
Checking 'prelink' command does not interfere with FIPS [OK]
Checking for obsolete ipsec.conf options [OBSOLETE KEYWORD]
Traceback (most recent call last):
File "/usr/lib/ipsec/verify", line 393, in <module>
main()
File "/usr/lib/ipsec/verify", line 384, in main
configsetupcheck()
File "/usr/lib/ipsec/verify", line 366, in configsetupcheck
err = err.replace("Warning"," Warning")
TypeError: a bytes-like object is required, not 'str'
Although there is a python syntax error for the "OBSOLETE KEYWORD" keyword check of /etc/ipsec.conf
, not sure what the obsolete keyword is, but doubt it would have an impact.
There was nothing that FAILED with ipsec verify.
+1 on ubuntu 22.04
+1 on ubuntu 22.04
Although an incorrect PSK is the most common problem with the invalid HASH_V1 payload length, decryption failed
error, others have reported issues if the PSK contains a special character like (!
) when a CISCO VPN server is used. e.g. :
Hello, I have used same settings on Ubuntu 18.04, but on Ubuntu 20.04 (newly installed), VPN does not work.
Installation steps:
I used all the settings that worked previously
I've also tried the following:
output of
sudo ./ike-scan.sh ... | grep SA=
:log from
journalctl --no-hostname --unit=NetworkManager
:From here https://docs.netgate.com/pfsense/en/latest/troubleshooting/ipsec.html#phase-1-pre-shared-key-mismatch I found that my log identifies "Phase 1 Pre-Shared Key Mismatch"
But in fact my Pre-Shared Key is correct
I have no idea how to resolve it or what could be the problem, please help.