VPN Capture: Inner Packets on tun0, Envelope on eth0

Capturing on a VPN host does not record one single thing. The kernel exposes the packet twice: wrapped, on the physical adapter, and unwrapped, on the tunnel device. Choosing the interface chooses which of those stories you read. Most arguments about what a capture proves are really arguments about which story was collected.

Encapsulation Creates Two Views

The tunnel takes the packet an application produced and puts it inside a new one whose destination is the VPN server. The inner form appears on tun0, wg0 or whatever device the client created. The outer form appears on the adapter that carries it to the network. Both forms are legitimate; they answer different questions. Collect each separately, because the two have different headers and different readers.

sudo tcpdump -i tun0 -n -s 0
sudo tcpdump -i eth0 -n host 198.51.100.20 and udp port 51820

The pseudo-interface any is a poor choice for this comparison. Forwarded packets can be recorded twice, and a locally generated packet shows up in both forms, which inflates counts. If a number looks impossible, check the interface before blaming the tunnel.

Inside the Tunnel, the Packet Is Ordinary

On the tunnel device, what you see is what the application asked the kernel to send. Destination addresses, ports, DNS names, TLS server names, sizes and timing are all there. The TLS payload stays encrypted by the application's own session, so the capture does not reveal page content. A plaintext DNS query is visible here even though its carrier is encrypted, because it was never protected in the first place.

Encrypted DNS removes that one visible field. It does not hide the destination address, the byte count or the rhythm, which are properties of the flow rather than of the query.

Outside, Only the Envelope and Its Shape

The physical adapter shows your address, the server's address, the port, packet sizes and timing. Destinations carried inside are absent, though their shape may still support inference. Sizes and cadence can suggest a video stream, a bulk transfer or a chat session without naming any of them. A nearby observer sees approximately this same view, which explains how a tunnel can conceal sites while advertising its own presence.

That claim depends on routing. A narrower route, an IPv6 default that does not enter the tunnel, or a process bound to the physical interface will put traffic outside the envelope. Read the actual route before drawing conclusions from the capture.

Peer Address and Capture Hygiene

TCP-mode OpenVPN keeps an established socket, so the socket table can name the peer. UDP-mode OpenVPN often leaves the socket unconnected, and ss may show only the local side. Read the profile's remote, a verbose client log, or the route to the endpoint instead. WireGuard reports its endpoint and latest handshake directly.

wg show
ss -tunp | grep 51820

A capture file outlives the session that produced it. It can be copied, and it may be readable by anyone with local access. Keep only what the investigation needs, restrict permissions, and delete it when the work is done.

A shareable capture should say which interface produced it and when. Without that note, the next reader has to guess which layer they are looking at.