Bug 806486 - NetworkManager fails to create routes for openvpn connections
Summary: NetworkManager fails to create routes for openvpn connections
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: NetworkManager-openvpn
Version: el6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 809620 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-23 22:55 UTC by Matěj Cepl
Modified: 2018-04-11 13:52 UTC (History)
5 users (show)

Fixed In Version: NetworkManager-0.8.1-29.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-05 14:37:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Matěj Cepl 2012-03-23 22:55:02 UTC
Description of problem:
Sometimes since around RHEL 6.3 NM-openvpn connection gets created but no connection actually exists (even ping to the in-VPN DNS server stalls).

Version-Release number of selected component (if applicable):
NetworkManager-glib-0.8.1-26.el6.x86_64
NetworkManager-gnome-0.8.1-26.el6.x86_64
NetworkManager-openswan-0.8.0-8.el6.x86_64
NetworkManager-openvpn-0.8.1-0.1.git20100609.el6.x86_64
NetworkManager-0.8.1-26.el6.x86_64
openvpn-2.2.1-1.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1.connect with NM-openvpn module
2.connection gets created (lock is attached to the icon)
3.ping <IP address of an internal DNS server>
  
Actual results:
nothing, connection gets stalled

Expected results:
working connection

Additional info:

Comment 3 David Jaša 2012-04-03 19:49:46 UTC
I'm hitting it too, when I add manually the network ranges to the tun0 device, the connection starts working. 

Relevant part of log are these two errors (already in Matěj's attachments), I presume one of them is for each route added:

Apr  3 21:34:18 dhcp-29-7 NetworkManager[10201]: <error> [1333481658.589502] [nm-system.c:187] nm_system_device_set_ip4_route(): (tun0): failed to set IPv4 route: Netlink Error (errno = No such process)
Apr  3 21:34:18 dhcp-29-7 NetworkManager[10201]: <error> [1333481658.589619] [nm-system.c:187] nm_system_device_set_ip4_route(): (tun0): failed to set IPv4 route: Netlink Error (errno = No such process)

and NM marks such route-less connection as complete which is a separate bug IMO:
Apr  3 21:34:18 dhcp-29-7 NetworkManager[10201]: <info> VPN connection 'Red Hat AMS2 OVPN' (IP Config Get) complete.

I'm also wondering if this is bug in NetworkManager proper rather than in NetworkManager-gnome

Comment 4 Matěj Cepl 2012-04-03 19:52:38 UTC
IMHO, the current theory is that it is NM-openvpn which hasn't been updated to work with the current NM.

Comment 5 Dan Winship 2012-04-05 13:45:34 UTC
There was a bug in a Fedora beta at one point where NM-openvpn couldn't get a route if selinux was enabled. Can you check if it's that?

Comment 6 David Jaša 2012-04-05 14:03:20 UTC
(In reply to comment #5)
> There was a bug in a Fedora beta at one point where NM-openvpn couldn't get a
> route if selinux was enabled. Can you check if it's that?

This is not the case, no AVCs are generated when connecting to the openvpn and when I set selinux to permissive mode, the problem does not go away.

Comment 7 Jirka Klimes 2012-04-05 14:37:07 UTC
The problem was introduced in NetworkManager-0.8.1-25.el6, while adding VLAN support. It's not connected with selinux, but libnl handling.

The fix is available in NetworkManager-0.8.1-29.el6.

Comment 9 Matěj Cepl 2012-04-05 14:47:10 UTC
(In reply to comment #7)
> The problem was introduced in NetworkManager-0.8.1-25.el6, while adding VLAN
> support. It's not connected with selinux, but libnl handling.
> 
> The fix is available in NetworkManager-0.8.1-29.el6.

Confirming ... upgrade to

NetworkManager-openvpn-0.8.1-0.1.git20100609.el6.x86_64
NetworkManager-gnome-0.8.1-29.el6.x86_64
NetworkManager-glib-0.8.1-29.el6.x86_64
NetworkManager-0.8.1-29.el6.x86_64

made OpenVPN plugin working again

Comment 10 Jirka Klimes 2012-04-12 08:08:16 UTC
*** Bug 809620 has been marked as a duplicate of this bug. ***


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