DHCP feature for network-manager-openvpn with TAP required

[Patrick T.]

Binary package hint: network-manager-openvpn

I use OpenVPN to secure my wireless network. A connection with the command-line openvpn client works perfectly.

The problem I have is that I do not use the OpenVPN-specific features at all to configure my network, I just use TAP and the clients should get their network information via DHCP (IP address, routes etc.) through this TAP interface. When trying to connect to the VPN via the network-manager applet, I get a VPN Connect Failure with the message that no adequate network configuration has been provided, which makes the applet unusable for my purpose.

Could you please add a feature (check box in the config dialog etc.) to run dhclient on the tap* interface after a connection has been established?

As far as I have seen, a lot of other people have such a configuration so this would be great help. Thanks in advance!

I am using Hardy Heron.

[Daniel Nowak (lowlyocean)]

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.

[rsenger1 (ichthyosaurus-1)]

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

[Michael van der Kolff (mvanderkolff)]

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

[Michael van der Kolff (mvanderkolff)]

BTW - Still present in Karmic

[Juha Siltala (topyli)]

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.

[Martin Bergman (martin-devsed)]

:/ 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.

[Eirik Hjelle (eirik-hjelle)]

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

[Michael van der Kolff (mvanderkolff)]

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

[Michael van der Kolff (mvanderkolff)]

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

[Eirik Hjelle (eirik-hjelle)]

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

[Michael van der Kolff (mvanderkolff)]

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

[Eirik Hjelle (eirik-hjelle)]

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.

[Steve Briggs (zzybaloobah)]

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...

[Leon (leonbo)]

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

[ossjunkie (ossjunkie)]

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

[Leon (leonbo)]

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

[Leon (leonbo)]

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

[Launchpad Janitor (janitor)]

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

[Timothy Pearson (kb9vqf)]

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.

[Olivier Berger (oberger)]

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 ?

[Danielle Underwood (daniellebunderwood)]

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

[Oldřich Jedlička (oldium)]

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.

[Gregor Riepl (onitake)]

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.

[Mike Auty (mike-auty)]

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!

[Mike Auty (mike-auty)]

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

[Alexander Neff (neffisback)]

Hey, we are running into the same problem, is there any update on this?

As it appeared in several tickets (since forever), here is a list of tickets related to the problem:
https://bugzilla.gnome.org/show_bug.cgi?id=445257
https://bugzilla.redhat.com/show_bug.cgi?id=484831
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/613