GNOME Bugzilla – Bug 445257
[enh] Support DHCP on tap devices
Last modified: 2020-11-12 14:31:57 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?
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.
*** Bug 465429 has been marked as a duplicate of this bug. ***
*** Bug 540666 has been marked as a duplicate of this bug. ***
confirming; nm-openvpn plugin does not yet support using DHCP to acquire an IP address over the tunnel
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...
(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?
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!
Any news on this? Will it be triggering the dhcp request from the openvpn plugin, or from NM itself?
There's also a bug reported for this on the ubuntu launchpad: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/297707
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...
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.
Still not working properly on Fedora 25. After 10 years, the status of this bug has to be a joke.
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).