Why many app connections share one OpenVPN session

Picture a browser loading an HTTPS page while an SSH client reaches another server and a resolver answers a query, all through one OpenVPN session. On the physical interface you see one conversation; inside the tunnel you see three. Both views are correct, and knowing why is the difference between a useful capture and a confusing one. Follow one inner flow from socket to wire and the layering stops being abstract.

One outer conversation, many inner flows

Each application opens its own socket, and the kernel gives it a five-tuple of source address, source port, destination address, destination port and protocol. Those tuples exist before any tunnel is involved. Routing then decides that all of them leave through the tunnel device, so the packet handed to OpenVPN still carries the original headers inside it. OpenVPN encrypts that inner packet and wraps the result in a single outer UDP or TCP conversation with the peer. The outer conversation is therefore one, while the flows inside it are as many as the applications opened.

Nothing collapses. The inner tuples survive end to end, which is why the far side can still tell the three flows apart.

The port that stays fixed

What stays constant is the outer tuple: your address, the local port the client bound, the peer address, and the configured service port. That tuple is what a firewall or a NAT in the path has to permit, and it is the one a capture on the uplink will show. It is also the one that changes after a reconnect or a network switch, because the client may bind a different local port. One tunnel does not imply one fixed source port forever.

The inner ports are what the endpoints care about. An HTTPS flow keeps destination port 443 inside the tunnel even though the outer transport sits on whatever port the operator configured. The application endpoints never learn about the outer one.

What decapsulation changes at the far end

At the peer the outer layer comes off, and the inner packet is what remains. From there, forwarding and access policy apply to the inner destination and protocol. The web server still receives an HTTPS connection, the SSH daemon still receives SSH, and the resolver still receives a query.

This is why a rule permitting the outer transport is not the same rule as permitting an internal service. The first describes a path; the second describes authorization.

TCP outer means one stream, not one connection

When the outer transport is UDP, each inner flow's fate is independent: a lost datagram affects one transfer until its own retransmission. When the outer transport is TCP, all inner flows share one reliable byte stream.

That shared stream is the part people miss. Recovery happens once, for everything, so a single lost segment delays traffic from every application multiplexed inside it. It is still many connections at the endpoints and one connection on the wire, and the wire is where the head-of-line effect lives. The number of listening ports tells you nothing about this, which is why counting ports is a poor way to reason about tunnel performance.

Describe your own setup accurately

Name the selected inner traffic and the specific outer transport carrying it, rather than saying the machine sends everything through one port. Local services, a second tunnel and the other address family all create flows that never enter this conversation. A capture on the uplink shows the outer tuple; a capture inside the tunnel shows the inner ones.

Take both, and put the timestamps side by side. If you need to prove which application generated which inner flow, the socket table on the host is the better instrument, since it maps ports to processes directly. Then write down the outer tuple you observed and the moment you observed it, because the next capture after a reconnect may legitimately show different numbers.