====== VPN Importance for Automation & Acquisition Servers ======
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.

===== Why a VPN Is Required =====
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.

===== Risk Reduction, Not Anonymity =====
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.

===== Architectural Role of the VPN Server =====
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

===== Mandatory VPN Behavior =====
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.

===== Why NordVPN Is Recommended =====
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.

===== NordVPN Best-Practice Settings =====
When using NordVPN on an automation or acquisition server, the following **behavioral settings** are considered best practice.

==== Core Settings ====
  * 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.

==== Traffic Routing Behavior ====
  * 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.

==== DNS Handling ====
  * Use VPN-provided DNS
  * Do not use ISP DNS
  * Avoid custom DNS unless required

DNS leaks defeat the purpose of tunneling traffic.

==== Server Selection ====
  * Use geographically stable regions
  * Avoid frequent region hopping
  * Avoid specialty servers unless required

Consistency improves reliability and reduces unexpected failures.

===== VPN + Automation: Why This Matters =====
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.

===== What This Page Does NOT Cover =====
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

===== Summary =====
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.