Version 7.3.2

TL;DR: Unraid drops IP address but webUI is accessible. Containers in Bridge mode not connecting, apps page not loading.

Unraid drops the IP address a few minutes after boot, with or without the array started (see screenshot). *While accessing the web UI*, it displays the alert “Interface - Ethernet Port 1 is down. Check cable!”, and Plex (host connection) is working as normal. So obviously the ethernet port is not down.

Background:

I've been trying to configure GluetunVPN with ProtonVPN on wireguard with port forwarding. For whatever reason, even though the wireguard certificate from Proton has VPN enabled and the container variable VPN_PORT_FORWARDING is on, it keeps getting servers that are not capable of port forwarding.

Yesterday I decided to try deleting the GluetunVPN docker container and reinstalling it from scratch. I did this a couple times, switching apps because I wasn’t sure if my issue was something in the container variables.

FWIW, I have done zero tinkering in the Unraid network settings, so that’s all still default. DHCP reservation is on the UniFi router, and nothing looks abnormal there. I have tried deleting the network items in the boot config directory and rebooting, but no changes.

pangu-diagnostics-20260926-0622.zip

Edited September 26Sep 26 by natecook
Clarity

That method only works with OpenVPN

For port forwarding with wireguard: https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/vpn-port-forwarding.md

2 hours ago, MowMdown said:

That method only works with OpenVPN

For port forwarding with wireguard: https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/vpn-port-forwarding.md

Thank you, this is really helpful. I spent a lot of time searching and never came up with this. Unfortunately it's way over my head. Do you know anywhere with an example in Unraid?

As far as the network issue, I'm going to try a Dynamix Factory Reset.

I would hold off on the factory reset for now. Your diagnostics show an actual Ethernet link interruption. At 06:19:22, br0 loses carrier and its default route. DHCP restores the address at 06:20:06. The link is up when the diagnostics finish, so being able to open the WebGUI does not rule out that earlier interruption.

Both boot logs show the drop immediately before Tips and Tweaks reports applying its settings. Could you try a boot in Safe Mode and see whether the warning returns? Use local access for this test, because Safe Mode also disables the Tailscale plugin. Keep Gluetun and any applications that depend on its VPN stopped during the test.

There is also a Gluetun configuration problem: Docker tries to attach it to bridge networking while it is associated with host networking. Host mode shares Unraid’s own network stack. Run this read-only command and post the output:

docker inspect --format 'NetworkMode={{.HostConfig.NetworkMode}} Running={{.State.Running}}' GluetunVPN

Please also provide its Network Type and Extra Parameters, with any credentials removed. Are you accessing Unraid through its LAN address or Tailscale? If the warning returns during the test, please collect fresh diagnostics before rebooting.

Separately, Gluetun does support ProtonVPN port forwarding over WireGuard. Its current instructions require VPN_PORT_FORWARDING=on and a WireGuard configuration generated with NAT-PMP (Port Forwarding) enabled. Setting PORT_FORWARD_ONLY=on filters for servers that support port forwarding. See the Gluetun ProtonVPN instructions (https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/protonvpn.md).

7 hours ago, JorgeB said:

I would hold off on the factory reset for now. Your diagnostics show an actual Ethernet link interruption. At 06:19:22, br0 loses carrier and its default route. DHCP restores the address at 06:20:06. The link is up when the diagnostics finish, so being able to open the WebGUI does not rule out that earlier interruption.

Both boot logs show the drop immediately before Tips and Tweaks reports applying its settings. Could you try a boot in Safe Mode and see whether the warning returns? Use local access for this test, because Safe Mode also disables the Tailscale plugin. Keep Gluetun and any applications that depend on its VPN stopped during the test.

There is also a Gluetun configuration problem: Docker tries to attach it to bridge networking while it is associated with host networking. Host mode shares Unraid’s own network stack. Run this read-only command and post the output:

docker inspect --format 'NetworkMode={{.HostConfig.NetworkMode}} Running={{.State.Running}}' GluetunVPN

Please also provide its Network Type and Extra Parameters, with any credentials removed. Are you accessing Unraid through its LAN address or Tailscale? If the warning returns during the test, please collect fresh diagnostics before rebooting.

Separately, Gluetun does support ProtonVPN port forwarding over WireGuard. Its current instructions require VPN_PORT_FORWARDING=on and a WireGuard configuration generated with NAT-PMP (Port Forwarding) enabled. Setting PORT_FORWARD_ONLY=on filters for servers that support port forwarding. See the Gluetun ProtonVPN instructions (https://github.com/qdm12/gluetun-wiki/blob/main/setup/providers/protonvpn.md).

Thank you for all this detail. I am accessing over LAN and the actual ethernet interruption was almost certainly me moving cables.

Other than general frustration with this issue, the main factors prompting a factory reset were that my Docker containers couldn't be edited and I wanted to clean out older unused or deleted container data and templates, but those were easy fixes.

Things seemed stable after this and rebooting the network equipment. I still see "not set" for the IP addresses in the console (screenshot in OP), but functionally, everything seems to be working as expected. As of now, I do not have Gluetun or qBittorrent installed or running.

If everything looks clean in these diagnostics, I'll proceed with setting those things back up, taking backups as I go.

pangu-diagnostics-20260927-1049.zip

The network looks healthy at the time of these diagnostics: br0 has its LAN address, and the Ethernet link is up at 10 Gb/s.

The IPv4 “not set” message likely appeared before Unraid received its DHCP address during boot. The diagnostics confirm that it subsequently obtained an address and that the LAN connection is working.

There was a brief startup link interruption, but no further drops appear during the following 16 hours. I would not recommend a factory reset based on this.

Back up the working configuration, then reinstall Gluetun using Bridge networking. Confirm that the VPN, LAN access, and Apps work before adding qBittorrent. If connectivity fails again, collect fresh diagnostics before rebooting.

On 9/26/2026 at 9:55 PM, natecook said:

Do you know anywhere with an example in Unraid?

You add two variables to the gluetunvpn container per the link I posted under the "qbittorrent example" section

Name: Port Up Command
Key: VPN_PORT_FORWARDING_UP_COMMAND
Value: /bin/sh -c 'wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":{{PORT}},\"current_network_interface\":\"{{VPN_INTERFACE}}\",\"random_port\":false,\"upnp\":false}" http://127.0.0.1:8080/api/v2/app/setPreferences' 

Name: Port Down Command
Key: VPN_PORT_FORWARDING_DOWN_COMMAND
Value: "/bin/sh -c 'wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":0,\"current_network_interface\":\"lo\"}" http://127.0.0.1:8080/api/v2/app/setPreferences'

Just note where it references 127.0.0.1:8080 (in both) you need to change this to the host IP and qbittorrent host port to match your machine else it wont connect.

Thank you all for your help.

I don't know what keeps happening, but within a couple hours of Gluetun being connected (even with no other containers attached) my entire UniFi LAN slows to a point where nothing connects, LAN or WAN. Stopping Gluetun and rebooting the UniFi hardware resolves the issue. I was unable to grab Unraid diags before removing Gluetun.

I'm not in a hurry to sort this out because it's such a pain to take the server offline, and I don't know where to start unless someone else has an idea.

For what it's worth, I believe the issue with Gluetun not grabbing a port-forwarding-capable WireGuard server is solved by adding the variable VPN_PORT_FORWARDING_PROVIDER with the value protonvpn. (It was near-impossible to find this recommendation online.)

When Gluetun alone (no dependents) can kneecap the whole UniFi LAN, that usually means the container is doing something on br0/L2 that UniFi hates—not “VPN is slow.” Things I’d isolate before another full outage cycle: 1. Confirm Gluetun’s network mode: if it’s on br0/macvlan/ipvlan and pushing WireGuard with AllowedIPs=0.0.0.0/0, some UniFi setups treat the flood of encrypted UDP as a storm/anomaly. Prefer plain bridge and only route the containers that need the tunnel—not the host/LAN. 2. Disable UniFi IDS/IPS / Smart Queues for a short controlled test while Gluetun is up. If the slowdown vanishes, you’ve found the interaction (fairly common with WG UDP). 3. Watch the UniFi switch-port counters for the Unraid NIC while Gluetun connects: errors, multicasts, or a jump in PPS without matching useful throughput. 4. Keep DNS bound to the VPN interface inside Gluetun; avoid host network_mode / extra privileged networking unless you truly need it. 5. Reproduce with a minimal stack: Gluetun WG only, no port-forward scripts, no other containers—then add one dependent back. If you can catch diagnostics *while* the LAN is sick (before stopping Gluetun), the routing table + br0 stats at that moment are worth more than a healthy post-reboot dump.