How a single request travels from a laptop on a home network, through a VPN tunnel, to a web server in the lab. All addresses are documentation examples.
Laptop
192.168.1.20→Home router
NAT→Internet
198.51.100.0/24→VPN endpoint
203.0.113.10→Tunnel
10.0.0.0/24→Reverse proxy→Web server
10.0.0.50
192.168.1.20→Home router
NAT→Internet
198.51.100.0/24→VPN endpoint
203.0.113.10→Tunnel
10.0.0.0/24→Reverse proxy→Web server
10.0.0.50
1. Name resolution
The browser asks a resolver for app.example.com and gets back a public address like 203.0.113.10.
2. Leaving the LAN
The laptop (192.168.1.20) sends the packet to its default gateway. The router rewrites the source address with NAT and forwards it upstream.
3. Into the tunnel
The VPN endpoint decrypts the packet and routes it onto the private tunnel network (10.0.0.0/24). Only the peers and subnets listed in AllowedIPs are reachable.
4. Proxy and server
A reverse proxy terminates TLS and hands the request to the right backend (10.0.0.50). The response retraces the path in reverse.
Where things usually break
- DNS pointing at a stale address
- MTU too large for the tunnel
- AllowedIPs missing a subnet
- Proxy forwarding headers not trusted by the app