search

nm-l2tp / NetworkManager-l2tp

L2TP and L2TP/IPsec support for NetworkManager
GNU General Public License v2.0
486 stars 83 forks source link

Activation of network connection failed Fedora 35 #181

Closed mjiao closed 2 years ago

mjiao commented 2 years ago

Hello,

I am trying to set up the l2tp/ipsec connection from Fedora35 to the remote server (it works on Win10). Because the remote server accepts modp1024, libreswan and NetworkManager-l2tp were built/installed manually to support that.

Config:

# cat ./NetworkManager/system-connections/Conn.nmconnection
[connection]
id=Conn
uuid=cb8dbbb1-a431-4307-84b0-e3a8bde76b4b
type=vpn
autoconnect=false
permissions=user:abc:;

[vpn]
gateway=vpn.abc.net
ipsec-enabled=yes
ipsec-esp=aes256-sha1,aes128-sha1,3des-sha1
ipsec-pfs=no
machine-auth-type=psk
mru=1400
mtu=1400
password-flags=1
user=abc
user-auth-type=password
service-type=org.freedesktop.NetworkManager.l2tp

[vpn-secrets]
ipsec-psk=ABC

[ipv4]
dns-search=
method=auto
never-default=true

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto
never-default=true

[proxy]

Debug logs:

nm-l2tp[100186] <info>  starting ipsec
Redirecting to: systemctl restart ipsec.service
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: /var/run/nm-l2tp-cb8dbbb1-a431-4307-84b0-e3a8bde76b4b/ipsec.conf
debugging mode enabled
end of file /var/run/nm-l2tp-cb8dbbb1-a431-4307-84b0-e3a8bde76b4b/ipsec.conf
Loading conn cb8dbbb1-a431-4307-84b0-e3a8bde76b4b
starter: left is KH_DEFAULTROUTE
loading named conns: cb8dbbb1-a431-4307-84b0-e3a8bde76b4b
resolving family = IPv4 src = <defaultroute> gateway = <defaultroute> peer 185.55.88.50
  seeking gateway
  query getroute +REQUEST +ROOT +MATCH
  add dst 185.55.99.50 (peer->addr)
  src <unset-address> prefsrc <unset-address> gateway 192.168.178.1 dst <unset-address> dev wlp0s20f3 priority 600 pref -1 table 254
  found gateway (host_nexthop): 192.168.178.1
  please-call-again: src = <defaultroute> gateway = 192.168.178.1
resolving family = IPv4 src = <defaultroute> gateway = 192.168.178.1 peer 185.55.99.50
  seeking prefsrc
  query getroute +REQUEST
  add dst 192.168.178.1 (host->nexthop)
  src <unset-address> prefsrc 192.168.178.52 gateway <unset-address> dst 192.168.178.1 dev wlp0s20f3 priority -1 pref -1 table 254 +cacheinfo +uid
  found prefsrc (host_addr): 192.168.178.52
  success: src = 192.168.178.52 gateway = 192.168.178.1
resolving family = IPv4 src = 185.55.99.50 gateway = <not-set> peer 192.168.178.52
  seeking nothing
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" modecfgdns=<unset>
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" modecfgdomains=<unset>
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" modecfgbanner=<unset>
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" mark=<unset>
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" mark-in=<unset>
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" mark-out=<unset>
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" vti_iface=<unset>
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" redirect-to=<unset>
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" accept-redirect-to=<unset>
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" esp=aes256-sha1,aes128-sha1,3des-sha1
conn: "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" ike=aes256-sha2_256-modp2048,aes256-sha2_256-modp1536,aes256-sha2_256-modp1024,aes256-sha1-modp2048,aes256-sha1-modp1536,aes256-sha1-modp1024,aes256-sha1-ecp_384,aes128-sha1-modp1024,aes128-sha1-ecp_256,3des-sha1-modp2048,3des-sha1-modp1024
002 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b": added IKEv1 connection
nm-l2tp[100186] <info>  Spawned ipsec auto --up script with PID 101360.
002 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: initiating IKEv1 Main Mode connection
102 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: sent Main Mode request
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: ignoring unknown Vendor ID payload [5b 36 2b c8  20 f6 00 07]
104 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: sent Main Mode I2
106 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: sent Main Mode I3
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: ignoring informational payload IPSEC_INITIAL_CONTACT, msgid=00000000, length=28
002 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: Peer ID is ID_IPV4_ADDR: '185.55.99.50'
004 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP1024}
002 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: initiating Quick Mode IKEv1+PSK+ENCRYPT+UP+IKE_FRAG_ALLOW+ESN_NO+ESN_YES {using isakmp#1 msgid:16eaa0bc proposal=AES_CBC_256-HMAC_SHA1_96, AES_CBC_128-HMAC_SHA1_96, 3DES_CBC-HMAC_SHA1_96 pfsgroup=no-pfs}
115 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: sent Quick Mode request
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: NAT-Traversal: received 2 NAT-OA. Ignored because peer is not NATed
025 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: cannot route template policy of IKEv1+PSK+ENCRYPT+UP+IKE_FRAG_ALLOW+ESN_NO+ESN_YES
032 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: state transition function for STATE_QUICK_I1 had internal error
nm-l2tp[100186] <warn>  Could not establish IPsec tunnel.

I have no idea why phase 2 can be established, please help.

mjiao commented 2 years ago

Tested on Fedora27 with older versions of NetworkManger-l2tp and libreswan and it worked:

004 "536c2a5e-f896-4abc-8f17-731c4536479b" #1: STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=3DES_CBC_192 integ=HMAC_SHA1 group=MODP1024}
002 "536c2a5e-f896-4abc-8f17-731c4536479b" #2: initiating Quick Mode PSK+ENCRYPT+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO {using isakmp#1 msgid:fd3cbf28 proposal=defaults pfsgroup=no-pfs}
117 "536c2a5e-f896-4abc-8f17-731c4536479b" #2: STATE_QUICK_I1: initiate
003 "536c2a5e-f896-4abc-8f17-731c4536479b" #2: NAT-Traversal: received 2 NAT-OA. Ignored because peer is not NATed
004 "536c2a5e-f896-4abc-8f17-731c4536479b" #2: STATE_QUICK_I2: sent QI2, IPsec SA established transport mode {ESP/NAT=>0x99905fb9 <0x0a47f62d xfrm=AES_CBC_128-HMAC_SHA1_96 NATOA=none NATD=185.55.99.50:4500 DPD=passive}
nm-l2tp[3420] <info>  Libreswan IPsec tunnel is up.
dkosovic commented 2 years ago

As Fedora 27 is connecting with aes128-sha1 for Quick Mode (phase 2), could try explicitly setting that for the Phase 2 algorithms setting and see if that makes a difference? Maybe the VPN server doesn't like aes256-sha1.

mjiao commented 2 years ago

As Fedora 27 is connecting with aes128-sha1 for Quick Mode (phase 2), could try explicitly setting that for the Phase 2 algorithms setting and see if that makes a difference? Maybe the VPN server doesn't like aes256-sha1.

@dkosovic Thanks for checking on this. After changing the phase2 algorithm to aes256-sha1, the IPsec tunnel still can't establish with exact same logs:

004 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: IKE SA established {auth=PRESHARED_KEY cipher=3DES_CBC_192 integ=HMAC_SHA1 group=MODP1024}
002 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: initiating Quick Mode IKEv1+PSK+ENCRYPT+UP+IKE_FRAG_ALLOW+ESN_NO+ESN_YES {using isakmp#1 msgid:f8f18a1b proposal=AES_CBC_128-HMAC_SHA1_96 pfsgroup=no-pfs}
115 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: sent Quick Mode request
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: NAT-Traversal: received 2 NAT-OA. Ignored because peer is not NATed
025 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: cannot route template policy of IKEv1+PSK+ENCRYPT+UP+IKE_FRAG_ALLOW+ESN_NO+ESN_YES
032 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: state transition function for STATE_QUICK_I1 had internal error
nm-l2tp[180337] <warn>  Could not establish IPsec tunnel
dkosovic commented 2 years ago

Actually I overlooked the following error which I've never seen before :

cannot route template policy of IKEv1+PSK+ENCRYPT+UP+IKE_FRAG_ALLOW+ESN_NO+ESN_YES

that error is mentioned in the following thread : https://www.mail-archive.com/swan@lists.libreswan.org/msg02909.html

Newer versions of NetworkManager-l2tp now explicitly set ikev2=no for compatibility reasons, you'll notice on Fedora 27 for the initiating Quick Mode line there was IKEV1_ALLOW+IKEV2_ALLOW. I'm guessing the VPN server is also running libreswan and it might be configured to use opportunistic connections that don't work with Libreswan clients configured for pure IKEv1. You could try removing the phase 2 algorithms and enabling the IKEv2 checkbox in the IPsec settings and seeing if that makes a difference.

dkosovic commented 2 years ago

Or try commenting out the write_config_option(fd, " ikev2=no\n"); code in src/nm-l2tp-service.c

mjiao commented 2 years ago

Or try commenting out the write_config_option(fd, " ikev2=no\n"); code in src/nm-l2tp-service.c

@dkosovic After enabling ikev2, the phase1 can't pass:

nm-l2tp[309305] <info>  Spawned ipsec auto --up script with PID 316622.
181 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: initiating IKEv2 connection
181 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: sent IKE_SA_INIT request
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: dropping unexpected IKE_SA_INIT message containing INVALID_SYNTAX notification; message payloads: N; missing payloads: SA,KE,Ni
010 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: STATE_V2_PARENT_I1: retransmission; will wait 0.5 seconds for response
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: dropping unexpected IKE_SA_INIT message containing INVALID_SYNTAX notification; message payloads: N; missing payloads: SA,KE,Ni
010 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: STATE_V2_PARENT_I1: retransmission; will wait 1 seconds for response
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: dropping unexpected IKE_SA_INIT message containing INVALID_SYNTAX notification; message payloads: N; missing payloads: SA,KE,Ni
010 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: STATE_V2_PARENT_I1: retransmission; will wait 2 seconds for response
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: dropping unexpected IKE_SA_INIT message containing INVALID_SYNTAX notification; message payloads: N; missing payloads: SA,KE,Ni
010 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: STATE_V2_PARENT_I1: retransmission; will wait 4 seconds for response
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: dropping unexpected IKE_SA_INIT message containing INVALID_SYNTAX notification; message payloads: N; missing payloads: SA,KE,Ni
010 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: STATE_V2_PARENT_I1: retransmission; will wait 8 seconds for response
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: dropping unexpected IKE_SA_INIT message containing INVALID_SYNTAX notification; message payloads: N; missing payloads: SA,KE,Ni
nm-l2tp[309305] <warn>  Timeout trying to establish IPsec connection

Do you know if there is a way to enable IKEV1+IKEV2 for phase2 while using IKEV1 for phase1 (if that makes sense)?

dkosovic commented 2 years ago

Extract from https://[libreswan](https://libreswan.org/man/ipsec.conf.5.html).org/man/ipsec.conf.5.html :

ikev2 Whether to use IKEv1 (RFC 4301) or IKEv2 (RFC 7296) settings to be used. Currently the accepted values are no(the default), signifying only IKEv1 is accepted, or yes, signifying only IKEv2 is accepted. Previous versions allowed the keywords propose or permit that would allow either IKEv1 or IKEv2, but this is no longer supported. The permit option is interpreted as no and the propose option is interpreted as yes. Older versions also supported keyword insist which is now interpreted as yes.

I think the libreswan version that shipped with Fedora 27 defaulted to ikev2=permit, but looks like that is no longer supported with newer libreswan versions.

It might just be a bug between that version of libreswan and whatever the VPN server is using.

Have you tried switching to strongswan? Assuming you built and modified a libreswan RPM, the following should do it :

sudo dnf install strongswan
sudo rpm -e libreswan

Unlike libreswan, modp1024 is still built by default with newer strongswan versions.

I don't know if SELinux causes problems with strongswan and Fedora 35 as I disable SELinux for developer reasons. The strongswan SElinux issues might have been fixed, but if it is still there, the errors would be pretty oblivious looking at the journalctl output.

dkosovic commented 2 years ago

I worked out what the issue was, having leftprotoport=udp/%any creates a template policy with libreswan, I had no idea that the %any wildcard was a template policy.

I've removed leftprotoport=udp/%any in commit# https://github.com/nm-l2tp/NetworkManager-l2tp/commit/a2387d7111e52c1854db8dc557ae2483e8551824

A workaround to not hit the bug is to stop the system xl2tpd with:

sudo systemctl stop xl2tpd.service
systemctl disable xl2tpd.service

I might make a new release of NetworkManager-l2tp with the fix.

mjiao commented 2 years ago

By applying your changes in your commit, it works fine on my Fedora 35 machine. Thanks a lot! @dkosovic 

002 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: Peer ID is ID_IPV4_ADDR: '185.60.00.00'
004 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #1: IKE SA established {auth=PRESHARED_KEY cipher=3DES_CBC_192 integ=HMAC_SHA1 group=MODP1024}
002 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: initiating Quick Mode IKEv1+PSK+ENCRYPT+UP+IKE_FRAG_ALLOW+ESN_NO+ESN_YES {using isakmp#1 msgid:8e09388d proposal=AES_CBC_256-HMAC_SHA1_96, AES_CBC_128-HMAC_SHA1_96, 3DES_CBC-HMAC_SHA1_96 pfsgroup=no-pfs}
115 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: sent Quick Mode request
003 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: NAT-Traversal: received 2 NAT-OA. Ignored because peer is not NATed
004 "cb8dbbb1-a431-4307-84b0-e3a8bde76b4b" #2: IPsec SA established transport mode {ESPinUDP=>0x759076ec <0xc8f4c0d5 xfrm=AES_CBC_256-HMAC_SHA1_96 NATD=185.62.88.50:4500 DPD=passive}
nm-l2tp[72646] <info>  Libreswan IPsec tunnel is up.
** Message: 01:15:33.689: xl2tpd started with pid 75879
xl2tpd[75879]: Not looking for kernel SAref support.
xl2tpd[75879]: Using l2tp kernel support.
xl2tpd[75879]: xl2tpd version xl2tpd-1.3.16 started on fedora PID:75879