Bug 1421476

Summary: VPN not working across VLANs
Product: [Fedora] Fedora Reporter: mr-miky <linuxml>
Component: NetworkManager-openvpnAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 25CC: bgalvani, choeger, dcbw, huzaifas, linuxml, lkundrak, steve, thaller
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-12 10:23:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description mr-miky 2017-02-12 15:40:06 UTC
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:

Comment 1 Beniamino Galvani 2017-02-18 14:01:05 UTC
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?

Comment 2 mr-miky 2017-02-19 13:52:55 UTC
(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.

Comment 3 mr-miky 2017-02-19 14:15:53 UTC
in addition to enp2s0 interface it is also wrong the gateway ? it should be ns ?

Comment 4 Beniamino Galvani 2017-02-21 15:52:52 UTC
(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

Comment 5 Fedora End Of Life 2017-11-16 19:39:56 UTC
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.

Comment 6 Fedora End Of Life 2017-12-12 10:23:26 UTC
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.