VPN: how a shared IP sends data to the right subscriber

A VPN can route several subscribers through the same IP address. Ports, a mapping table and tunnels ensure each reply reaches the right device, without this technical record automatically constituting a browsing history.

When two VPN subscribers open the same page, the website may see their requests arrive from a single public IP address. That does not mean the VPN server confuses them: to route the replies, it associates each exchange with a temporary mapping and a tunnel to the device concerned.

This distinction sheds light on two questions that are often conflated. A shared IP address can hide the original public address from the websites visited. But the network still has to work, so the VPN server must retain enough information, at least while exchanges are taking place, to know where to send the packets back. This connection record is not, in itself, a browsing history.

One visible address, several connections

An IP address is used to route packets between networks. With IPv4, for example, several devices on the same home network can already share the public address assigned to the router. Inside the home, they have private addresses; when traffic leaves, the router replaces those addresses with its own. On the way back, it performs the reverse translation.

A VPN server can play a similar role for the traffic that passes through it. The subscriber’s device sends its data through an encrypted tunnel to the VPN server. Within the VPN network, the server can identify the client using its internal address and the information associated with the tunnel. It then uses its public IP address to send the traffic on to the internet.

The remote website sees this public address, not the public address of the network from which the subscriber connected to the VPN. So if several clients use the same VPN address to access the internet, that address alone is not enough to distinguish them. The server must also keep track of the connections themselves.

The port completes the address

For a TCP or UDP connection, packet headers include port numbers as well as IP addresses. A port identifies a communication endpoint associated with an exchange. To reach a website over HTTPS, traffic is generally sent to port 443 on the server. The browser also uses a port on the client side, called the source port.

For illustration, imagine two clients whose requests go out through the same VPN address to the same web server. The VPN can assign different source ports on its public address to their exchanges. The web server replies to the address and port associated with each request. The VPN then checks its mapping table to find the internal address and port of the client concerned, and sends the data back to it through its tunnel.

This translation of the address and port is called NAPT, short for “Network Address and Port Translation”. The Internet Engineering Task Force’s RFC 3022 describes this mechanism for IPv4 networks: several internal addresses and their ports can be mapped to a single external address and distinct ports. The mapping takes account of the protocol used, notably TCP or UDP.

A port is therefore not a permanent label for an internet user. It is used to distinguish between exchanges in progress. A state table keeps the mappings needed for traffic in both directions; when a connection ends or becomes inactive, this information can expire. Without this state, the server would not know which client should receive a reply arriving at a shared address.

From the VPN server to the right tunnel

Translating the public address is only part of the journey. Once the reply has returned to the VPN server, it still has to send it to the right device through the corresponding tunnel. To do this, it relies on internal network information and how the VPN protocol works.

In WireGuard, for example, the addresses allowed in tunnels are associated with clients’ public keys. This helps determine which cryptographic session is used to transmit packets. The details vary between protocols and architectures: sharing an exit address does not mean that all VPNs carry out every step in exactly the same way, or that every configuration must use identical address translation.

The more general rule is that a reply must return through the device capable of identifying the exchange to which it belongs. RFC 3022 highlights this requirement for traditional NAT: traffic for a session must pass through the router that holds its translation state, or through a device sharing the necessary information. If this route or state disappears, an ongoing connection can fail, even if the public address remains available.

Technical records do not mean a browsing log

Two types of information need to be distinguished. The mapping table is used for routing: it temporarily links an external exchange to an internal connection. A browsing log, in the usual sense, records a user’s activity, such as the websites visited or the times they connected. The need to maintain connection state does not, in itself, establish that the provider retains this second type of data.

This distinction does not, however, allow us to draw conclusions about the policy of any particular provider. How long information is retained, what data is recorded for other purposes and management practices depend on its configuration and commitments, which should be examined separately. Network mechanics explain what needs to be tracked to route traffic; they do not certify a company’s practices.

Finally, a shared IP does not mean anonymity. A website can recognise someone because they log in to their account, through cookies or other information associated with their browser. The VPN changes the public IP address visible to the website, but does not remove these other means of recognition. It therefore addresses a specific question — the address used to access the internet — without erasing the identity linked to accounts or traces stored in the browser.