Hide Forgot
Description of problem: To connect to the internet I use a connection 802.1Q VLAN over a gigabit connection. Everything works fine until I enable Openvpn connection. Vpn tunnel is established successfully but then the 'end of the tunnel is not accessible and is not even reached the remote OpenVPN server. Before the openvpn connection route report: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default ns 0.0.0.0 UG 400 0 0 enp2s0.1 192.168.10.0 0.0.0.0 255.255.255.0 U 400 0 0 enp2s0.1 NB enp2s0.1 is tagged VLAN id 1 ( enp2s0 is the gigabit ethernet ) After the openvpn connection route report: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default ns 0.0.0.0 UG 400 0 0 enp2s0.1 xx.xx.xx7.1 xx.xx.xx7.17 255.255.255.255 UGH 50 0 0 tun0 xx.xx.xx7.17 0.0.0.0 255.255.255.255 UH 50 0 0 tun0 host26-141-stat 0.0.0.0 255.255.255.255 UH 100 0 0 enp2s0 192.168.4.0 xx.xx.xx7.17 255.255.255.0 UG 50 0 0 tun0 192.168.10.0 0.0.0.0 255.255.255.0 U 400 0 0 enp2s0.1 host26-141-stat is the openvpn server, and 192.168.4.0 is the remote network (I'm connecting as road warrior) Thing that puzzles me is the route added via enp2s0, I suppose serves to ensure that traffic to openvpn server transits across the LAN connection and not through additional connections but then there should be enp2s0.1 VLAN and not the Ethernet physical connection enp2s0. to solve the problem I run: ip route del yy.yy.yy.yy where yy.yy.yy.yy is the ip of host26-141-stat result is: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default ns 0.0.0.0 UG 400 0 0 enp2s0.1 xx.xx.xx7.1 xx.xx.xx7.17 255.255.255.255 UGH 50 0 0 tun0 xx.xx.xx7.17 0.0.0.0 255.255.255.255 UH 50 0 0 tun0 192.168.4.0 xx.xx.xx7.17 255.255.255.0 UG 50 0 0 tun0 192.168.10.0 0.0.0.0 255.255.255.0 U 400 0 0 enp2s0.1 I do not think is the best solution but at least this way I can connect to the VPN server and to the office network. Version-Release number of selected component (if applicable): Fedora 25 upgraded from Fedora 23 How reproducible: Connect via OpenVpn over VLAN ethernet connection Steps to Reproduce: 1. Connect via VLAN 802.1Q 2. Connect to remote lav via networkmanager OpenVpn Actual results: remote peer not reachable, remote server not visible Expected results: Additional info:
I can't reproduce this with NM 1.4.4-3.fc25 in a similar scenario. # ip r default via 3.3.3.3 dev ens8.10 proto static metric 400 3.3.3.0/24 dev ens8.10 proto kernel scope link src 3.3.3.10 metric 400 # nmcli connection up VPN1 VPN connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/5) # ip r default via 3.3.3.3 dev ens8.10 proto static metric 400 3.3.3.0/24 dev ens8.10 proto kernel scope link src 3.3.3.10 metric 400 3.3.3.3 dev ens8.10 proto static scope link metric 400 172.25.100.1 via 172.25.100.21 dev tun111 proto static metric 300 172.25.100.21 dev tun111 proto kernel scope link src 172.25.100.22 metric 300 192.168.222.0/24 via 172.25.100.21 dev tun111 proto static metric 300 In my test the route to the VPN server (3.3.3.3) is added through the tagged interface. Which NM version do you have ('nmcli --version')? Is the host 'host26-141-stat' in the local subnet or not?
(In reply to Beniamino Galvani from comment #1) > In my test the route to the VPN server (3.3.3.3) is added through the > tagged interface. Which NM version do you have ('nmcli --version')? [michele@Phenom-fc25 ~]$ nnmcli --version Strumento nmcli, versione 1.4.4-3.fc25 > Is the host 'host26-141-stat' in the local subnet or not? No is the wan IP of remote office web/vpn server.
in addition to enp2s0 interface it is also wrong the gateway ? it should be ns ?
(In reply to mr-miky from comment #3) > in addition to enp2s0 interface it is also wrong the gateway ? it should be > ns ? Exactly. I tried also the scenario in which the gateway is non-local and all routes were ok. Maybe you could attach NM logs of the connection, if possible at TRACE level [1]? Probably if you don't want to disclose IP address, the log will need some sanitization. [1]: nmcli general logging level TRACE nmcli connection up <my-vpn> ip r > log.txt journalctl -u NetworkManager -s "-60s" >> log.txt
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.