The source question mixes two different meanings of VPN. ZimaClient, Tailscale, or WireGuard can create a secure path into the NAS for remote access. NordVPN is typically used as an outbound provider VPN so selected traffic leaves through a NordVPN server.
Once the original poster clarified that the real goal was mostly torrent traffic, routing the entire NAS through NordVPN became unnecessary and potentially disruptive. A cleaner architecture is to route qBittorrent (and only the containers that need it) through a VPN gateway container while leaving ZimaOS management, SMB, Plex/Jellyfin, backups, and remote access on their normal network.
Remote Access VPN and Provider VPN Solve Different Problems
Zima-Giorgio first asked why the user wanted a VPN and pointed out that ZimaOS Remote/ZimaClient already handles remote access. That is appropriate when the goal is reaching the NAS from outside.
It does not make the NAS's outbound Internet traffic exit through NordVPN.
Routing the Whole NAS Through NordVPN Has Side Effects
A host-wide default-route change can affect:
- ZimaClient or other remote-access paths;
- DNS resolution;
- App Store and update access;
- Plex/Jellyfin remote connectivity;
- webhooks and cloud sync;
- published Docker services.
That is a large blast radius when only qBittorrent needs the provider VPN.
Use a Dedicated VPN Gateway Container for Selected Apps
Gluetun is a maintained VPN client container that currently supports NordVPN with OpenVPN and WireGuard modes, includes a firewall/kill switch, and allows other containers to share its network namespace.
See the current Gluetun VPN gateway features.
qBittorrent Should Share the VPN Container's Network
The conceptual Compose architecture is:
gluetun
├─ /dev/net/tun
├─ NET_ADMIN
├─ NordVPN credentials/config
└─ publishes qBittorrent WebUI port
qbittorrent
└─ network_mode: service:gluetunWhen qBittorrent shares the Gluetun network namespace, it cannot fall back to the normal Docker network if the VPN gateway is configured to fail closed.
Publish qBittorrent's WebUI Port on the VPN Gateway
Because qBittorrent no longer has its own Docker network stack in this design, its LAN-accessible WebUI port is published on the Gluetun service. Keep that WebUI reachable only from trusted LAN/private-network clients.
Use NordVPN Manual-Service Credentials or the Current Supported Key Method
Do not paste the ordinary account password into random Compose examples. Use the credential/key mechanism documented for current NordVPN manual connections and the selected Gluetun protocol, and store secrets outside public YAML whenever possible.
Standard NordVPN Servers Do Not Provide Traditional Incoming Port Forwarding
NordVPN's current support page says standard shared servers do not provide port forwarding. That can reduce inbound peer connectivity for torrent clients even when outbound torrenting works.
See NordVPN's current port-forwarding policy.
Verify the Public IP from Inside qBittorrent's Network
Do not assume the VPN works because the Gluetun container says “running.” Test the egress IP from the qBittorrent network namespace or use a legal torrent/IP-check mechanism. It should show the VPN exit IP, while ordinary ZimaOS host traffic should keep its normal route in a selective design.
Test the Kill Switch Deliberately
Stop or break the VPN connection and confirm qBittorrent loses Internet access rather than silently using the home WAN IP. Then restore the VPN and verify connectivity returns.
NordVPN on ZimaOS FAQ
Does ZimaOS WireGuard automatically route the NAS through NordVPN?
No. A self-hosted WireGuard/remote-access tunnel and a commercial provider VPN are different configurations.
Should the entire NAS use NordVPN if only qBittorrent needs it?
Usually not. Selective container routing reduces the chance of breaking NAS management and other services.
Does standard NordVPN support incoming port forwarding?
NordVPN currently says its standard shared servers do not provide traditional port forwarding.
