Surfshark on TrueNAS SCALE: Docker VPN Setup Guide

Do not follow old TrueNAS OpenVPN-client tutorials

The most important fact on this page is historical: modern TrueNAS SCALE should not be configured by following old screenshots for the built-in OpenVPN client service. TrueNAS deprecated that service and removed it as SCALE moved forward. Later releases also changed the Apps backend, with 24.10 and newer using Docker-based application infrastructure. A 2026 Surfshark guide therefore needs to start from current application and routing architecture rather than preserving instructions for a control that no longer exists.

That changes the recommended design. If only qBittorrent or another app needs Surfshark, put the VPN at the application/container layer. If the entire TrueNAS host or an entire server VLAN needs to use Surfshark, put the VPN on the network gateway such as OPNsense, pfSense or a capable router. Both designs keep the storage appliance closer to its intended job and make the VPN policy easier to observe and reverse.

TrueNAS community discussions repeatedly converge on Gluetun-style routing for selected apps. The concept is simple: one container establishes the Surfshark tunnel, and protected applications share or route through that network. This is more granular than changing the default route for the NAS and safer than modifying the underlying host with one-off scripts that can break after an update.

Choose between app-level VPN and gateway-level VPN

Use app-level routing when the privacy requirement belongs to an application. Downloaders are the classic example. The TrueNAS shares, SMB/NFS services, management UI, replication tasks and Plex server can remain on the normal network while the downloader exits through Surfshark. This reduces the number of services that can be affected by a VPN outage or endpoint change.

Use gateway routing when the policy belongs to the device or VLAN. If a firewall already manages your home lab, it can route the TrueNAS IP or a dedicated application subnet through Surfshark while preserving local routes. The advantage is central visibility and policy control. The disadvantage is that a mistake at the gateway can affect every service on the NAS, so local-subnet exemptions and management access must be tested carefully.

Do not use Surfshark when the actual requirement is remote administration. TrueNAS has supported WireGuard-oriented tools such as WG-Easy in its app ecosystem, and private overlay networks are designed to create inbound authenticated connectivity. Surfshark is primarily a commercial outbound VPN and does not provide the same remote-access function.

A safe Gluetun-style pattern on TrueNAS

Start with a healthy TrueNAS system and current backups. Update to a supported release before building new Apps. Create or identify the dataset that will hold application configuration, then deploy the VPN gateway as a custom or community application using current documented container behavior. Supply current Surfshark manual configuration values, not old credentials copied from a forum post.

Bring the VPN container up by itself. Confirm its logs show a healthy tunnel, verify the external IP from inside that container and perform a DNS leak check. Only after the gateway is stable should you attach one test application to its network. Remove the test application direct internet path if your design requires a kill switch. Stop the VPN gateway intentionally and confirm the application does not quietly fall back to the ordinary WAN.

TrueNAS application networking can change between releases, so avoid hard-coding assumptions from Kubernetes-era tutorials into a modern Docker-based system. Use the controls exposed by the release you actually run. Document every port moved to the VPN gateway, every host path and the application network relationship. That documentation matters during upgrades.

Whole-TrueNAS Surfshark belongs on the gateway

If you truly need all internet-bound TrueNAS traffic to use Surfshark, an external gateway is usually the cleanest design. OPNsense, pfSense, OpenWrt and several commercial routers can establish a Surfshark tunnel and apply policy routing to the NAS IP. The TrueNAS host continues to use an ordinary default gateway while the network appliance decides which WAN path to use.

Keep local subnets outside the VPN policy. SMB, NFS, iSCSI and administrative connections should normally remain local. If a workstation sends a 10GbE file copy to TrueNAS, that transfer should never make a detour through Surfshark. The VPN is an internet egress decision, not a replacement for local Ethernet.

Build a recovery rule before enforcing a kill switch. An overly broad firewall policy can make a storage server unreachable even though the data pool is healthy. Test from a second local machine and preserve console access where possible.

Plex, qBittorrent and the port-forwarding limitation

TrueNAS users often want one commercial VPN for qBittorrent and at the same time want Plex reachable remotely. Those goals should not share one indiscriminate route. Put qBittorrent behind the Surfshark gateway and leave Plex on the ordinary internet route unless you have a measured reason to change it. Surfshark states that it does not support VPN port forwarding, so it is not a provider to choose when your architecture depends on a forwarded inbound VPN port.

Plex remote access can be especially confusing because local playback may continue to work even when the external reachability path breaks. Test Plex account communication, local Direct Play and remote clients separately. If only Plex fails after the VPN change, remove Plex from the VPN path before changing TrueNAS storage, certificates or application data.

The same pattern applies to Home Assistant, Nextcloud and other services. The service that needs inbound reachability and the service that needs outbound privacy do not have to use the same network path.

Performance and resource planning

Encrypting VPN traffic consumes CPU and adds network overhead, but on a TrueNAS server it is easy to misdiagnose the result as a storage problem. Measure the WAN path separately from pool performance. A ZFS pool capable of several gigabits per second locally can still upload through a 500 Mbps internet service or a slower VPN endpoint. Conversely, a VPN gateway container can become CPU-limited while ARC and disk latency remain healthy.

Watch CPU, memory and network metrics during a real protected transfer. If the VPN container has aggressive resource limits, make sure those limits are not the bottleneck. If the TrueNAS system is already memory-constrained by a large app stack or VM workload, solve that capacity problem rather than blaming Surfshark for general system pressure.

Cloudzat recommends keeping VPN performance tests reproducible: same file, same application, same remote destination, same Surfshark location. That produces useful before-and-after data.

Troubleshooting TrueNAS + Surfshark

When a Gluetun-style container fails, start with its logs and current Surfshark configuration. Verify the server endpoint and credentials or WireGuard keys, then test the VPN container in isolation. If it is healthy but the application is not, inspect container networking and port mapping. If neither works, confirm the TrueNAS host itself has normal DNS and internet access.

When gateway routing fails, remove the TrueNAS IP from the Surfshark policy and verify normal WAN connectivity. Re-add it with local-subnet exemptions. Compare public IP from the NAS before and after. This isolates the policy from the storage host.

Avoid shell hacks that replace core networking files or install unmanaged packages into the TrueNAS base OS. Appliance updates are designed around a controlled platform. Container or gateway solutions are easier to reproduce, document and remove.

Who should use Surfshark with TrueNAS?

Surfshark is useful on TrueNAS when specific apps need a commercial outbound VPN or when a network gateway should route the NAS through a privacy service. It is not the tool to install merely because you want to access TrueNAS remotely.

The best architecture is usually asymmetric: qBittorrent through Surfshark, Plex and storage services through the normal WAN/LAN, remote administration through a private WireGuard/Tailscale-style network, and the ZFS storage stack left untouched. That design gives each tool one job and keeps failures understandable.