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.