Closed xhpohanka closed 6 years ago
In your IPv4 settings ignore-auto-routes
is set to false, but I don't see the following VPN automatic default route for dev ppp0 which directs all traffic over the VPN connection:
$ ip route
default dev ppp0 proto static scope link metric 50
...
If you are manually adding/removing routes outside of the VPN IPv4 settings GUI and trying to do split network VPN routing, instead of the 192.168.0.0/23 dev ppp0
route I think you need two routes xxx.xxx.xxx.xxx dev ppp0
and 192.168.0.0/23 via xxx.xxx.xxx.xxx
as 192.168.0.0/23 is on the other side of the point-to-point link.
I will check your suggestions, thanks. I'm not sure whether the issue is in routing, I already tried manual and automatic routing but I'll double check...
I changed all routing to default but unfortunately it does not help.
This part of log seems suspicious to me:
pppd[2162]: Plugin pppol2tp.so loaded.
pppd[2162]: Plugin /usr/lib/pppd/2.4.7/nm-l2tp-pppd-plugin.so loaded.
pppd[2162]: pppd 2.4.7 started by root, uid 0
pppd[2162]: Using interface ppp0
pppd[2162]: Connect: ppp0 <-->
pppd[2162]: Overriding mtu 1500 to 1100
pppd[2162]: Overriding mru 1500 to mtu value 1100
NetworkManager[1150]: <info> [1501095313.7915] manager: (ppp0): new Generic device (/org/freedesktop/NetworkManager/Devices/6)
pppd[2162]: Overriding mtu 1400 to 1100
pppd[2162]: PAP authentication succeeded
pppd[2162]: Could not determine remote IP address: defaulting to 10.64.64.64
pppd[2162]: Cannot determine ethernet address for proxy ARP
pppd[2162]: local IP address 192.168.180.1
pppd[2162]: remote IP address 10.64.64.64
pppd[2162]: primary DNS address 192.168.1.9
pppd[2162]: secondary DNS address 192.168.1.11
NetworkManager[1150]: <info> [1501095316.2499] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",0]: VPN connection: (IP4 Config Get) reply received from old-style plugin
NetworkManager[1150]: <info> [1501095316.2503] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: VPN Gateway: xxx.xxx.xxx.xxx
NetworkManager[1150]: <info> [1501095316.2504] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: Tunnel Device: "ppp0"
NetworkManager[1150]: <info> [1501095316.2504] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: IPv4 configuration:
NetworkManager[1150]: <info> [1501095316.2504] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: Internal Address: 192.168.180.1
NetworkManager[1150]: <info> [1501095316.2504] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: Internal Prefix: 32
NetworkManager[1150]: <info> [1501095316.2504] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: Internal Point-to-Point Address: 0.0.0.0
NetworkManager[1150]: <info> [1501095316.2504] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: Maximum Segment Size (MSS): 0
NetworkManager[1150]: <info> [1501095316.2505] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: Forbid Default Route: no
NetworkManager[1150]: <info> [1501095316.2505] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: Internal DNS: 192.168.1.9
NetworkManager[1150]: <info> [1501095316.2505] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: Internal DNS: 192.168.1.11
NetworkManager[1150]: <info> [1501095316.2505] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: DNS Domain: '(none)'
NetworkManager[1150]: <info> [1501095316.2505] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: Data: No IPv6 configuration
NetworkManager[1150]: <info> [1501095316.2506] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: VPN plugin: state changed: started (4)
NetworkManager[1150]: <info> [1501095316.2516] vpn-connection[0x24890d0,61718d08-6663-461d-a847-ad6becdcf94f,"xxx",19:(ppp0)]: VPN connection: (IP Config Get) complete
NetworkManager[1150]: <info> [1501095316.2542] dns-mgr: Writing DNS information to /usr/bin/resolvconf
dbus[474]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
systemd[1]: Starting Network Manager Script Dispatcher Service...
dbus[474]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
systemd[1]: Started Network Manager Script Dispatcher Service.
nm-dispatcher[2388]: req:1 'vpn-up' [ppp0]: new request (1 scripts)
nm-dispatcher[2388]: req:1 'vpn-up' [ppp0]: start running ordered scripts...
pppd[2162]: local IP address 192.168.180.1
is nonsense, I don't know where it came from. I should get something from 192.168.0.0/23
from DHCP.
However pppd[2162]: primary DNS address 192.168.1.9
and pppd[2162]: secondary DNS address 192.168.1.11
are correct, so something can be retrieved from server. It's strange ...
Could the issue be in kernel settings? I have these...
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
I finally managed to get xl2tpd working on my Arch Linux VM, but had to downgrade from xl2tpd 1.3.9 to 1.3.8. The connection would drop out a few seconds after connecting with xl2tpd 1.3.9.
I issued the following and I'm still able to ping a host inside the VPN network :
sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
sudo sysctl -w net.ipv4.conf.all.accept_redirects
sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
sudo sysctl -w net.ipv4.conf.default.accept_redirects=0
sudo sysctl -w net.ipv4.conf.default.send_redirects=0
There was a Linux Kernel regression in 4.11.x line: https://groups.google.com/forum/#!topic/linux.kernel/LLHBfYpkzWg/discussion
Downgrade to Linux-LTS kernel helped me. Also, in my case, I also had to downgrade security restrictions since my VPN server setup seems to only support MD5 or SHA1 hash. (Here is a script which I used to scan the supported IPsec modes: https://github.com/nm-l2tp/network-manager-l2tp/wiki/Known-Issues#querying-vpn-server-for-supported-ipsec-ikev1-ciphers)
Strange, I tried to downgrade xl2tpd and kernel but nothing helped. Automatic routing, manual routing, dhcp, static addres ... no way.
What do you think about the part of log I posted last time? Why I get that wierd default addresses?
@xhpohanka I have no clue, sorry. It works fine on my Arch Linux with Kernel 4.12.3 (and 4.9.40), xl2tpd 1.3.9, networkmanager 1.8.2, networkmanager-l2tp 1.2.8, libreswan 3.20, and Gnome 3.25.4.
Sorry I have no idea how to solve the Cannot determine ethernet address for proxy ARP
error in the logs. I don't understand why it needs the MAC address as the PPP interface (which in this case is created by xl2tpd) has no MAC address. But it could explain the weird default addresses. I assume non-linux VPN clients have no issue connecting, so the issue is on the linux client side.
As no one else has answered since August last year and I'm not able to provide any advise and I don't think it is a network-manager-l2tp bug specifically, I'm almost thinking of closing this issue.
Hi, I agree with you that it is not the buf of network-manager-l2tp. I still live with this on two of my computers, but it works at least a bit. I can access vpn with setting static ip...
Hi, I have strange issue. Connection to vpn is successfuly estabilished, but I cannot ping any IP in vpn network. Can you see something interesting in logs, please? I also do not get address from dhcp, I need to set static one.