1

I set up a vpn connection according to this instruction - https://www.rapidvpn.com/setup-vpn-l2tp-mint

I establish a vpn connection to my server. The connection is established, but the pings do not go, the pages on the Internet do not open, there is no access to the local network behind the server. As if there are problems with packet routing after I receive the configuration via dhcp from a remote server. After about 60 seconds, the connection is broken.

I’ll make a reservation right away, such a connection to the same server from under Windows or MacOS works without problems. I tried to change the connection to the Internet. The problem is not with the ISP. Replaced the xl2tpd plugin in the network manager with kl2tpd. The problem doesn't go away. Before reinstalling Linux, the vpn client worked.

What is configured wrong on Linux Mint? Logs from the client are attached

Apr 15 20:31:30 LenovoPC charon[10498]: 13[IKE] local host is behind NAT, sending keep alives
Apr 15 20:31:30 LenovoPC charon[10498]: 14[IKE] IKE_SA 955a0158-8008-45b4-b61b-aae634aad51b[1] established between 192.168.1.100[192.168.1.100]...80.80.33.101[80.80.33.101]
Apr 15 20:31:30 LenovoPC charon[10498]: 15[IKE] CHILD_SA 955a0158-8008-45b4-b61b-aae634aad51b{1} established with SPIs c82f58b7_i ca6daee4_o and TS 192.168.1.100/32[udp/l2f] === 80.80.33.101/32[udp/l2f]
Apr 15 20:31:30 LenovoPC nm-l2tp-service[10469]: strongSwan IPsec connection is up.
Apr 15 20:31:30 LenovoPC pppd[10534]: Using interface ppp0
Apr 15 20:31:30 LenovoPC pppd[10534]: Connect: ppp0 <-->
Apr 15 20:31:30 LenovoPC pppd[10534]: Overriding mtu 1500 to 1400
Apr 15 20:31:30 LenovoPC pppd[10534]: Overriding mru 1500 to mtu value 1400
Apr 15 20:32:12 LenovoPC pppd[10628]: CHAP authentication succeeded
Apr 15 20:32:12 LenovoPC charon[10592]: 07[KNL] 10.100.20.1 appeared on ppp0
Apr 15 20:32:12 LenovoPC charon[10592]: 09[KNL] interface ppp0 activated
pr 15 20:32:12 LenovoPC pppd[10628]: local IP address 10.100.20.1
Apr 15 20:32:12 LenovoPC pppd[10628]: remote IP address 80.80.33.101
Apr 15 20:32:12 LenovoPC NetworkManager[917]: [1681583532.4651] device (ppp0): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
Apr 15 20:32:12 LenovoPC pppd[10628]: primary DNS address 1.1.1.1
Apr 15 20:32:12 LenovoPC pppd[10628]: secondary DNS address 8.8.8.8
Apr 15 20:32:12 LenovoPC NetworkManager[917]: [1681583532.4662] device (ppp0): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'external')
Apr 15 20:32:12 LenovoPC dbus-daemon[753]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.16' (uid=0 pid=917 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Apr 15 20:32:12 LenovoPC NetworkManager[917]: [1681583532.4861] policy: set 'VPN' (ppp0) as default for IPv4 routing and DNS
Apr 15 20:32:12 LenovoPC systemd-resolved[721]: wlp3s0: Bus client set default route setting: no
Apr 15 20:32:12 LenovoPC systemd-resolved[721]: wlp3s0: Bus client reset DNS server list.
Apr 15 20:32:12 LenovoPC systemd-resolved[721]: ppp0: Bus client set default route setting: yes
Apr 15 20:32:12 LenovoPC systemd-resolved[721]: ppp0: Bus client set DNS server list to: 1.1.1.1, 8.8.8.8
Apr 15 20:32:12 LenovoPC nm-dispatcher[10671]: /etc/network/if-up.d/resolved: 12: mystatedir: not found
Apr 15 20:32:28 LenovoPC systemd-resolved[721]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 8.8.8.8.
Apr 15 20:32:33 LenovoPC systemd-resolved[721]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 1.1.1.1.
Apr 15 20:33:10 LenovoPC NetworkManager[10627]: xl2tpd[10627]: check_control: Received out of order control packet on tunnel 56426 (got 2, expected 3)
Apr 15 20:33:10 LenovoPC NetworkManager[10627]: xl2tpd[10627]: handle_control: bad control packet!
Apr 15 20:33:12 LenovoPC NetworkManager[10627]: xl2tpd[10627]: check_control: Received out of order control packet on tunnel 56426 (got 2, expected 3)
Apr 15 20:33:12 LenovoPC NetworkManager[10627]: xl2tpd[10627]: handle_control: bad control packet!
Apr 15 20:33:16 LenovoPC NetworkManager[10627]: xl2tpd[10627]: check_control: Received out of order control packet on tunnel 56426 (got 2, expected 3)
Apr 15 20:33:16 LenovoPC NetworkManager[10627]: xl2tpd[10627]: handle_control: bad control packet!
Apr 15 20:33:40 LenovoPC NetworkManager[10627]: xl2tpd[10627]: Maximum retries exceeded for tunnel 4711. Closing.
Apr 15 20:33:40 LenovoPC NetworkManager[10627]: xl2tpd[10627]: Terminating pppd: sending TERM signal to pid 10628
Apr 15 20:33:40 LenovoPC NetworkManager[10627]: xl2tpd[10627]: Connection 56426 closed to 80.80.33.101, port 1701 (Timeout)
Apr 15 20:33:40 LenovoPC pppd[10628]: Terminating on signal 15
Apr 15 20:33:40 LenovoPC pppd[10628]: Connect time 1.5 minutes.
Bib
  • 2,056
  • 1
  • 4
  • 10
Slava
  • 13
  • 2
  • p.s. Linux Mint 21.1 (Vera), network-manager/jammy-updates,now 1.36.6-0ubuntu2 amd64 [installed] – Slava Apr 16 '23 at 08:54
  • Is the PTP host `80.80.33.101` in the log output also the VPN Ext Gateway? If so, you might have a routing issue, try removing the route after the VPN connection is up with `sudo ip route del 80.80.33.101 dev ppp0` – Douglas Kosovic Apr 17 '23 at 08:53
  • @DouglasKosovic I have already done this and I do not like this solution, because this should always be done after connection. Is it possible to configure the network manager in such a way that it bypasses this problem? Or maybe there is a way to automate the execution of the command to remove the routing after the connection? – Slava Apr 17 '23 at 15:26

1 Answers1

0

As you are already using network-manager-l2tp 1.20.8 from ppa:nm-l2tp/network-manager-l2tp, which provides NetworkManager both the PTP host and Ext Gateway details, it is a routing bug with NetworkManager.

You could try the /etc/ppp/ip-up.d/0001routes ppp script described in the following post:

Alternatively, you could write a command-line script that brings up the VPN connection followed by the route removal, e.g. (replace MyVPN with your VPN connection name):

#! /bin/sh

nmcli con up 'MyVPN' --ask
sudo ip route del 80.80.33.101 dev ppp0

EDIT: Just some added comments, I get mixed messages about if this routing issue (when the VPN Ext Gateway and PTP host are the same IP address) has been fixed with later versions of NetworkManager, seems to be fixed for some, but not for others. If anybody with programming skills who is able to reproduce this issue (I've never encountered it personally) and might want to attempt fixing it, here are the relevant locations in the NetworkManager 1.36.6 code where the PTP host and Ext gateway values are obtained (from the values supplied to it by NetworkManager-l2tp):

NM_VPN_PLUGIN_IP4_CONFIG_PTP :

NM_VPN_PLUGIN_CONFIG_EXT_GATEWAY :

src/core/vpn/nm-vpn-connection.c is where the VPN routes get added and the kernel is queried to add some of the routes.

Douglas Kosovic
  • 186
  • 5
  • Alternatively... `sudo touch /etc/network/if-up.d/ifupvpn` `sudo vi /etc/network/if-up.d/ifupvpn` #!/bin/sh if [ "$IFACE" = "ppp0" ]; then ip route del 80.80.33.101 dev ppp0 proto kernel scope link src 10.100.20.1 fi :wq `sudo chmode +x /etc/network/if-up.d/ifupvpn` – Slava Apr 19 '23 at 04:47