Hindsy

Xteve WebUI Inaccessible via LAN (net=container:privoxyvpn) - Stream Works, UI Blocked (Port 34400) Help provided by Gemini I would be extremely grateful if someone can help with this, or provide a solution/recommendation for something like the xTeVe container that can reliably run through privoxyvpn. Edit: I should mention I also tried Threadfin, and this resulted in the same issue where I couldn't access the WebUI once I routed through privoxyvpn. I have configured the xteve container to use the network stack of binhex-privoxyvpn (i.e., --net=container:binhex-privoxyvpn). The core function—Xteve's IPTV stream—works perfectly and is correctly routed through the VPN. However, the WebUI at http://192.168.1.2:34400/web/ is completely inaccessible via the LAN. I receive a connection timeout/refused error. This strongly suggests a firewall (IPTables) rule is blocking LAN-to-container access on port 34400, despite all documented settings being correct. Container Configuration Details 1. binhex-privoxyvpn (VPN Container) SettingsVariable Value Purpose Network Type Bridge (Correct for VPN container) LAN_NETWORK 192.168.1.0/24, 172.17.0.0/16, 10.253.0.0/24 Includes LAN, Docker Bridge, and WireGuard ranges. ENABLE_PRIVOXY yes Confirmed set to yes to enable LAN access to bound containers. VPN_INPUT_PORTS ..., 34400, 5004 Explicitly includes Xteve's ports for forwarding. VPN_OUTPUT_PORTS ..., 34400, 5004 Also includes Xteve's ports. Other Services Prowlarr and qBittorrent are also running successfully on this VPN container's network stack. This confirms the VPN is functional. 2. xteve (Client Container) SettingsVariable Value Rationale Network Type Container: binhex-privoxyvpn Correct for routing through the VPN. Port Mappings None (0) Confirmed removed (no Host:Container port entries for 34400/5004). Log Output Web interface is running on http://172.17.0.4:34400/web/ Confirms Xteve is running on the internal Docker Bridge network. Troubleshooting Steps Taken (Did NOT Work)I have exhausted all known fixes, including low-level system resets: Verified all configuration variables (LAN_NETWORK, ENABLE_PRIVOXY, VPN_INPUT_PORTS) are correctly set. Confirmed Port Mappings were removed from the xteve container. Attempted the Bridge/Revert fix: Temporarily switched Xteve to Bridge mode, added ports, confirmed access, switched back to Container mode, and removed ports. No change. Performed a full Docker and IPTables reset: Stopped Docker, ran iptables --flush, iptables -t nat --flush, and iptables -X (and ip6tables equivalents), then re-enabled Docker. No change. Attempted Manual URL Access: Tried accessing http://192.168.1.2:34400/web/ directly. No change. Given that the Xteve stream works (VPN is routed) and the WebUI is inaccessible (LAN is blocked), what specific, non-standard IPTables chain or rule might be blocking traffic from the 192.168.1.x LAN to the internal 172.17.0.4:34400 path, which is managed by the binhex-privoxyvpn container? Is there a known Unraid-specific bug or a custom kernel setting that interferes with this container-to-host forwarding?