How a VPN Works: Follow One Packet's Detour
- The Green Shield Hides Five Moving Parts
- The First Observer Loses Detail, Not All Visibility
- The Public IP Changes at the Exit
- DNS and IPv6 Can Take a Side Door
- The Protocol Decides How the Detour Behaves
- Speed Is the Price of the Route, Not Just Encryption
- A Tunnel Drop Is the Test That Matters
- Decide Who Gets the Clearer View
You tap Connect in an airport lounge. The shield turns green, but your browser hasn't vanished from the internet; its traffic has taken a new first stop. That detour is the whole VPN trick.
Picture the same laptop opening a bank site. Without a VPN, its packets leave through the airport network toward the bank. With a VPN, covered traffic first travels to a VPN server, wrapped so the lounge operator can't read the inner trip.
The server unwraps it and sends it onward. That changes who can observe what—but it doesn't erase every observer.
The Green Shield Hides Five Moving Parts
First, the app contacts a VPN server over the connection you already have. The app and server authenticate, negotiate session keys, and establish the protected route. If the account has expired, the clock is badly wrong, or the network blocks the chosen protocol, the tunnel never comes up.
Next, the app creates a virtual network interface. On Android, the official VPN developer guide describes a local TUN interface: outgoing IP packets are read from that interface, encrypted, and sent to a gateway; returning packets are decrypted and written back. Other platforms differ in plumbing, but the useful mental model holds.
That “tunnel” is a wrapper, not a private cable. The encrypted outer packet still crosses the lounge router, your access provider, and ordinary internet links on its way to the VPN server. Inside sits the browser's original packet.
At the server, the wrapper comes off. The server forwards the request, receives the reply, wraps it again, and sends it back to the laptop. This repeats fast enough that one click feels like one connection.
The First Observer Loses Detail, Not All Visibility
Follow the bank request past the four relevant observers.
- The laptop knows the bank site, the VPN app, and which traffic the routing rules cover.
- The airport Wi-Fi and ISP see the laptop exchanging encrypted traffic with a VPN server. They can still see timing, volume, and the server address, but not simply read the inner bank request.
- The VPN operator receives the tunnel and forwards the traffic. It occupies the observation point the local network just lost.
- The bank sees a connection arriving from the VPN server's public IP, plus whatever the browser, cookies, login, and HTTPS session reveal.
Now remove the VPN. The laptop still knows the destination. The Wi-Fi and ISP see ordinary connections toward it, no VPN operator joins the route, and the bank sees the connection's normal public IP. HTTPS can still encrypt the bank session in either route; the VPN adds protection for the first leg and changes the public source address.
The real trade isn't “visible” versus “invisible.” It's which intermediary gets the better view.
The Public IP Changes at the Exit
The bank doesn't receive the laptop's home or mobile public address when the request exits through the VPN. It receives the server's address. That can change an approximate location and make many customers appear behind one exit.
It doesn't break account tracking. A signed-in bank still knows the account, a shop can still read its own cookies, and browser fingerprinting doesn't disappear because the source IP changed.
A wired gateway such as the GL.iNet Brume 2 can put that route in one deliberate place instead of asking every device to run an app. Confirm that its current firmware supports the VPN protocol and policy rules you intend to use.
- Sits on a wired network as a dedicated gateway for OpenVPN or WireGuard traffic
- Can run VPN client and server roles together for remote access and protected outbound browsing
- Has no Wi-Fi radio, making it best for pairing with an existing router or access point
The server is also where trust moves. Read a provider's logging language as a description of data handling, not as proof that the operator is incapable of observing traffic.
DNS and IPv6 Can Take a Side Door
Before the bank connection starts, the device may need DNS to turn a hostname into an IP address. A well-configured VPN normally sends covered DNS requests through the tunnel to a resolver the provider operates or selects.
If those requests keep going to the ISP outside the tunnel, the ISP may learn the domains being requested even though HTTPS protects page contents. That is a DNS leak. It is a different test from checking the public IP.
IPv6 deserves the same route check. A VPN that covers IPv4 but leaves ordinary IPv6 traffic outside can expose a direct public IPv6 address. The app should route supported IPv6 through the tunnel or block it while connected; “my IPv4 changed” isn't enough evidence.
The Protocol Decides How the Detour Behaves
The protocol defines the handshake, packet format, encryption, and recovery behavior. WireGuard's official protocol description shows a handshake that establishes symmetric session keys and encrypted packets carried over UDP. OpenVPN offers a longer deployment history and broad configurability. IKEv2/IPsec is often chosen on mobile devices for quick recovery across network changes.
Those are tendencies, not permanent speed rankings. A network that handles one protocol badly may make a nominally slower option feel much better.
Obfuscation answers another problem. It tries to make recognizable VPN traffic harder to classify on a restrictive network; it isn't a stronger grade of encryption, and it may add overhead.
Pick a protocol because it solves the failure in front of you: slow setup, broken roaming, UDP blocking, or compatibility. Changing three settings at once only hides which one mattered.
Speed Is the Price of the Route, Not Just Encryption
The laptop now encrypts packets, visits an extra server, and may take a longer physical route. Distance raises latency. Server load, protocol implementation, device power, and the quality of both internet paths can cut throughput.
A nearby server is the sensible first choice. Yet routing is messy: occasionally the VPN dodges a poor ISP path and improves one transfer. It still can't create bandwidth the airport connection never had.
Treat speed tests as snapshots. Repeat the bank-safe version of your real tasks—calls, pages, downloads—at different times before blaming the encryption alone.
A Tunnel Drop Is the Test That Matters
Suppose the laptop sleeps, wakes, and moves from lounge Wi-Fi to a phone hotspot. During that handoff, the virtual route can disappear before it returns. Without a safeguard, covered apps may fall back to the ordinary interface and expose the normal public IP.
A kill switch blocks that fallback. Some modes protect only after a VPN session begins; stricter modes block whenever the VPN is inactive. Turn the setting on, break the connection deliberately, and see whether traffic actually stops.
For several travel devices, the GL.iNet Beryl AX can sit between your devices and hotel Wi-Fi, making the shared route easier to see and test. It doesn't remove captive portals, provider trust, or the need to test failure behavior.
- Combines Wi-Fi 6 with a 2.5-gigabit WAN port in a compact travel-friendly body
- Runs OpenVPN and WireGuard profiles from compatible VPN providers across connected devices
- Adds WPA3, encrypted DNS, captive-portal support, and a configurable privacy switch
Run the same handoff test on the router and on a device behind it. Check a browser, a background app, and the public address after the uplink returns. A green icon on one box doesn't prove that every device, protocol, and fallback path stayed inside.
Decide Who Gets the Clearer View
A VPN is useful because it changes the first hop: the local network sees an encrypted connection to a VPN server, while destinations see the server's public IP. The operator sits between those views. HTTPS, account security, software updates, and careful browsing still have their own jobs.
Choose the service whose documentation, data policy, software maintenance, and independent evidence justify that trust. Then test the route you actually use. The shield is an indicator; the packets are the proof.