Two VPN Hops in a Row: Who Actually Sees Your Traffic?

Every client profile names one server, so from the user's seat there is one tunnel and one place where protection ends. What happens after that first gateway is a design decision the client never sees, and the two common designs behave very differently under inspection. In a serial chain the first gateway decrypts and re-encrypts. In a nested chain it removes an outer layer and forwards an inner tunnel it cannot open. The hop count is identical in both, which is why the difference has to be drawn rather than counted.

Start at the client and name both endpoints

Begin where the user begins, in the connection profile. It holds one remote address, one authentication method and, when the design supports it, a route list. Label that outer tunnel from the client to gateway A and give it example addresses: the client's tunnel address 10.77.0.2, A's 10.77.0.1, and A's public endpoint 198.51.100.10, taken from the TEST-NET-2 documentation range so nothing in the example can collide with a real host.

Nothing in that profile mentions gateway B, and that is not a defect. The second hop belongs to A, and the client's only obligation is to deliver traffic to A and accept what comes back. Whether A terminates the tunnel, forwards it or opens a new one is the question the rest of this walkthrough answers, and it decides what A can read.

Serial: A decrypts, then encrypts again

In the serial design A terminates traffic twice. It removes the protection from the client, obtains the application's IP packet, and then sends that packet through a second tunnel that A originates toward B. Between those two operations the packet sits in A's forwarding path as an ordinary IP packet addressed to a private destination.

That produces two consequences worth stating plainly. A can apply policy to the inner packet, in the form of routes, filter rules and logging of source and destination, and A must hold two sets of credentials, one as a server for the client and one as a client of B. Protection exists at every instant, yet the object being protected changes identity at A.

It does not follow that A reads application plaintext. When the client and the service run TLS and verify each other's certificates, A sees a TLS record stream rather than a readable request. Confirming where that protection ends takes a look at the service's certificate chain, not at the tunnel diagram.

Nested: A removes only the outer layer

In the nested design the client builds an inner tunnel to B first and then carries that tunnel inside the outer one to A. A strips the outer header, finds an inner tunnel, and forwards it without holding its keys, so the inner protection still terminates at B.

The client's uplink then carries two layers, while the path between A and B carries one. A sees the outer addresses of the inner tunnel, which is enough to know that traffic exists and roughly where it is headed, and not enough to read the payload. That is the entire difference from the serial case, and no hop counter shows it. What A can still do is refuse to forward what it cannot read, which is always available to the operator of that gateway.

Nesting charges for that property. Each layer adds header overhead, so MTU and MSS planning turns mandatory rather than tidy, and a path that works with one layer can silently drop large packets with two. Each layer also needs its own reconnect and keepalive behaviour, and a failure in one layer looks like a partial outage through the other.

Draw the observers, not just the tunnels

The tunnels are the easy part of the drawing. The observers are what the design is about, so write one row per vantage point and fill in what each one can actually read.

Two rows get conflated constantly: the operator of A and the provider of the client's tunnel. They may be one entity, and separate gateway names do not make them independent. Independent ownership needs separate administrative control, separate credentials and separate logging.

Metadata survives both designs. Timing, packet sizes and connection counts stay observable at each hop, so two hops raises the cost of correlation rather than removing the signal. A design that promises invisibility should be checked against that list before anyone relies on it.

Walk the failure paths before you choose

Break things on purpose from the client, in the order a user would meet them. Start with the interface and its MTU, because nesting fails at packet size long before it fails at authentication.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Then confirm the protection endpoints instead of assuming them. Ask the service for its certificate from inside whichever tunnel is up, and compare the chain the client sees with the chain the service actually presents. A gateway that re-signs or intercepts changes that certificate, and the inspection becomes visible in a single command.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Finish with the reconnect matrix: the client's tunnel drops, B's tunnel drops, the path between A and B changes. Note what returns and what does not, and whether an inner connection ever falls back to a route outside its intended carrier. Record the addresses each test used, since repeating it on a different access network answers a different question. Repeat the MTU probe after every reconnect as well, because a changed path can lower the usable size without a single configuration line moving.

Choose serial when A must apply policy to the inner packet, or when the client cannot run two stacked tunnels. Choose nesting when the inner payload has to stay unreadable at A. Write the choice down with its observers and its MTU numbers, and the next person will not have to redraw the whole picture to answer one question.