Client source port versus server listener in a VPN flow
Compare the two port numbers in one tunnel: the server's fixed listener and the client's ephemeral source, and how a router translation sits between them.
Two numbers appear in the same conversation, and neither one is wrong. The server log shows the listener that offers the service, the laptop shows the socket that sent the datagram, and a router in between may rewrite the second on the way out. Comparing the ends of the conversation is more useful than comparing the digits. The comparison below keeps the listener, the client socket and the translated source apart, because they answer different questions.
Two numbers that describe opposite ends
The server's configured port is the destination the client dials. It is fixed by policy, appears in the profile, and has to be open on the server side. The client's source port is chosen locally, usually from the ephemeral range, and exists so the reply has somewhere to land. It may change on every reconnect, and nothing in the design depends on it being stable.
A router in between may rewrite that source into its own mapping. That is why the number observed at the server often has no relationship to the one the laptop picked.
Where the source number changes on the way out
Take an invented IPv4 example: a client behind a translating router, a server with one UDP listener, and a single datagram crossing both. The table names each endpoint and what happens to it, rather than replaying the packet at three observation points.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
The destination is constant in every row, and only the source identity changes. The UDP NAT requirements distinguish an internal address and port from the external mapping, which is exactly the gap between the second and third rows. A router may preserve the client's source port or pick another; preservation is not something an application should assume.
Read the three endpoints from the hosts themselves
The listings below come from three different machines, and together they show the whole conversation. Run the first on the server, the second on the client, and the third wherever the mapping exists. A single log line never shows all three.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194The first listing proves the server is bound to the service port and shows which process owns it. The second shows the client's local socket and the destination it dialed. The third shows the mapping the router created, which is the only place the translated source appears. Read them in that order and the two numbers stop looking contradictory.
What a reconnect changes, and what it does not
Some routers keep the client's source port when it is free, and some allocate a different one every time. Both behaviours are normal, and an application that requires the first will break on the second. A change of mapping after a reconnect or a network switch is not a server fault: the client opens a new socket, the router assigns what it has, and the server sees a new source on the same listener. What would be a fault is expecting the server to accept traffic addressed to an arbitrary client port.
Community OpenVPN clients get this behaviour through nobind, which lets the operating system choose the local port; the remote port still comes from the profile. Binding explicitly is a deliberate choice, not a protocol requirement. The server keeps offering one endpoint while clients choose their own local identities.
Label the layers separately in the record
Inside the tunnel there is a second conversation with its own ports. An HTTPS request carried by the tunnel has destination TCP 443, while the outer encrypted connection uses UDP 1194, so changing the outer source port changes nothing about the inner service.
Even at the outer layer, protocol matters. UDP 1194 and TCP 1194 are different endpoints, and a TCP listener will never receive a UDP datagram because the number matches. When documenting a deployment, label the server listener, the client socket and the translated source as three distinct things, and add the transport to each.
Then let policy follow the roles. The server opens the intended transport on its listener and still authenticates the peer; the client's firewall admits replies to its own outbound exchange without publishing an inbound service. A stateless filter needs its return direction written out explicitly, which is the practical reason the distinction matters beyond tidy diagrams.