Comment 1 for bug 201777

Revision history for this message
John Pearson (admin-gtagalenco) wrote :

I can confirm this behaviour; I'm a Debian user but have used the Ubuntu source to build network-manager-openvpn.

I'm using OpenVPN with a tap interface to create a bridged configuration; everything works fine when stopping and restarting OpenVPN by hand, but the network-manager plugin treats the TAP device like a point-to-point interface, and ignores options pushed by the server that are designed to set up the appropriate routes.

My server config for this client includes the options
  ifconfig-push rose 255.255.255.0
  push "redirect-gateway def1"
('rose' resolves to the intended IP, 192.168.113.224)

Here's the routing table I get:
  # route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric Ref Use Iface
  203.122.249.19 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan1
  192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan1
  192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 br1
  0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tap1

But this is what it should be:
  # route -n
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric Ref Use Iface
  203.122.249.19 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan1
  192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan1
  192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 br1
  192.168.113.0 0.0.0.0 255.255.255.0 U 0 0 0 tap1
  0.0.0.0 192.168.113.106 128.0.0.0 UG 0 0 0 tap1
  128.0.0.0 192.168.113.106 128.0.0.0 UG 0 0 0 tap1

In my syslog, I see
  Jul 11 14:03:43 rose nm-openvpn[14790]: TUN/TAP device tap1 opened
  Jul 11 14:03:43 rose nm-openvpn[14790]: ifconfig tap1 192.168.113.224 netmask 255.255.255.0 mtu 1500 broadcast 192.168.113.255
  Jul 11 14:03:43 rose avahi-daemon[9140]: New relevant interface tap1.IPv4 for mDNS.
  Jul 11 14:03:43 rose avahi-daemon[9140]: Joining mDNS multicast group on interface tap1.IPv4 with address 192.168.113.224.
  Jul 11 14:03:43 rose avahi-daemon[9140]: Registering new address record for 192.168.113.224 on tap1.
  Jul 11 14:03:43 rose nm-openvpn[14790]: /usr/lib/network-manager-openvpn/nm-openvpn-service-openvpn-helper tap1 1500 1576 192.168.113.224 255.255.255.0 init
  Jul 11 14:03:43 rose NetworkManager: <information>^IVPN Activation (Huiac) Stage 4 of 4 (IP Config Get) reply received.
  Jul 11 14:03:43 rose nm-openvpn[14790]: ERROR: Linux route add command failed: shell command exited with error status: 7

Note that I only see one error, although the directives specified by the server should result in 3 routes being added (rather than the 1 bogus Point-to-pint style default route which I end up with).

This appears to be an upstream bug and there appear to be several duplicates in launchpad, but there doesn't appear to have been any movement on it; I'd be very interested to see it addressed, because it's one of the principal roadblocks which currently prevent us from recommending or offering Ubuntu to our corporate clients for deployment on laptops - they currently use Windows XP with "direct" OpenVPN support (i.e., just running the OpenVPN service with X.509 certificates managed by the MS Certificate Store), which "just works" in this configuration.

John.