After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 445257 - [enh] Support DHCP on tap devices
[enh] Support DHCP on tap devices
Status: RESOLVED OBSOLETE
Product: NetworkManager
Classification: Platform
Component: VPN: openvpn
git master
Other Linux
: Normal enhancement
: ---
Assigned To: Dan Williams
NetworkManager maintainer(s)
: 465429 540666 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-06-07 20:03 UTC by Spenser_Gilliland
Modified: 2020-11-12 14:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Spenser_Gilliland 2007-06-07 20:03:47 UTC
I just finished setting up a bridged openvpn server.  The server works perfectly when run from the command line.  with openvpn /etc/openvpn/client.conf.  but fails due to no returned networking configuration with the openvpn plugin.  I dont know why it fails?
Comment 1 Spenser_Gilliland 2007-06-11 14:52:46 UTC
wow i was vague.  Alright, theres a local dhcp server on the vpn machine that will hand out dhcp addresses if i run. 

openvpn client.conf
dhclient tap0

however, when network manager connects and does not see an ip it returns 

Invalid Network Information from the server.  

Curently, I reset the server-bridge directive to allow ip's to be assigned through openvpn.  Once connected i can then run 

dhclient tap0 

and obtain a dynamic address from the dhcp server.  
Comment 2 Dan Williams 2008-08-08 03:44:05 UTC
*** Bug 465429 has been marked as a duplicate of this bug. ***
Comment 3 Dan Williams 2008-08-08 03:55:10 UTC
*** Bug 540666 has been marked as a duplicate of this bug. ***
Comment 4 Dan Williams 2008-08-08 14:15:58 UTC
confirming; nm-openvpn plugin does not yet support using DHCP to acquire an IP address over the tunnel
Comment 5 matmoser 2008-11-29 21:35:10 UTC
This seems to be the problem with the OpenVPN tunnels of dd-wrt routers as well. If I try to establish a tun tunnel to the router I get the following (works from the command line):

NetworkManager: <info>  Will activate VPN connection 'openvpn', service 'org.freedesktop.NetworkManager.openvpn', user_name 'user', vpn_data 'connection-type / x509 / dev / tun / remote / %MY_IP% / port / 1194 / proto / udp / servercert-insecure / yes / ca / ca.key / cert / client.crt / key / client.key / comp-lzo / no / shared-key /  / local-ip /  / remote-ip /  / username / ', route ''.
NetworkManager: <info>  VPN Activation (vishnu) Stage 1 of 4 (Connection Prepare) scheduled...
NetworkManager: <info>  VPN Activation (vishnu) Stage 1 of 4 (Connection Prepare) ran VPN service daemon org.freedesktop.NetworkManager.openvpn (PID 12412)
NetworkManager: <info>  VPN Activation (vishnu) Stage 1 of 4 (Connection Prepare) complete.
NetworkManager: <info>  VPN Activation (vishnu) Stage 2 of 4 (Connection Prepare Wait) scheduled...
NetworkManager: <info>  VPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 1 -> 6.
NetworkManager: <info>  Error getting killswitch power: org.freedesktop.Hal.Device.UnknownError - process 12416: arguments to dbus_move_error() were incorrect, assertion "(dest) == NULL || !dbus_error_is_set ((dest))" failed in file dbus-errors.c line 278. 
 This is normally a bug in some application using the D-Bus library.
NetworkManager: <info>  VPN Activation (vishnu) Stage 2 of 4 (Connection Prepare Wait) waiting...
NetworkManager: <info>  VPN Activation (vishnu) Stage 2 of 4 (Connection Prepare Wait) complete.
NetworkManager: <info>  VPN Activation (vishnu) Stage 3 of 4 (Connect) scheduled...
NetworkManager: <info>  VPN Activation (vishnu) Stage 3 of 4 (Connect) sending connect request.
NetworkManager: <info>  VPN Activation (vishnu) Stage 3 of 4 (Connect) request sent, waiting for reply...
NetworkManager: <info>  VPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 6 -> 3.
** Message: <information>	openvpn started with pid 12417


** (process:12412): WARNING **: <WARNING>	 openvpn_watch_cb (): openvpn exited with error code 1

NetworkManager: <info>  VPN Activation (vishnu) Stage 3 of 4 (Connect) reply received.
NetworkManager: <info>  VPN Activation (vishnu) Stage 4 of 4 (IP Config Get) timeout scheduled...
NetworkManager: <info>  VPN Activation (vishnu) Stage 3 of 4 (Connect) complete, waiting for IP configuration...
NetworkManager: <WARN>  nm_vpn_service_process_signal(): VPN failed for service 'org.freedesktop.NetworkManager.openvpn', signal 'ConnectFailed', with message 'The VPN login failed because the VPN program could not connect to the VPN server.'.
NetworkManager: <info>  VPN service 'org.freedesktop.NetworkManager.openvpn' signaled state change 3 -> 6.
NetworkManager: <WARN>  nm_vpn_service_stop_connection(): (VPN Service org.freedesktop.NetworkManager.openvpn): could not stop connection 'openvpn' because service was 6.


** (process:12412): WARNING **: <WARNING>	 nm_openvpn_connect_timer_cb (): Could not open management socket


Any change for this being resolved? There is a workaround using a tap device and the server-bridge option, but there is no such option for tun devices. Would love to see NM connecting to my openvpn server...
Comment 6 Dan Williams 2008-11-30 03:59:05 UTC
(In reply to comment #5)
> This seems to be the problem with the OpenVPN tunnels of dd-wrt routers as
> well. If I try to establish a tun tunnel to the router I get the following
> (works from the command line):

It's probably something completely different.  'tun' connections do not use DHCP, because they are IP-layer connections, which can't use DHCP.

It also looks like you've got an older version of NM, what exact SVN revision are you running?
Comment 7 matmoser 2008-11-30 08:22:15 UTC
Oh I didn't know that. I am using NM 0.6.6 out of the Debian Testing repos. The server (OpenVPN 2.1_rc7) runs on a linksys router with dd-wrt. Thats the config:

push "route 192.168.0.0 255.255.255.0" 
server 192.168.1.0 255.255.255.0 

dev tun0 
proto udp 
keepalive 10 120 
dh /tmp/openvpn/dh.pem 
ca /tmp/openvpn/ca.crt 
cert /tmp/openvpn/cert.pem 
key /tmp/openvpn/key.pem

It starts up fine, and I can connect from the command line with the following config file:
remote my_ip 1194 

client 
remote-cert-tls server 
dev tun0 
proto udp 
resolv-retry infinite 
nobind 
persist-key 
persist-tun 
float
ca ca.crt
cert client.crt
key client.key

I would be happy to provide more information on this...thanks for your help!
Comment 8 Stefan Brüns 2009-09-20 18:29:43 UTC
Any news on this?

Will it be triggering the dhcp request from the openvpn plugin, or from NM  itself?
Comment 9 leon 2011-06-26 18:33:46 UTC
There's also a bug reported for this on the ubuntu launchpad: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/297707
Comment 10 Mike Auty 2016-12-30 19:23:08 UTC
Ok, so this bug has been open nearly 10 years now.  There's very little activity going on here, but there have been comments as recently as 2016 on the ubuntu launchpad.  I understand that it's a not-very-often-used feature, but I suspect it's languishing because no one's using the feature because it isn't present, which no one will work on because no one's using it, a self-fulfilling prophecy.  One of the key qualities that differentiates OpenVPN from other VPNs is its ability to provide layer 2 connectivity.  NetworkManager provides a nice GUI that allows a great deal of configuration of OpenVPN, but it still does not support TAP adaptors acquiring a DHCP address.

As best I can tell, the NetworkManger API expects all VPN plugins to provide appropriate IP information on successful connection.  It seems an odd architecture that VPNs cannot leverage the existing DHCP capabilities of NetworkManager to get their own address, but I guess OpenVPN is one of the only layer 2 VPNs.  It currently falls down as having "No IP4 netmask/prefix (missing or invalid 'ifconfig_netmask')".  Patching that (and a later check to ensure one of ip4config and ip6config have been set) seems to allow the helper to complete, but then NetworkManager issues a connection time out, so I haven't even been able to get it to bring up the adapter and to even allow manual DHCP.

Without understanding a) Networkmanager, b) libnm, c) C++ or d) d-bus very well, it's extremely difficult to suggest how to fix this, but it's quite disappointing that the high bar to entering development ensures this feature won't ever be worked on.  Can any developer please provide guidance as to even a strategy to allow OpenVPN on TAP adapters with external DHCP addresses to return appropriate ip4config information?  Are there libnm helpers that could be used to do the DHCP heavy lifting?  Should this really be considered an enhancement rather than a bug (since because of this bug, network manager doesn't support openvpn's full interface)?  Any help or support with this would be much appreciated...
Comment 11 Mike Auty 2017-01-03 22:51:59 UTC
Most of the details on how to solve this are written into the TODO file: 

https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/TODO#n119

The information is from 2011, but may still provide a basis for coding up a fix for this long standing issue.
Comment 12 Paweł 2017-09-14 18:32:55 UTC
Still not working properly on Fedora 25. After 10 years, the status of this bug has to be a joke.
Comment 13 André Klapper 2020-11-12 14:31:57 UTC
bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).