Bug 501829 - nm-openvpn vs. standalone openvpn routes
nm-openvpn vs. standalone openvpn routes
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: NetworkManager-openvpn (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-20 18:03 EDT by Daire Byrne
Modified: 2009-05-21 11:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-21 11:13:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daire Byrne 2009-05-20 18:03:26 EDT
Description of problem:
Although the routes setup by nm-openvpn and vanilla openvpn client are almost the exact same, NetworkManager doesn't give a working connection whereas the openvpn init.d script does.

Version-Release number of selected component (if applicable):
[root@vpn-dbyrne ~]# rpm -qa | grep NetworkManager
NetworkManager-openvpn-0.7.0.99-1.fc11.x86_64
NetworkManager-gnome-0.7.1-4.git20090414.fc11.x86_64
NetworkManager-0.7.1-4.git20090414.fc11.x86_64
NetworkManager-glib-0.7.1-4.git20090414.fc11.x86_64

How reproducible:
Always using a "Password with certificates (TLS)" openvpn connection with an additional TLS key. It broke for me somewhere during an update to Fedora 10 and continues to be a problem in Fedora 11. We have to use the openvpn init.d script instead

Steps to Reproduce:
1. Connect using nm-openvpn
2. Connection is setup but unable to ping anything
  
Actual results:
Unable to ping any hosts with nm-openvpn. Works fine with vanilla openvpn client.

The result of "ip route | sort" with no VPN:
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.76  metric 2
default via 192.168.1.254 dev wlan0  proto static

The result of "ip route | sort" with vanilla openvpn client (working):
172.16.0.0/16 via 192.168.13.133 dev tun0
172.17.0.0/16 via 192.168.13.133 dev tun0
172.18.0.0/16 via 192.168.13.133 dev tun0
192.168.0.0/24 via 192.168.13.133 dev tun0
192.168.10.0/24 via 192.168.13.133 dev tun0
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.76  metric 2
192.168.1.0/24 via 192.168.13.133 dev tun0
192.168.12.0/24 via 192.168.13.133 dev tun0
192.168.13.129 via 192.168.13.133 dev tun0
192.168.13.133 dev tun0  proto kernel  scope link  src 192.168.13.135
192.168.20.166 via 192.168.13.133 dev tun0
192.168.20.204 via 192.168.13.133 dev tun0
192.168.2.0/24 via 192.168.13.133 dev tun0
193.XXX.XXX.XXX via 192.168.1.254 dev wlan0
default via 192.168.13.133 dev tun0

The result of "ip route | sort" with nm-openvpn (not working):
172.16.0.0/16 via 192.168.13.133 dev tun0  proto static
172.17.0.0/16 via 192.168.13.133 dev tun0  proto static
172.18.0.0/16 via 192.168.13.133 dev tun0  proto static
192.168.0.0/24 via 192.168.13.133 dev tun0  proto static
192.168.10.0/24 via 192.168.13.133 dev tun0  proto static
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.76  metric 2
192.168.1.0/24 via 192.168.13.133 dev tun0  proto static
192.168.12.0/24 via 192.168.13.133 dev tun0  proto static
192.168.13.129 via 192.168.13.133 dev tun0  proto static
192.168.13.133 dev tun0  proto kernel  scope link  src 192.168.13.134
192.168.20.166 via 192.168.13.133 dev tun0  proto static
192.168.20.204 via 192.168.13.133 dev tun0  proto static
192.168.2.0/24 via 192.168.13.133 dev tun0  proto static
193.XXX.XXX.XXX via 192.168.1.254 dev wlan0  proto static
default via 192.168.13.133 dev tun0  proto static

The only visible difference in routing is the use of "proto static" in the nm-openvpn case.

Expected results:
It used to work for our openvpn server with the same account details in the early days of Fedora 10 but then broke in some update.

Additional info:
The following error message appears and periodically repeats in the logs for the nm-openvpn case:

nm-openvpn[15525]: write to TUN/TAP : Invalid argument (code=22)

In both cases the resolv.conf is correctly configured. iptables is disabled in both cases.
Comment 1 Daire Byrne 2009-05-21 11:11:03 EDT
*Sigh*

My bad. I forgot to check the lzo compression flag. Everything works fine now.

Bogus bug.

Note You need to log in before you can comment on or make changes to this bug.