Template not updated with latest parameters/considerations

[argonan0]

I've put in 6+ hours so far today trying to get this working again after updating from qmcgaw/gluetun:v3.34.1 to qmcgaw/gluetun:latest. Can the template get a review as it pertains to WireGuard & AirVPN?

It looks like --device /dev/net/tun is also necessary now as an Extra Parameter:

TUN device is not available: open /dev/net/tun: no such file or directory; creating it...

--cap-add=NET_ADMIN on it's own doesn't appear to be sufficient.

The server IP I have provided in my airvpn.conf isn't listed here: https://raw.githubusercontent.com/qdm12/gluetun/refs/heads/master/internal/storage/servers.json
Would that absence block a vpn connection?

ERROR [vpn] finding a VPN server: target IP address not found

A number of the fields should be assessed for necessity (*). If using WireGuard, the OpenVPN details shouldn't be necessary for example and this may be leading to confusion within the docker.

Most of the URL references are outdated (like the wiki).

Missing:
WIREGUARD_PERSISTENT_KEEPALIVE_INTERVAL
probably many more I haven't stumbled on

Default HEALTH_TARGET_ADDRESS is github.com:443 rather than the referenced: cloudflare.com:443

[DiamondPrecisionComputing]

@argonan0

I've put in 6+ hours so far today trying to get this working again after updating from qmcgaw/gluetun:v3.34.1 to qmcgaw/gluetun:latest. Can the template get a review as it pertains to WireGuard & AirVPN?

Unsure on the specifics of this question. The template is not protocol or provider specific.

It looks like --device /dev/net/tun is also necessary now as an Extra Parameter:

TUN device is not available: open /dev/net/tun: no such file or directory; creating it...

--cap-add=NET_ADMIN on it's own doesn't appear to be sufficient.

Unless you are seeing some failure or error message, the TUN device is failing to create, or Gluetun stops because of this, I would not change anything. I also see this but it does not effect functionality in my instance. If it is causing issues for you, then yes, I would add "--cap-add=NET_ADMIN" to the extra parameters.

The server IP I have provided in my airvpn.conf isn't listed here: https://raw.githubusercontent.com/qdm12/gluetun/refs/heads/master/internal/storage/servers.json
Would that absence block a vpn connection?

ERROR [vpn] finding a VPN server: target IP address not found

It is possible that the built-in server list in your instance is outdated. You can find an explanation here of how to update it or see which servers are available for you to use for your provider here:
https://github.com/qdm12/gluetun-wiki/blob/main/setup/servers.md#list-of-vpn-servers

A number of the fields should be assessed for necessity (*). If using WireGuard, the OpenVPN details shouldn't be necessary for example and this may be leading to confusion within the docker.

As far as I am aware, there is no mechanism in unraid to dynamically show specific variables based on the value place inside another variable. While there are many variable options available, it was carefully thought over as to which variables would be default to the template. Unless there have been major updates recently, there should be at minimum the necessary variable to get the container working with either OpenVPN or Wireguard. As always, if there are any variables you need, or do not need, they can be added or deleted to suit your needs.

Most of the URL references are outdated (like the wiki).

Good call out as that portion has not been updated since the Wiki was move to its own repository. This and other links have been fixed in e9f757d.
I am sure there might be others that were missed but will try to update them as I find them.

Default HEALTH_TARGET_ADDRESS is github.com:443 rather than the referenced: cloudflare.com:443

This has also been address in the above commit.

[argonan0]

The TUN log line may have been a red herring. Adding the adapter resolved the message but didn't resolve the connection problem on it's own. The problem seemed to be a combination of over-specifying various fields which instead should have been empty. Without really being able to isolate the problem I did come across this:

https://github.com/search?q=repo%3Aqdm12%2Fgluetun-wiki%20privileged&type=code

--cap-add=NET_ADMIN was already added as it was a default from the template

Regarding the template fields, what I meant was that at the very least, less fields should be marked as (*) Necessary. That said, it seems that wasn't really the issue either.

The issue seemed to be a combination of configuring the WIREGUARD_ADDRESSES with IPv4+IPv6 which resulted in rapid restarts of the container however the AirVPN.conf provided it. This has nothing to do with the template but a warning at the field within the template would be nice. "Don't add IPv6 unless it's enabled" or something.

At least something within the SERVER_ range of fields seems to be necessary since I could not specify a SERVER_HOSTNAMES or VPN_ENDPOINT_IP/VPN_ENDPOINT_PORT. Those aren't marked as necessary but it seemed logical to include the values from the AirVPN.conf. This was seemingly what resulted in the VPN error.

It seems most of the DOT_VERBOSITY_ fields are now deprecated.

WIREGUARD_PERSISTENT_KEEPALIVE_INTERVAL seems like it would be a good one to have added to the template and it's also in the AirVPN.conf (PersistentKeepAlive:15) and my be important in determining if the wireguard connection dropped (maybe). I actually didn't think I could add some of the 'special' or omitted variables. I see now that I can.

In any case it wasn't particularly clear what the problem was (or rather how to fix the problems) shown in the logs and there appear to be numerous pitfalls from a 'bad config' despite it seeming fine. While that is on me to learn more, it would also be nice if notes were perhaps more specific/links more accurate, etc from within the template. Myself having put in accurate .conf info was literally the last thing I suspected as being the problem.

This can probably be closed with whatever resolution you see fit. Thanks for taking the time to respond.