Bug 1381037

Summary: Can not establish OpenVPN connection, when connected to internet via Broadband Connection (WWAN)
Product: [Fedora] Fedora Reporter: Petr Novak <petr>
Component: NetworkManager-openvpnAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 24CC: bgalvani, choeger, dcbw, huzaifas, lkundrak, petr, 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-07-21 08:57:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Petr Novak 2016-10-02 16:47:58 UTC 
User-Agent:       Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Build Identifier: 

When computer is connected to internet via WLAN, OpenVPN works fine, but when computer is connected to internet via Broadband Connection, OpenVPN is not working. It seems, that OpenVPN connection is established, I can see "lock symbol" and "ip a s" command lists tun or tap interface, but default gateway is not reachable. Current workaroung is  start openvpn from command line. 

Reproducible: Always

Steps to Reproduce:
1. Disconnect wired connection (LAN) and/or wireless connection (WLAN)
2. Connect to internet via broadband (WWAN)
3. Connect OpenVPN
4. Try to access VPN network
Actual Results:  
Default gateway (configured by OpenVPN client) is inacessible, internet is inacessible.

Expected Results:  
Default gateway (configured by OpenVPN client) should be acessible, internet should be acessible.

NetworkManager-1.2.4-2.fc24.x86_64
NetworkManager-openvpn-1.2.4-2.fc24.x86_64
Comment 1 Beniamino Galvani 2016-10-31 09:28:57 UTC 
Hi,

can you please attach the output of 'ip a; ip r' after the VPN is up but not working and also after connecting using openvpn directly?
Comment 2 Petr Novak 2016-10-31 19:05:05 UTC 
Hi,

not working outputs:


ip a 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether d4:be:d9:88:92:21 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 60:67:20:e1:00:d4 brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 52:54:00:b4:01:23 brd ff:ff:ff:ff:ff:ff
37: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 100.92.111.36/32 brd 100.92.111.36 scope global ppp0
       valid_lft forever preferred_lft forever
39: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.59.11.112/24 brd 10.59.11.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::8df3:6005:e5bb:232f/64 scope link flags 800 
       valid_lft forever preferred_lft forever

ip ro
default via 10.59.11.1 dev tun0  proto static  metric 50 
default dev ppp0  proto static  scope link  metric 700 
10.59.11.0/24 dev tun0  proto kernel  scope link  src 10.59.11.112  metric 50 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 linkdown 


When connected VPN manually from command line (working) state:

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether d4:be:d9:88:92:21 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 60:67:20:e1:00:d4 brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 52:54:00:b4:01:23 brd ff:ff:ff:ff:ff:ff
37: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 100.92.111.36/32 brd 100.92.111.36 scope global ppp0
       valid_lft forever preferred_lft forever
40: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.59.11.112/24 brd 10.59.11.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::9866:771d:3b6d:5baf/64 scope link flags 800 
       valid_lft forever preferred_lft forever


ip ro
default dev ppp0  proto static  scope link  metric 700 
10.0.0.0/8 via 10.59.11.1 dev tun0 
10.59.11.0/24 dev tun0  proto kernel  scope link  src 10.59.11.112 
172.16.0.0/12 via 10.59.11.1 dev tun0 
192.168.0.0/16 via 10.59.11.1 dev tun0 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 linkdown 

Petr
Comment 3 Beniamino Galvani 2016-10-31 19:53:56 UTC 
The difference I see is that NM adds a default route through the VPN, while openvpn adds only routes to some subnets. Maybe that's because you have unchecked the option "Use this connection only for resources in its network" in the VPN connection? Could you try if enabling it makes any difference?

If this doesn't work, can you please increase the logging level with

  nmcli general logging level TRACE

then connect to the VPN with NetworkManager and attach the logs? Thanks!
Comment 4 Petr Novak 2016-10-31 20:48:17 UTC 
Checking "Use this connection only for resources in its network" didn't resolve it. I can not reach resources at VPN network. When I use wifi instead of 3G/4G modem as internet connection, openvpn trough NetworkManager works well.

Here is debug log gathered by journalctl -u NetworkManager:

http://pastebin.com/wQiiQGzS

Greetings,

Petr
Comment 5 Petr Novak 2017-07-21 08:57:30 UTC 
Hello,

some of next releases fixed this bug.

Best regards
Petr