GNOME Bugzilla – Bug 629807
does not correctly apply non-PTP VPN IP configuration
Last modified: 2010-12-16 02:00:43 UTC
Created attachment 170385 [details] openvpn config file for the network in question I am unable to use my university's OpenVPN because there is no possibility to tell NetworkManager to use a subnet topology with a tunnel interface. The config file is located at http://www2.math.uni-paderborn.de/fileadmin/Mathematik/RBM/FAQ/RemoteAccess/OpenVPN/linux/math.conf (attached here, too) Importing the file in NetworkManager doesn't work. When using a tunnel interface (default), NetworkManager assumes a point-to-point topology. The only way to use a subnet topology is to use a TAP device, but that doesn't work either. I cannot reach any machine beyond my local gateway, since the setup seems to require a point-to-point tunnel interface with a subnet topology. Pushing the subnet topology from the server's side doesn't work either. Using openvpn via the openvpn command line works (openvpn --config <filename>).
While investigating, I determined that NM-openvpn is doing the right thing here. You can determine that yourself by looking at the NM syslog output. Mine looks like this: Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> VPN connection 'rh-openvpn' (IP Config Get) reply received. Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> VPN Gateway: x.x.x.x Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Internal Gateway: 10.3.112.1 Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Tunnel Device: tun0 Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Internal IP4 Address: 10.3.112.21 Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Internal IP4 Prefix: 24 Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Internal IP4 Point-to-Point Address: 0.0.0.0 Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Maximum Segment Size (MSS): 0 Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Static Route: 10.0.0.0/8 Next Hop: 10.0.0.0 Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Static Route: 172.16.0.0/16 Next Hop: 172.16.0.0 Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Forbid Default Route: no Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Internal IP4 DNS: 172.16.52.28 Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Internal IP4 DNS: 10.11.255.27 Sep 17 14:37:56 dcbw NetworkManager[1323]: <info> Internal IP4 DNS: 10.5.26.20 and you'll find the "point-to-point" address being 0.0.0.0 and the prefix being '24'. That indicates that NM-openvpn is doing theright thing. What apparently is happening is that NetworkManager itself is not correctly applying the subnet topology to tun0.
Well, 'tun' devices are PTP by definition, though they can have subnet topology. One piece that would help in fixing this... can you grab 'ifconfig tun0' when you use openvpn to manually bring up the connection so I can see what the tun0 interface should look like?
So it appears the issue is this: 1) openvpn connects 2) openvpn calls /sbin/ip internally (from inti.c::do_open_tun() and tun.c::do_ifconfig()) with what it thinks is the configuration, which is apparently wrong. In my case openvpn automatically adds: 14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/[65534] inet 10.3.112.21 peer 255.255.255.0/32 scope global tun0 while instead that *should* be: 14: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/[65534] inet 10.3.112.21/24 brd 10.3.112.255 scope global tun0 3) NetworkManager receives correct ifconfig information from OpenVPN and attempts to apply the correct address to the interface, instead of openvpn's incorrectly applied configuration 4) NetworkManager always tries to detect whether the address its about to apply to the interface already exists on that interface, so that we don't go adding/removing addresses when it's not necessary. This step is failing, so NetworkManager believes that the address its about to apply is already owned by tun0, thus the correct configuration does not get applied.
Aha! nm-openvpn-service is not sending the magic "--ifconfig-noexec" option to openvpn to stop it from messing up tun0 underneath NM. Fixes: 9a280f7ae9fabbce7ee92fe736fad1c25f153c14 (master) bfe5c793262837f3561a3cfbd9355bf00dd75793 (0.8.x)
My daemon.log says something different: Sep 18 15:26:51 Shadow NetworkManager: <info> Starting VPN service 'org.freedesktop.NetworkManager.openvpn'... Sep 18 15:26:51 Shadow NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 1861 Sep 18 15:26:51 Shadow NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.openvpn' just appeared, activating connections Sep 18 15:26:51 Shadow NetworkManager: <info> VPN plugin state changed: 1 Sep 18 15:26:51 Shadow NetworkManager: <info> VPN plugin state changed: 3 Sep 18 15:26:51 Shadow NetworkManager: <info> VPN connection 'math.uni-paderborn.de' (Connect) reply received. Sep 18 15:26:51 Shadow nm-openvpn[1866]: OpenVPN 2.1.0 i486-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Jul 20 2010 Sep 18 15:26:51 Shadow nm-openvpn[1866]: WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page). Sep 18 15:26:51 Shadow nm-openvpn[1866]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Sep 18 15:26:51 Shadow nm-openvpn[1866]: LZO compression initialized Sep 18 15:26:51 Shadow nm-openvpn[1866]: UDPv4 link local: [undef] Sep 18 15:26:51 Shadow nm-openvpn[1866]: UDPv4 link remote: [AF_INET]131.234.116.36:1194 Sep 18 15:26:52 Shadow nm-openvpn[1866]: [vpn.math.uni-paderborn.de] Peer Connection Initiated with [AF_INET]131.234.116.36:1194 Sep 18 15:26:54 Shadow nm-openvpn[1866]: WARNING: Since you are using --dev tun with a point-to-point topology, the second argument to --ifconfig must be an IP address. You are using something (255.255.255.128) that looks more like a netmask. (silence this warning with --ifconfig-nowarn) Sep 18 15:26:54 Shadow NetworkManager: SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/tun0, iface: tun0) Sep 18 15:26:54 Shadow NetworkManager: SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found. Sep 18 15:26:54 Shadow nm-openvpn[1866]: TUN/TAP device tun0 opened Sep 18 15:26:54 Shadow nm-openvpn[1866]: /sbin/ifconfig tun0 131.234.114.23 pointopoint 255.255.255.128 mtu 1500 Sep 18 15:26:54 Shadow nm-openvpn[1866]: Linux ifconfig failed: external program exited with error status: 1 Sep 18 15:26:54 Shadow nm-openvpn[1866]: Exiting Sep 18 15:26:54 Shadow NetworkManager: SCPlugin-Ifupdown: devices removed (path: /sys/devices/virtual/net/tun0, iface: tun0) Sep 18 15:26:54 Shadow NetworkManager: <info> VPN plugin failed: 1 Sep 18 15:26:54 Shadow NetworkManager: <info> VPN plugin state changed: 6 Sep 18 15:26:54 Shadow NetworkManager: <info> VPN plugin state change reason: 0 Sep 18 15:26:54 Shadow NetworkManager: <WARN> connection_state_changed(): Could not process the request because no VPN connection was active. Sep 18 15:26:54 Shadow NetworkManager: <info> Policy set 'Auto eth0' (eth0) as default for routing and DNS. From what I see the important part is the message at 15:26:54. There is no way to configure a subnet topology in the interface, so I guess NM assumes a point-to-point topology because of the tunnel interface. On my system (running Ubuntu 10.04), NM saves its configuration in gconf. Here is the part where the VPN connection is saved: /system/networking/connections/3/ipv4: addresses = [] name = ipv4 dns = [527755907] routes = [] method = auto dns-search = [math.uni-paderborn.de,win.math.uni-paderborn.de] ignore-auto-dns = true /system/networking/connections/3/vpn: tls-remote = vpn.math.uni-paderborn.de connection-type = password comp-lzo = yes ca = /home/frederik/docs/wlan/uni/math.cacert.pem service-type = org.freedesktop.NetworkManager.openvpn username = fredm remote = vpn.math.uni-paderborn.de /system/networking/connections/3/connection: uuid = 8e8a754b-0f67-42fb-80a5-803f352a052b name = connection id = math.uni-paderborn.de type = vpn timestamp = 1284388772 Running openvpn from the command line (with --config) brings up this interface: tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:131.234.216.75 P-t-P:131.234.216.75 Mask:255.255.255.128 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:21 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:2131 (2.1 KB) TX bytes:7330 (7.3 KB)
There's a related bug in the Ubuntu launchpad bugtracker: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/610361
I can confirm that the fix is working. I installed packages Mathieu Trudel-Lapierre posted in the Ubuntu bugtracker and which incorporate the fix. The error message stating that I'm trying to use a tun device with a point-to-point topology still comes up, but in the end I have a working connection. Thank You!