Feature Request - (media-adjacent apps outside the VPN-routed module can't use its forwarded ports)
Posted by paulrturnbull
Hi Tom, Not sure if this is feasible. Before moving to Sparkbox and Docker environment, I used to host my Audiobookshelf server via port forward over my Airvpn tunnel. Since going through the question with TomAI, I realise I can't do this with my current connection. Is this scenario a possibility for the future? Question: I have a port forward from airvpn for QBit over the gluetun vpn on port 39028 to local port 39028 and this works. Why doesn't my port forward for audiobookshelf on port 13379 to local port 13378 work? TomAI: Same root cause I flagged earlier — worth spelling out clearly since it's the actual answer, not a firewall thing at all. Why qBittorrent's forward works: qBittorrent runs with networkmode: service:gluetun — it shares gluetun's network namespace entirely. There's no separate container network for qBit; as far as Docker/the kernel is concerned, qBittorrent is gluetun, networking-wise. So when AirVPN forwards port 39028 down the tunnel, it lands inside gluetun's namespace, and qBittorrent — sitting in that same namespace — just receives it directly on localhost:39028. No hop required. Why Audiobookshelf's forward doesn't: Audiobookshelf is a completely separate module with its own bridge network (sbaudiobookshelf, per its compose file) and its own container IP on that bridge — it's nowhere near gluetun's namespace. When AirVPN forwards 13379 down the tunnel, that packet arrives inside gluetun's namespace (because that's the only place the tunnel terminates), same as qBit's traffic does. But then it just... stops. There's nothing inside gluetun's namespace listening on 13378, and nothing configured to hop that packet across the Docker bridge from gluetun's namespace over to Audiobookshelf's separate container. It's not a firewall rule missing — it's that the two containers live in genuinely different network worlds, and only one of them is plugged into the tunnel. Same tunnel, same AirVPN forwarding config style, totally different networking behind it depending on which container the forwarded port actually needs to reach. There's no clean, supported way to bridge that from ufw or from the Audiobookshelf module's own config — you'd need something injecting a redirect inside gluetun's namespace (e.g. an iptables DNAT rule or socat relay added to the gluetun container) pointing 13378 at Audiobookshelf's bridge IP, and that's a manual, unsupported hack that a sparkbox update could silently wipe out since it's not part of gluetun's managed config. I don't have a tool to do that safely for you, and I'd rather be straight about that than hand you something fragile. If you want Audiobookshelf reachable through the AirVPN tunnel specifically, this is worth raising on the forum — it's a legit feature gap (media-adjacent apps outside the VPN-routed module can't use its forwarded ports), not something you're doing wrong. Click "Share to demox" below if you want Tom to see it.
1 replies
tomspark wrote:
Thanks for the thoughtful write-up — this is a genuinely useful request and I've logged it for Tom. You've spotted a real gap: right now only the apps inside the VPN-routed media module can use the tunnel's forwarded port, so something like Audiobookshelf sitting outside that module can't share it. Making that forwarded port usable by other apps (opt-in) is exactly the kind of thing worth building — no promises on timing, but it's captured and on the list. In the meantime, if simply reaching Audiobookshelf from outside is the goal, Cloudflare Tunnel or the wg-easy (WireGuard) module are two easy routes — happy to point you at whichever fits your setup. 🙂