VPN Fundamentals
Volume 2 — Networking Foundations
A VPN (Virtual Private Network) extends a private network across a public one, so a device that's physically outside a network can behave — for routing and access purposes — as if it's inside it. This chapter covers the concepts and when they actually apply to Traxs infrastructure, as distinct from when they don't.
1. What a VPN Actually Does
Two things, together:
- Encrypts traffic between your device and the private network, so it's unreadable while crossing the public internet.
- Routes your traffic as if your device were physically on that private network — giving you access to private IP addresses (like
10.0.1.5) that aren't reachable from the open internet at all.
Without the VPN, your laptop simply has no route to 10.0.1.5 at all — it's not that the connection is blocked, there's no path to it in the first place. The VPN is what creates that path.
2. Remote Access vs. Site-to-Site
| Type | What it connects | Typical use |
|---|---|---|
| Remote access VPN | A single device to a private network | An individual connecting their laptop to reach internal resources |
| Site-to-site VPN | Two entire networks to each other, permanently | Connecting an on-premises office network to an Azure VNet as if they were one network |
Traxs, as a fully cloud-based, no-office-network operation, would use a remote access VPN if a VPN is needed at all — site-to-site exists mainly for organizations bridging an on-premises data center or office network with cloud infrastructure, which isn't the current Traxs setup.
3. Protocols
| Protocol | Notes |
|---|---|
| IPSec | Long-established, works at the network layer, widely supported by enterprise VPN gateways including Azure VPN Gateway |
| SSL VPN | Runs over standard TLS (often port 443), which makes it easy to pass through restrictive firewalls since it looks like ordinary HTTPS traffic |
| WireGuard | Modern, much simpler codebase than IPSec, generally faster, increasingly the default choice for new remote-access setups |
For anything new, WireGuard or a managed SSL VPN service is generally the simpler, faster starting point — IPSec's main advantage today is breadth of enterprise/legacy support, which matters more for site-to-site scenarios than for a small team's remote access needs.
4. Azure VPN Gateway
Azure VPN Gateway is Azure's managed VPN service, supporting both connection types:
| Azure feature | Corresponds to |
|---|---|
| Point-to-Site (P2S) | Remote access VPN — an individual device connects directly to a VNet |
| Site-to-Site (S2S) | Site-to-site VPN — an entire on-premises network connects to a VNet |
| VNet-to-VNet | Connects two Azure VNets to each other, using the same underlying gateway mechanism |
A Point-to-Site VPN Gateway is the relevant option if a private Azure resource (like a database with no public endpoint) ever needs to be reached directly from a developer's laptop rather than through an application layer.
5. When Traxs Actually Needs a VPN — and When It Doesn't
This is the practical question that matters more than the protocol details:
Doesn't need a VPN:
- Accessing
api.roundtrips.appor any public-facing API endpoint — these are meant to be publicly reachable over HTTPS, that's the point of them. - Deploying via Azure DevOps pipelines — the pipeline agent authenticates and connects using its own credentials, not a VPN tunnel.
- Most day-to-day development against local or containerized (OrbStack) resources.
Would need a VPN (or an equivalent tunnel):
- Connecting DataGrip directly to an Azure SQL instance that's been locked down to a private endpoint with no public access — a Point-to-Site VPN or an SSH tunnel (see Section 10 of the SSH & Key Management chapter) both solve this; a VPN is the standing, always-on version of that same idea, an SSH tunnel is the ad hoc, per-session version.
- Any future scenario where a Traxs resource is deliberately given no public IP at all as a security posture, and a developer genuinely needs direct access rather than going through an application layer.
For Traxs's current architecture — Azure SQL and App Service reachable through firewall rules rather than fully private endpoints — an SSH tunnel or a firewall allow-rule for a known IP has generally been the lighter-weight solution; a standing VPN Gateway becomes worth the added infrastructure once private-endpoint-only resources are actually in place.
6. Split Tunneling
A VPN can be configured two ways:
| Mode | Behavior |
|---|---|
| Full tunnel | All of your traffic routes through the VPN, including ordinary internet browsing |
| Split tunnel | Only traffic destined for the private network routes through the VPN; everything else goes directly to the internet as normal |
Split tunneling is usually what you want for a "reach one private resource" use case — full tunnel adds latency to unrelated traffic and routes your general browsing through the VPN's network for no benefit, though some organizations deliberately choose full tunnel for stricter traffic monitoring/security policy reasons.
7. Practical Developer Workflow
Connecting via an Azure Point-to-Site VPN (once configured by whoever manages the VNet):
- Download the VPN client configuration package from the Azure Portal (VPN Gateway → Point-to-site configuration → Download VPN client).
- Install the generated profile — on macOS/Windows this typically uses a native or Azure-provided VPN client.
- Connect; your machine now has a route to the VNet's private address space.
- Confirm with a direct test against a known-private resource:
nc -zv 10.0.1.5 1433 # confirm you can now reach the private database port
8. Troubleshooting Playbook
| Symptom | Likely cause | What to check |
|---|---|---|
| VPN connects but can't reach the private resource | Split tunnel not routing that specific subnet, or NSG still blocking the VPN client's assigned address range | Check the VPN client's routing table; confirm the NSG allows the VPN gateway's address pool |
| VPN won't connect at all | Certificate/authentication issue, or the gateway's public IP/port is blocked by a local network | Re-download the client profile if certificates may have expired; test from a different network |
| Works over VPN, breaks the moment it disconnects | Expected — this confirms the resource genuinely has no public path, which the VPN was solely providing | Not a bug; if broader access is needed going forward, that's an infrastructure decision, not a debugging task |
| Everything (including ordinary browsing) is slow while connected | Full tunnel mode routing unrelated traffic through the VPN | Confirm whether split tunneling is configured, if unrelated traffic doesn't need to go through the tunnel |
| Intermittent disconnects | Client-side network instability, or an idle-timeout policy on the gateway | Check gateway idle-timeout settings; confirm the disconnect correlates with actual network changes (wifi to ethernet, sleep/wake) |
9. Quick Reference
| Category | Concept | Detail |
|---|---|---|
| Type | Remote access (P2S) | Single device to a private network |
| Type | Site-to-site (S2S) | Two entire networks connected permanently |
| Protocol | WireGuard | Modern, simple, fast — good default for new setups |
| Protocol | IPSec | Established, broad enterprise/legacy support |
| Protocol | SSL VPN | Runs over TLS, passes through restrictive firewalls easily |
| Azure | VPN Gateway | Managed Azure VPN service, supports P2S, S2S, and VNet-to-VNet |
| Mode | Split tunnel | Only private-network traffic routes through the VPN |
| Mode | Full tunnel | All traffic routes through the VPN |
| Alternative | SSH tunnel | Ad hoc, per-session equivalent for a single resource — see SSH & Key Management |
Part of the Traxs Engineering Handbook — Volume 2: Networking Foundations. Companion chapters in this volume: TCP/IP Fundamentals, DNS Deep Dive, SSL/TLS Explained, Network Troubleshooting, Load Balancers & Reverse Proxies.