This should be simple enough.

We already create the tun device in nm-openconnect-service, in the create_persistent_tundev() function. You'd just need to move that so it happens per-connection rather than being done when the process starts up (which is odd behaviour anyway; I don't remember why it's like that). And then you can make it use a name from the VPN's configuration.

From the UI point of view I'd rather see this done generically for all VPN types though, rather than just being an option for n-m-openconnect.

Why do we need to specify the tunnel interface?  It's not sufficient to create on automatically?

Besides you can already apply firewall rules to the VPN connection using dispatcher scripts, keying the specific rules you want to use for that connection off the UUID that the dispatcher script is passed in the environment.

One problem with having manually specified interfaces is that you now have to manage the interface names for *all* openvpn connections you might have, and if you change the name in one connection, then you have to make sure some other connection doesn't have the same name just in case they could concurrently be used (and yes, we'll have concurrent VPN connections in the  near future too).

Given that we already have a configuration unit (the Connection) that can be used to uniquely identify a connection to a specific network, and that that connections UUID *and* the VPN tunnel interface are passed to the dispatcher scripts which can be used to start/stop firewall rules for a specific tunnel, I don't think we need to expose the interface name anywhere in configuration. This can all be handled automatically.

At some point we may also allow firewall rules to be attached to the connection object itself, which would simply the process too, but still wouldn't require a manually-specified interface name.

'man NetworkManager' for more details on dispatcher scripts.

You might be right, but some comments:

The OpenVPN plugin already allows choosing between a tun/tap device, which will cause it to name the interface differently.

With concurrent VPN support, it seem the interface name is at the whim of VPN-plugin or the order in which the VPNs have been started. This can become confusing when running "ifconfig -a" or any other commands - aside from the dispatcher script, the user will have no idea which interface belongs to which connection. This can make management more difficult. It also means that each VPN-plugin will need to check that the interface name it requests is not already taken. (similar to the problem of globally manager interface names for *all* VPN connections).

Will dispatcher scripts play well with all firewalls? For example, I don't think shorewall (which I use) can programmatically tear up/down interface policy and rules.

The OpenVPN plugin is allowing you to choose the *type* of device. That affects the name, but it isn't the same as allowing you to set an arbitrary interface name.

With concurrent VPN support, you are correct that the interface name will depend on the order in which the VPNs have been started. The first may take 'vpn0', and the second may find that name is already in use and use 'vpn1', etc.

I don't think it's *such* an evil request to want to set up a specific interface name for each configured VPN connection, so that it doesn't depend on the ordering.

We do it for physical Ethernet, after all. We have systems which randomly assign eth0/eth1 names to devices in a different order each time you boot, and we *could* handle that "correctly" by putting the correct configuration on each device, regardless of how it's named each time. But we don't; udev will automatically rename devices when they are discovered, so they get consistent names.

I'm not worried by the "what if the name is already taken" question; like the udev renaming, this is just a best-effort. If the desired name is already taken, it can just use the next 'vpn%d' that *is* available.

I think we should support it, but I *don't* want to do it only in openconnect. It needs to be consistent.

we now have NMSettingConnection:interface-name. Although it's not exposed in the editor UI for VPNs, it could be set for any VPN type, and then the plugins could use it to pass the appropriate options to the VPN programs

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