Any server responsible for media acquisition or automation control should be treated as internet-facing infrastructure, even if it is not directly exposed via open ports.

A VPN is not optional hardening — it is a baseline requirement for protecting identity, reducing exposure, and enforcing predictable traffic flow.

This page explains why a VPN is required, how it fits into the Trash Panda Guides architecture, and outlines best-practice VPN behavior, with NordVPN recommended as a known-good provider.

Configuration steps are intentionally covered on separate pages.

Automation and acquisition servers routinely:

• Communicate with external services
• Query indexers and metadata providers
• Download content from untrusted or variable sources
• Maintain long-lived outbound connections

Without a VPN, this traffic:

• Exposes your public IP address
• Is directly attributable to your ISP account
• Can be logged, throttled, or flagged
• Breaks the assumption of isolation used elsewhere in the architecture

A VPN establishes a controlled, encrypted egress path that decouples acquisition traffic from your physical location and ISP identity.

This is not about absolute anonymity.

A VPN provides:

• IP abstraction
• Traffic encryption in transit
• Reduced ISP visibility
• Consistent routing behavior

It does not:

• Make a system immune to misconfiguration
• Replace firewall rules
• Protect exposed services

Think of the VPN as a network boundary, not a magic shield.

In the Trash Panda Guides environment:

• The automation/acquisition server is isolated
• Internet-bound traffic is forced through the VPN
• LAN traffic remains local and unrestricted

This creates a clear separation:

• WAN traffic = encrypted, tunneled
• LAN traffic = direct, low-latency

This balance is critical — especially for:

• NFS mounts
• Plex communication
• Reverse proxy access
• Management UIs

Any acceptable VPN configuration must meet the following requirements:

• All internet-bound traffic traverses the VPN
• Local subnet traffic bypasses the VPN
• VPN failure does not leak traffic
• The VPN starts automatically at boot
• No application-level VPN exceptions

If the VPN drops, traffic should fail closed, not silently fall back to the WAN.

Any reputable VPN provider can work, but NordVPN is recommended because it:

• Supports Linux natively
• Provides a mature CLI
• Allows fine-grained routing control
• Supports kill-switch enforcement
• Is widely documented and well-tested

NordVPN is not required — but using it minimizes unknowns.

When using NordVPN on an automation or acquisition server, the following behavioral settings are considered best practice.

• VPN protocol: NordLynx
• Auto-connect: Enabled
• Start on boot: Enabled
• Kill switch: Enabled (system-wide)

These ensure the VPN is always active and traffic never escapes unintentionally.

• Route all external traffic through VPN
• Exclude local subnets from the tunnel
• Do not rely on application-level split tunneling

Local resources (examples):

• NAS / NFS servers
• Plex Media Server
• Reverse proxy
• Management workstations

These must remain reachable even if the VPN is active.

• Use VPN-provided DNS
• Do not use ISP DNS
• Avoid custom DNS unless required

DNS leaks defeat the purpose of tunneling traffic.

• Use geographically stable regions
• Avoid frequent region hopping
• Avoid specialty servers unless required

Consistency improves reliability and reduces unexpected failures.

Automation tools assume:

• Reliable connectivity
• Predictable routing
• Stable IP behavior

A misconfigured VPN can:

• Break indexer access
• Prevent downloads
• Disrupt local mounts
• Cause silent failures

A properly configured VPN becomes invisible — exactly as intended.

This page intentionally avoids:

• CLI command syntax
• OS-specific setup steps
• Firewall rule definitions
• Tool-level binding

Those topics are covered in:

• VPN installation guides
• Automation server configuration pages
• Download client binding guides

A VPN on the automation/acquisition server is:

• A security boundary
• A routing policy
• A reliability requirement

When implemented correctly:

• Internet traffic is controlled and encrypted
• Local services remain fast and accessible
• Automation runs uninterrupted
• Failures are obvious, not silent

This is foundational infrastructure — not an optional add-on.