DHCP feature for network-manager-openvpn with TAP required

I agree with this ... I have to run `sudo openvpn client.conf &` and then do a Ctrl+D whenever I want to make a VPN connection to my Tomato OpenVPN server. The network-manager-openvpn package does not allow me to receive a DHCP address from dnsmasq running from the OpenVPN server. It is also not feasible to set a static IP either (with the default gateway being the tap* device). I need an ifconfig statement in my client.conf file and openvpn must be run from the terminal, as mentioned above. Please help provide this support - I think that many other users may have a need for this as well.

I have the same problem, as many other users do. A fix would be greatly appreciated.

Is network-manager-openvpn actually maintained? It seems strange that the general brokenness of the tap configuration would go unfixed for this long - or is it a case of "patches please!"?

Cheers,

Michael

BTW - Still present in Karmic

Each time I connect to my University openvpn, i have to manually run 'sudo dhclient' before i get an IP address and access anything. I'm on Karmic.

:/ What gives, Can't this issue be assigned or delegated to a maintainer of the plugin? I can't find a duplicate to this bug and no known workaround.

Not being able to use network manager just because I can't check "run dhclient" / "run script on startup" feels very weak.

I added a patch to run commands on connect and disconnect with the --up and --down parameters, maybe it can solve your problems too? https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/273773

That's far from a perfect solution, but it's a good start. I'll try it next time... What would be the best solution is for a tap-based openvpn interface to show up as an ethernet interface with all the configuration buttons that we have for them right now, including DHCP. In particular, how to ignore the DNS server you get, and all those other knobs. But it seems we can't just say "Here's another ethernet interface - please let me configure it as one"...

Cheers,

Michael

Now that I think of it, one way of showing this is to cover the simple case - how do we set up a new GRE tunnel that passes ethernet frames, and build from there...

Cheers,

Michael

Michael: You can push all theese options from your openvpn server if I understand correctly what you are asking for ?

There's a slight problem, Eirik: The options are being sent out via DHCP. None of this would be a problem if we could configure the tap{x} interface exactly as we could an ethernet interface. I'm thinking that a way of demonstrating this would be to build a GRE nm plugin, and go from there... Not because anyone would use it, but because it would demonstrate what I'm talking about.

Cheers,

Michael

Hello Michael,

I understand, but instead of announcing IP addresses from a separate DHCP server you can do it in your OpenVPN server, it gives you greater flexibility for other options in the future, like I've done with mine:

server 172.31.0.0 255.255.255.0 # this makes the vpn server assign clients IPs in the 172.31.0.0/24 range.
keepalive 1 120

#To push extra options
push "dhcp-option DNS 172.31.0.1"
push "dhcp-option DOMAIN your-domain.com"

I can now connect my clients to the VPN server with minimum configuration, only need to add the certificate and its done.

I would also like Network Manager to treat tap like any other Ethernet interface.
When it gets a "link" (i.e. OpenVPN starts up), Network Manager should take the
appropriate action, whether to configure it manually, launch dhclient, or whatever.

Yes, you could push options from the OpenVPN server, but I have the server-side
tap bridged to my internal LAN and I want the remote machine to look EXACTLY
like another machine on my net. Which means to get its IP configuration via DHCP,
just like all the other machines. I don't want to maintain (essentially) 2 DHCP
servers: a "normal" one and OpenVPN via push.

Steve

PS. I'm new to Ubuntu. In Fedora, "/sbin/ifup tap0" would use a configuration file
(ifcfg-tap0) and treat tap0 just like eth0. This at least gave me a work-around...

I think this is fixed? Or is this something else?

@Leon: It's something else :) Using TAP is not the problem, but getting the IP address & co via DHCP for it is.

Ah, I see. I'm having the same problem now having to run dhclient3 tap0 manually. Has anyone got a solution for this?

There's also a bug for this on gnome bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=445257

Status changed to 'Confirmed' because the bug affects multiple users.

Rather surprised this still isn't fixed 6 *years* later. All of my customers using VPN access have been forced to run a custom script in a terminal to get access; this complicates their workflow and gives a rather bad impression of Linux to these users.

And no, using the OpenVPN "DHCP server" is not an option for various reasons.

I wonder if that couldn't be worked around by adding something to /etc/network/interfaces for tap0 to declare dhcp... although this may interfere with other uses of tap0 :-/

Any comments ?

No doubt, Timothy. 6 years should be more than enough time. And adding a configuration for tap0 as Ethernet doesn't help.

I also need this feature. We have VPN box from our customer (a special router), which is out of our control, and we have our OpenVPN server to connect remotely to this VPN box. The VPN box is giving us IP address over DHCP, so we are not able to setup a fixed IP on the OpenVPN server. Having DHCP option on NetworkManager in this case is the only possibility to use it.

NetworkManager's TODO file contains very nice description on what needs to be implemented in order to get DHCP over VPN working.

oldium, can you link or post that TODO part here?
Perhaps someone with enough know.how and time can pick up in it.
Not saying I'll do it, but the issue is bothering me too, and I might find some time to implement the feature.

Gregor, the TODO documentation you were looking for is at:

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

although, the branch referenced in it is no longer available. It is reasonably detailed, but unfortunately requires better knowledge of C, D-bus and NetworkManager than I have. If you manage to get an implementation going but need a tester, please let me know!

This bug was also relevant, but has been marked as CLOSED/WONTFIX (although the issue is still present on later versions of Fedora)...

https://bugzilla.redhat.com/show_bug.cgi?id=484831