VPN connection is up, but the servers aren’t fully reachable after some time #210
Comments
|
Extract from kernel 6.1.26 LTS changelog :
You might like to try a different kernel. |
|
Thanks for such a prompt reply! 🙏 Oh, another kernel issue. Do you watch this kernel issue? If so, could you notify me if/when it is resolved please! 🙏 I’ve been running May 02 14:26:20 $hostname NetworkManager[851]: <info> [1683030380.9495] device (wlan0): driver supports Access Point (AP) mode
May 02 14:26:20 $hostname NetworkManager[851]: <info> [1683030380.9499] manager: (wlan0): new 802.11 Wi-Fi device (/org/freedesktop/NetworkManager/Devices/3)
May 02 14:26:20 $hostname NetworkManager[851]: <info> [1683030380.9501] device (wlan0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
May 02 14:26:21 $hostname NetworkManager[851]: <info> [1683030381.1858] device (wlan0): set-hw-addr: set MAC address to 11:11:22:33:44:55 (scanning)
May 02 14:26:21 $hostname NetworkManager[851]: <info> [1683030381.5212] device (wlan0): supplicant interface state: internal-starting -> disconnected
May 02 14:26:21 $hostname NetworkManager[851]: <info> [1683030381.5235] device (wlan0): state change: unavailable -> disconnected (reason 'supplicant-available', sys-iface-state: 'managed')
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2113] device (wlan0): Activation: starting connection '$wifi_con_name' (8e344155-c22d-46d3-8f35-00bf345bddf7)
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2114] device (wlan0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2480] device (wlan0): set-hw-addr: reset MAC address to 00:11:22:33:44:55 (preserve)
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2507] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2514] device (wlan0): Activation: (wifi) access point '$wifi_con_name' has security, but secrets are required.
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2514] device (wlan0): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed')
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2537] device (wlan0): supplicant interface state: disconnected -> inactive
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2539] device (wlan0): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed')
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2545] device (wlan0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2550] device (wlan0): Activation: (wifi) connection '$wifi_con_name' has security, and secrets exist. No new secrets needed.
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.2792] device (wlan0): supplicant interface state: inactive -> authenticating
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.3070] device (wlan0): supplicant interface state: authenticating -> associating
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.4214] device (wlan0): supplicant interface state: associating -> completed
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.4215] device (wlan0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network "$wifi_ssid"
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.4226] device (wlan0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.4239] dhcp4 (wlan0): activation: beginning transaction (timeout in 45 seconds)
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.4273] dhcp4 (wlan0): state changed new lease, address=192.168.1.31
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.4366] device (wlan0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.4405] device (wlan0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.4408] device (wlan0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
May 02 14:26:25 $hostname NetworkManager[851]: <info> [1683030385.4429] device (wlan0): Activation: successful, device activated.
May 02 14:27:11 $hostname NetworkManager[851]: <info> [1683030431.1502] vpn[0x5590b5954e00,4ecb50e8-337d-4123-9643-d98ee724343e,"$vpn_con_name"]: starting l2tp
May 02 14:27:21 $hostname NetworkManager[851]: <warn> [1683030441.1903] vpn[0x5590b5954e00,4ecb50e8-337d-4123-9643-d98ee724343e,"$vpn_con_name"]: failed to connect: 'Timeout was reached'
May 02 14:27:24 $hostname NetworkManager[851]: <info> [1683030444.1528] vpn[0x5590b5b81dc0,4ecb50e8-337d-4123-9643-d98ee724343e,"$vpn_con_name"]: starting l2tp
May 02 14:27:30 $hostname NetworkManager[851]: <warn> [1683030450.7039] vpn[0x5590b5b81dc0,4ecb50e8-337d-4123-9643-d98ee724343e,"$vpn_con_name"]: plugin NeedSecrets request #1 failed: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
May 02 14:27:35 $hostname NetworkManager[851]: <info> [1683030455.6693] vpn[0x5590b5aeef40,4ecb50e8-337d-4123-9643-d98ee724343e,"$vpn_con_name"]: starting l2tp
May 02 14:27:45 $hostname NetworkManager[851]: <warn> [1683030465.7295] vpn[0x5590b5aeef40,4ecb50e8-337d-4123-9643-d98ee724343e,"$vpn_con_name"]: failed to connect: 'Timeout was reached'
May 02 14:28:40 $hostname NetworkManager[851]: <info> [1683030520.6785] vpn[0x5590b5bf0bb0,4ecb50e8-337d-4123-9643-d98ee724343e,"$vpn_con_name"]: starting l2tp
May 02 14:28:50 $hostname NetworkManager[851]: <warn> [1683030530.6915] vpn[0x5590b5bf0bb0,4ecb50e8-337d-4123-9643-d98ee724343e,"$vpn_con_name"]: failed to connect: 'Timeout was reached'Update 19 minutes after startup (using However, I have just noticed you explicitly stated that the issue is in |
|
All I did was just look at the changelog file for the current LTS kernel release and searched for ipsec and l2tp. The kernel ChangeLog-6.2.13 file also mentions the same ipsec fix. I'm using kernel-6.2.13-300.fc38 on Fedora 38 and not able to reproduce the issue. I'll try and reproduce the issue on my existing Arch Linux VM tomorrow, I'm going to have to do a lot of updates to get it current. |
|
I am in the middle of downgrade to
Thanks! 🙏 I am not that good at browsing the code and changelogs of the kernel, as I don’t code in C/Rust nor I understand much of such low-level stuff. Basically, I am lost in there, that is why I am grateful you have looked it up for me. 🙏
Yeah, all RHEL-like distros use patched kernels AFAIK and definitely are more rigorously tested than Arch Linux kernels, therefore that kernel might not be affected by this issue (be it a bug in the kernel, or
That’d be awesome! 🙏 |
|
Well, the same behaviour as I described in the OP happened with Note that I switched only the kernels, not the |
|
I've updated my Arch Linux VM to be current, but unable to reproduce this issue. Other people who have been connecting to VPN servers which have the same IP address for the external gateway and PTP host have still been reporting routing issues (not in issues here, but elsewhere), they have had to delete the ppp0 route to the VPN external gateway, e.g. So I think the NetworkManager code still needs to be fixed for the routing issues when the VPN Ext Gateway and PTP host are the same IP address. Here are the relevant locations in the NetworkManager 1.42.6 code where the PTP host and Ext gateway values are obtained (from the values supplied to it by NetworkManager-l2tp):
I think someone with programming skills who is able to reproduce the issue would need to fix |
I had that issue and commented on this in #132, however, it seemed to be resolved for me with Below are my routes. I have removed Docker-related routes. I have commented out routes which are up even when I am not connected to the VPN. # Routes: before connecting to the VPN
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.31 metric 60
default via 192.168.1.1 dev enp0s31f6 proto dhcp src 192.168.1.13 metric 100
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.31 metric 60
192.168.1.0/24 dev enp0s31f6 proto kernel scope link src 192.168.1.13 metric 100
# Routes: during VPN connection (it does not change when the VPN stops behaving as expected)
default dev ppp0 proto static scope link metric 50
# default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.31 metric 60
# default via 192.168.1.1 dev enp0s31f6 proto dhcp src 192.168.1.13 metric 100
$vpn_remote_ip_address dev ppp0 proto kernel scope link src 192.168.100.100
# 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.31 metric 60
# 192.168.1.0/24 dev enp0s31f6 proto kernel scope link src 192.168.1.13 metric 100
192.168.1.1 dev wlan0 proto static scope link metric 50
$vpn_host via 192.168.1.1 dev wlan0 proto static metric 50When I remove the extra route using I believe the issue is related to that issue, but it might not be exactly the same. Here is the output of |
|
The log is useful. The following looks weird in the log output: Normally it would fallback to a defaulting made up arbitrary address of 10.64.64.64 with ppp0 : In the pppd code, for that warning So I'm not sure how you could get something other than But even if it is |
Well, I was not sure where $hostname : my hostname
$vpn_dns_1 : DNS 1 used by the VPN (all comm needs to go through the VPN
and without the DNSes, I would have no Internet access
when I am connected to the VPN)
$vpn_dns_2 : DNS 2 used by the VPN
$vpn_host : VPN server I connect to using L2TP/IPSec
$vpn_remote_ip_address : 10.64.64.64
$wifi_con_name : Wi-Fi connection name
$wifi_ssid : Wi-Fi SSID
$wlan0_mac_address : wirelles network interface MAC addressAnyway, would would happen the the LAN is |
|
Anyway, all works as expected on Fedora Workstation 37 with |
|
On Fedora it is also I've never encountered the |
Give me a moment, I need to reboot my system. Update: Yes, it is the same I have just installed Fedora Workstation 38 (Sway spin) with # journalctl -xe NM_CONNECTION=852aaffa-938e-451a-b623-514482ced0d6 + NM_DEVICE=enp44s0u1u1
May 03 12:14:22 p15lnx-fsway NetworkManager[913]: <info> [1683108862.8886] manager: (enp44s0u1u1): new Ethernet device (/org/freedesktop/NetworkManager/Devices/3)
May 03 12:14:22 p15lnx-fsway NetworkManager[913]: <info> [1683108862.8897] device (enp44s0u1u1): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
May 03 12:14:23 p15lnx-fsway NetworkManager[913]: <info> [1683108863.3379] device (enp44s0u1u1): carrier: link connected
May 03 12:14:23 p15lnx-fsway NetworkManager[913]: <info> [1683108863.3420] device (enp44s0u1u1): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
May 03 12:14:23 p15lnx-fsway NetworkManager[913]: <info> [1683108863.3426] device (enp44s0u1u1): Activation: starting connection 'Wired connection 2' (68b90275-8b2d-326e-8cc4-73bc3c68b722)
May 03 12:14:23 p15lnx-fsway NetworkManager[913]: <info> [1683108863.3426] device (enp44s0u1u1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
May 03 12:14:23 p15lnx-fsway NetworkManager[913]: <info> [1683108863.3428] device (enp44s0u1u1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
May 03 12:14:23 p15lnx-fsway NetworkManager[913]: <info> [1683108863.3518] device (enp44s0u1u1): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
May 03 12:14:23 p15lnx-fsway NetworkManager[913]: <info> [1683108863.3522] dhcp4 (enp44s0u1u1): activation: beginning transaction (timeout in 45 seconds)
May 03 12:14:25 p15lnx-fsway NetworkManager[913]: <info> [1683108865.3536] dhcp4 (enp44s0u1u1): state changed new lease, address=192.168.1.32
May 03 12:14:25 p15lnx-fsway NetworkManager[913]: <info> [1683108865.3577] device (enp44s0u1u1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
May 03 12:14:25 p15lnx-fsway NetworkManager[913]: <info> [1683108865.3588] device (enp44s0u1u1): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
May 03 12:14:25 p15lnx-fsway NetworkManager[913]: <info> [1683108865.3590] device (enp44s0u1u1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
May 03 12:14:25 p15lnx-fsway NetworkManager[913]: <info> [1683108865.3595] device (enp44s0u1u1): Activation: successful, device activated.
May 03 12:15:44 p15lnx-fsway NetworkManager[913]: <info> [1683108944.4627] vpn[0x55828493cf30,852aaffa-938e-451a-b623-514482ced0d6,"$vpn_con_name"]: starting l2tp
May 03 12:15:54 p15lnx-fsway NetworkManager[913]: <warn> [1683108954.4791] vpn[0x55828493cf30,852aaffa-938e-451a-b623-514482ced0d6,"$vpn_con_name"]: failed to connect: 'Timeout was reached'The censored output of
I hope |
|
pppd uses Maybe the L2TP VPN server doesn't have a pool of IP addresses it could provide, if xl2tpd is being used for the VPN server, I believe the configuration option is ip range. Otherwise configure the VPN server to use RADIUS (or something else) to provide the IP address. |
|
I do not manage the VPN server. All I know is that it should be a Zyxel VPN and that it works on Fedora 37, macOS, MS Windows 10+, Android 11 (using the built-in VPN manager). I always get some issues on Arch Linux (which is expected due to its bleeding-edge nature). 😉 |
|
Actually, ATM the VPN connection on Android 11 behaves the same way as in the OP (I tested this directly on the phone using Termux and indirectly on my laptop via VPN Hotspot app, as described in this comment). 🤦♂️ I am thinking of using Fedora (again) as my daily driver just because of this, however, I like many stuff on Arch Linux much more than on Fedora. 🤔 |
|
@dkosovic, did you check the Fedora 38 (Sway) logs I shared with you in this comment? I am not sure what changed between F37 and F38, or the |
|
FYI, F38 (Sway) is a vanilla installation where I only run |
|
The Fedora 38 IPsec connection is failing main mode (phase 1) as the VPN server couldn't agree on using any of the the phase 1 proposals sent to it. From the logs, here are the libreswan proposals that are getting sent: I'm guessing the libreswan proposals are too strong for the VPN server and they couldn't agree on any proposal. For IPsec IKEv1, strongswan still supports modp1024 and that weak algorithm is probably what the VPN server is using. Although you installed strongswan, NetworkManager-l2tp default is libreswan, to use strongswam, remove libreswan with: Unlike other linux distros, Fedora can have both libreswan and strongswan installed at the same time. Also don't forget to remove the blacklisting of the L2TP kernel modules. See the README.md file in this repo for more details. |
|
Okay, after I did you told me now (as you have told me multiple times, but I have forgotten to note it down in my installation script), I am able to connect to the VPN without any issues. Bellow is the script I used. Thanks for the help! 🙏 # Update system packages
sudo dnf -y update
# Install dependencies
# Note: Unlike on other Linux distributions, RHEL-like systems can have both `libreswan` and `strongswan` installed at the same time.
sudo dnf -y remove libreswan
sudo dnf -y install xl2tpd strongswan NetworkManager NetworkManager-l2tp # NetworkManager-l2tp-gnome
# Un-blacklist the L2TP modules
for n in l2tp_netlink l2tp_ppp; do
sudo sed -i "s/^blacklist $n$/# &/g" "/etc/modprobe.d/${n}-blacklist.conf"
done
# Remove some experimental and problematic `strongswan` plugins
# Note: `/etc/strongswan.d/charon` is used on Arch Linux and `/etc/strongswan/strongswan.d/charon` on RHEL-like systems.
if [ -d /etc/strongswan.d/charon ]; do
charon_path='/etc/strongswan.d/charon'
else
charon_path='/etc/strongswan/strongswan.d/charon'
fi
for n in bypass-lan connmark forecast sha3; do
# Note: On Fedora 38, there are no `connmark.conf`, `forecast.conf` and `sha3.conf` files.
if [ -f "$charon_path/$n.conf" ]; then
sudo sed -i 's/load = yes/load = no/' "$charon_path/$n.conf"
fi
done
# Restart `NetworkManager` service
sudo systemctl restart --now NetworkManagerAnyway, I’d like to fix my original issue on Arch Linux if possible. I don’t mean to hurry you or something, take your time. Thanks in advance! 🙏 |
|
Regarding the script you mentioned for the installation on Fedora. Here is the strongswan RPM spec file used to build the RPM: You'll notice the following comment in that RPM spec file: # too broken to enable: --enable-sha3 --enable-rdrand --enable-connmark --enable-forecastThere is no need to re-disable them in your script on Fedora. Unlike other Linux distros, Arch Linux enables all of the experimental strongswan plug-ins, I got the idea from Fedora to disable them on Arch Linux. Regarding the made-up address Where IPv4 manual settings correspond to the following pppd settings:
Set the <local_IP_address> to your current local IP address, set the <remote_IP_address> to something other than |
|
Chances are there is something different between the Arch Linux pppd and the Fedora one:
Both ppp packages have a lot of linux distro bundled files, in particular the ppp scripts that get installed to |
Thanks for the detailed info. 🙏 My installation script checks if the files exists and makes sure the plugins/modules are disabled. Yes, it might be unnecessary, but I’d rather keep the checks in place, so that the script could be cross-platform (although I still need to add commands to install dependencies on using other package managers, at the very least
Yeah, I’ll test it later today.
I think we need to compare the files between the packages, but I believe I won’t have that much time this week. |
|
Regarding the local and remote IP configuration: I am not sure if I configure it correctly, but it fails with All I did is modified the connection as bellow. I have only added nmcli c mod $vpn_con_name vpn.data 'gateway = $vpn_host, ipsec-enabled = yes, \
ipsec-psk = $psk, password-flags = 0, user = $vpn_user, \
ipcp-accept-local = $local_ip, ipcp-accept-remote = $vpn_host'Update I have also tried to add However, I am not sure what should be the format of |
|
I just tried now and used the same netmask as |
@dkosovic, about this error? |
|
Oh, you are using 'ipcp-accept-local' is not a NetworkManager-l2tp property, but a pppd option that is put in the generated ppp-options file. An IPv4 Manual setting with address of I'm starting to suspect the issue might be something else, so wouldn't worry too much about getting the manual IPv4 settings working. Arch Linux is using strongswan 5.9.9, while Fedora 37 & 38 are using 5.9.10 which has some XFRM routes changes. |
Related to #132
@dkosovic, I am not sure what happened, but today I wanted to connect to a L2TP/IPSec VPN after some time (a month?) which worked last time I tried, I have made no config change at all, but now behaves strangely. All I did is upgrade the packages as usual.
Current behaviour:
nmcli c up $vpn_con_nameconnects to the the VPN as expected and the connection never ceases (unless I executenmcli c down $vpn_con_name).nmap.nmaplists no open ports, the website cannot be open, SSH connection cannot be made (Connection refused).Now, the only change I see is that today I have upgraded
networkmanagerto1.42.6-1. I tried to downgrade it to1.42.4-2and1.42.4-1, but the problems are the same. I haven’t tried to downgrade to older versions. As for this packages, I usenetworkmanager-l2tp-git@1.20.6.r3.g6483691-1since 13 Dec 2022. I have noticed thatyay(my AUR helper command) does not know if there is a newnm-l2tpversion (because the package uses Git commits), so I created a BASH script to check if there is a new commit innm-l2tprepository and update the package then. Therefore right now, I have installed version1.20.10.r0.g8760535-1, however, it behaves all the same.Note that I have rebooted my computer after each upgrade/download of each package before testing if the connection works as expected.
I use Arch Linux x86_64 BTW. 😉
The text was updated successfully, but these errors were encountered: