No, My VPN Does Not Support Countries

An IP address is not a geographic coordinate, and a VPN is not a country selector

This is an opinion article about the terminology surrounding virtual private networks, commercial Internet egress services and IP geolocation. It is not claimed that commercial “privacy VPN” services never have legitimate uses, nor that the encrypted tunnels used by them are technically not VPNs. The problem is that one very specific application has captured the name of a much broader networking concept - and that it is commonly marketed using a geographic model the Internet itself does not possess.

• Introduction
• What a VPN Actually is
• What the Commercial Service Actually Provides
• A VPN Supports Routes, not Countries
• An IP Address is not a Geographic Coordinate
• An Address Registry is not a Land Registry
• Anycast Makes the Question “Where is This Address?” Ill-defined
• A Database Opinion Becomes a Legal Oracle
• Then an Industry Appears to Route Around the Fiction
• Privacy by Choosing a Different Upstream Provider
• Geographic Databases Have Become a Shadow Control Plane
• Conclusion
• References

Introduction

One of the surprisingly reliable ways to discover how completely a technical term has been captured by marketing is to tell someone that one has built a VPN.

The first question is often not which protocol is used, how peers authenticate, whether the system transports Ethernet frames or IP packets, whether it uses a hub-and-spoke or mesh topology, how routing information is distributed, whether roaming is supported, or whether the implementation handles MTU discovery correctly. The first question often is:

Which countries does it support?

At that point I usually have to suppress the urge to ask whether their Ethernet switch supports Belgium.

The question is not entirely irrational. A large part of the non-technical public now thinks to understand “VPN” to mean a subscription service that sends all traffic through a server operated by some - often shady or at least not trustworthy in the strict sense - third party and then forwards it from there to the public Internet. Such providers often advertise lists of countries, flags, maps and promises that the user may appear to be somewhere else.

But this is not what the general term Virtual Private Network means.

The commercial product may contain a VPN. It may even use an entirely respectable VPN protocol. But the list of countries is not a capability of the VPN. It is a property of an additional Internet egress service attached to one end of it. It’s a list of points of presence they operate.

Confusing those two things is rather like calling a railway system a “holiday destination selector” because some trains happen to terminate in tourist cities.

What a VPN Actually is

A virtual private network provides a restricted logical connectivity domain over infrastructure that is also used for other traffic. Hosts, routers or complete networks become members of that domain and can communicate according to its routing and access policy while remaining logically separated from systems outside it.

The classical case is a site-to-site connection:

The shared infrastructure may be the public Internet, a provider backbone, an MPLS network or some other transport system. The private network may be implemented using cryptographic tunnels, provider-controlled forwarding tables, unencrypted encapsulation (think of gre or gif), labels or combinations of these mechanisms.

Encryption is extremely common and frequently essential, but it is not by itself the definition of a VPN. Provider-provisioned Layer 3 VPNs can provide separation through routing and forwarding state without necessarily providing cryptographic confidentiality against the provider. Conversely, an encrypted SSH connection does not automatically create a general-purpose virtual network.

The IETF literature has long acknowledged that VPN is a broad and somewhat confused term. RFC 2764 describes a VPN as the emulation of private WAN facilities using IP infrastructure, while RFC 4110 formulates it as a restricted set of communicating sites using infrastructure shared with systems outside that set. Hosts may also be attached directly, so remote-access and host-to-network VPNs are equally valid. A VPN does not even have to belong to one legal organization: extranets and provider VPNs may connect participants from different organizations under a common connectivity policy[1, 9].

My own default mental model is still the site-to-site or host-to-private-network case. It captures the important part: there is a defined private connectivity domain. There are members, routes, resources and a policy governing communication between them.

__It has peers and prefixes.

It does not have countries.__

What the Commercial Service Actually Provides

A typical consumer “VPN” product looks approximately like this:

The client normally installs a virtual interface and directs either selected routes or the default route through it. In a so-called full-tunnel configuration, nearly all traffic is sent to the provider. The provider decapsulates the packets and forwards them to the public Internet, often after network address translation. RFC 7359 explicitly distinguishes this send all traffic through the VPN configuration from split tunnelling, where only selected traffic uses the tunnel[2].

The tunnel between the device and the provider is a valid remote-access VPN.

But the destination website is not part of that VPN. The public Internet beyond the provider gateway has not suddenly become private. The provider is simply acting as the user’s new upstream router and Internet transit provider.

The complete commercial product is therefore better described as remote-access VPN plus forced or selected routes plus third-party Internet transit plus provider-controlled egress addresses.

Calling the entire product merely a VPN is technically not completely false, but it hides almost everything interesting about what is being sold. The VPN is one component of the service. The feature represented by all the little national flags is the provider’s collection of Internet egress points.

A more precise description would be an encrypted Internet egress service, a tunnelled egress relay, or - if one wants to retain the established term - a remote-access VPN with selectable Internet egress gateways.

That formulation also makes the trust model rather more obvious.

A VPN Supports Routes, not Countries

When evaluating a VPN implementation, sensible questions include whether it supports IPv4 and IPv6, how peers are authenticated, which cryptographic algorithms are available, how keys are rotated, how routes are distributed, whether overlapping address spaces can be handled, whether broadcast or multicast traffic is supported, how NAT traversal works, whether roaming between physical interfaces is possible and what happens when a peer disappears.

A VPN may support:

• IPv4
• IPv6
• Ethernet frames
• point-to-point links
• site-to-site links
• mesh connectivity
• split tunnelling
• full tunnelling
• dynamic routes
• multiple administrative tenants
• multicast routing

“France” is not a network protocol.

When a commercial provider claims to support France, Canada or Japan, it normally means that the provider can arrange for traffic to emerge from an address that external systems are expected to classify as belonging to the selected country.

That expectation may correspond to the physical location of a server. It may correspond to operator-supplied geolocation metadata. It may correspond merely to the current opinion of one or more commercial geolocation databases.

None of these is a VPN capability.

An IP Address is not a Geographic Coordinate

An IPv4 address is a 32-bit protocol address. An IPv6 address is a 128-bit protocol address. They are protocol-layer identifiers used by the routing and forwarding architecture. Their bit patterns do not contain standardized geographic coordinates or national jurisdiction information.

• There is no country field in an IP packet header.
• There is no latitude field.
• There is no longitude field.
• There is no border-control bit telling a router that a packet has now left Austria and entered Germany.

IPv4 historically described an address in terms of a network part and a local part. The IPv6 addressing architecture defines routing prefixes, subnet identifiers and interface identifiers, and explicitly warns nodes not to infer arbitrary structure beyond boundaries that are known from their routing context. An operator may voluntarily construct an internal address plan based on cities, buildings or continents, but that is a local convention, not a globally defined meaning of the address bits[3\, 10].

The important distinction can be written rather simply:

What actually exists is something more like:

Here, $a$ is an address, $D$ is a particular geolocation database and $t$ is the time at which it is queried. The result $\widehat{C}_D$ is an estimate produced by that database.

Another database may return another country. The result may change tomorrow without the address or server moving. The user associated with the traffic may be in an entirely different place.

Any location remains a guess. It is not information encoded in the address.

An Address Registry is not a Land Registry

A common source of confusion is the regional allocation of Internet number resources.

IP address space is administered hierarchically. IANA delegates resources to Regional Internet Registries, which in turn allocate and register resources for network operators and other organizations. Registry records are important for uniqueness, coordination, abuse handling, transfers and operational contact.

But the fact that an address block was allocated through a particular regional registry does not transform it into geographically anchored property.

The RIPE Database contains registration information and contact details for network resources. RIPE itself warns that its country information should not be treated as perfectly accurate, and its documentation has historically been explicit that some country attributes did not possess a single reliable geolocation meaning. APNIC similarly states that allocation data can at most provide an approximate indication of an address blocks original allocation and that it cannot accurately map resources to specific countries[4].

There may, of course, be contractual and policy requirements governing how number resources are obtained and used. Different registries have different rules for in-region and out-of-region use. ARIN, for example, explicitly recognizes out-of-region use under defined conditions. These are administrative rules surrounding resource management; they are not properties enforced by the IP or routing protocols[5].

This distinction matters:

Registration identifies responsibility for a resource. It does not assign the resource a physical position.

To improve geolocation data, an operator can publish a geofeed: an external mapping between prefixes and approximate locations. RFC 8805 defines a format for these feeds, while RFC 9632 describes how they can be discovered and used. The very existence of a separate geofeed mechanism demonstrates the point. Geographic information has to be attached as additional metadata because it is not present in the IP address itself[6, 11].

A geofeed may be useful. It may even be supplied by the operator that knows the deployment better than anyone else.

It is still metadata.

Anycast Makes the Question “Where is this Address?” Ill-defined

The assumption that each IP address corresponds to one physical place fails particularly spectacularly with anycast.

In an anycast service, the same service address is made available from multiple discrete locations. Routing delivers a client’s packets to one of those instances according to network topology and routing policy. Exactly the same address may therefore reach a server in Vienna for one client, Frankfurt for another and Amsterdam for a third - even for clients residing all in the same origin country. RFC 4786 defines this operational model, and RFC 7094 discusses the architectural consequences of placing equivalent instances of an address in multiple locations[7, 12].

For an anycast address $a$, physical location is not even a single-valued function:

The address simultaneously represents multiple service instances.

Which one receives a packet depends on the routing state seen by that packet’s source. A routing change can cause subsequent packets to reach a different site without the address changing at all.

The natural question “where is this IP address?” therefore has no answer.

One might instead ask:

• Where is the organization operating it incorporated?
• Through which registry was the prefix allocated?
• Which anycast instance receives traffic from this client?
• What country does a particular database currently assign to it?
• Under which jurisdiction is a contract performed?

Those are different questions. Their answers need not agree.

Tunnels, mobile access networks, carrier-grade NAT, satellite networks, cloud systems, remote desktops and ordinary corporate gateways separate them even further. A person in Vienna can connect to a machine in Zurich through a gateway in Frankfurt using an address registered to an organization in Texas.

The address still performs its actual job perfectly: packets can be routed toward it. The failure occurs only when an external system demands that it also serve as a geographic identity document.

A Database Opinion becomes a Legal Oracle

Why, then, are IP addresses treated as countries? Because the source address is readily observable.

A website may not know where a person is. It may not have access to GPS, nearby wireless networks, a verified postal address or any other stronger location signal. But it necessarily sees some network endpoint from which the connection arrives.

The temptation is obvious: take that address, query a database and pretend that the result is location.

What begins as a rough heuristic then becomes a policy boundary.

Content contracts may grant distribution rights only in certain territories. Governments impose territorially different taxation, trade, censorship, gambling, media and financial rules. Companies divide markets, vary prices and limit products by jurisdiction. RFC 6740 itself notes that legal requirements and geographically limited content licences have motivated attempts to map IP blocks to physical locations[8].

Some of these requirements may have legitimate intentions. Most may not. That is a separate political question.

The technical problem remains the same:

A law cannot add location information to an IP address. A contract cannot make an anycast address exist at only one site. A lawyer writing “users in country X” does not create a reliable function that determines whether a packet was generated by such a user.

Nevertheless, systems routinely collapse the whole problem into something like:

if geoip_country(source_ip) not in permitted_countries:
    deny_access()

A probabilistic estimate has become an authorization decision. This is equivalent to taking a noisy sensor, discarding its uncertainty and declaring its output legally authoritative.

Then an Industry Appears to Route Around the Fiction

Once services use source-address classification as a territorial gate, the workaround is nearly inevitable. The user establishes a tunnel to a provider. The provider forwards the connection from an address classified as belonging to the desired country. The destination service sees the provider’s address rather than the user’s ordinary access-network address.

• Nothing about the user’s physical location has changed.
• Nothing about the content has changed.
• The packet has not presented a passport at a border.
• Only the input to a database lookup has changed.

The providers list of “supported countries” is therefore largely a list of of geographic classifications that its selectable egress addresses are intended to obtain from external systems. It does not even have to be a physical machine in the destination country - in fact many “VPN providers” not not operate real machines in the countries but operate IP networks that have the matching classification in prominent databases.

This produces an absurd circular economy:

First, global services are artificially divided using an unreliable geographic inference. Then users pay another company to provide a different input to that inference. And no legal entity, government or company can make the underlying inference technically true merely by requiring it to be true. They may block known relays, regulate providers or make circumvention difficult, but they cannot turn an IP address into a geographic coordinate.

We built a global packet network, installed national turnstiles above it and then created a subscription industry selling routes around the turnstiles. It is difficult not to see this as institutional damage converted into recurring revenue. Commercial egress providers are not solely responsible for this situation. They satisfy a demand produced by territorial contracts, censorship, surveillance concerns, market segmentation and other restrictions. In some situations they provide an important escape route.

But calling the resulting product simply a VPN hides the whole chain of causes. It makes the tunnel itself appear to provide geography, privacy and anonymity as intrinsic properties.

It provides none of them automatically.

Privacy by Choosing a Different Upstream Provider

The privacy marketing deserves its own distinction.

Without a commercial VPN service, traffic might follow this simplified path:

With one, the path becomes:

The local access provider can no longer inspect the inner network traffic directly. It primarily sees an encrypted exchange with the VPN endpoint, together with timing and traffic-volume information.

But the VPN provider is now the users immediate upstream network operator. At its egress it can normally observe destination addresses, timing and traffic volumes, and potentially DNS traffic depending on the chosen configuration. Application-layer encryption such as HTTPS continues to protect the actual encrypted content from the VPN operator, but the operator has not vanished from the trust model. The trusted intermediary has been moved.

It may have been moved to a transparent, technically competent and carefully audited provider. It may also have been moved from a known local telecommunications company to a brand name whose infrastructure, ownership, resellers and logging practices the user has never examined. That can still be a rational trade. It is not the elimination of trust.

It certainly is not anonymity by definition. Accounts, payment information, browser fingerprints, cookies, application logins, traffic correlation and endpoint compromise all exist outside the VPN tunnel. Calling this entire arrangement privacy without explaining which observer loses access and which observer gains it is just marketing.

Geographic Databases have become a Shadow Control Plane

The Internet already has a control plane. Routing protocols distribute reachability information and select paths according to network policy. GeoIP systems add another, unofficial control plane above it.

This shadow control plane decides which language a person sees, which price is offered, which media may be played, which account may be created and sometimes whether access is allowed at all. Yet its data are neither globally standardized nor perfectly consistent. Different providers may disagree. Updates propagate at different speeds. Operator-published information may conflict with measurement-derived information. Cached decisions may remain wrong long after a network has changed.

From an engineering perspective this is an extraordinarily weak basis for hard authorization. It also punishes perfectly normal network architectures. Corporate gateways, cloud systems, universities, mobile operators, satellite networks, travellers, anycast services and privacy-preserving relays routinely separate a user’s physical location from a visible source address.

These are not attacks against the Internet. They are normal uses of the Internet. The territorial policy layer treats them as suspicious because they expose the false assumption underneath it.

Conclusion

The consumer use of the word VPN is not entirely technically wrong. A genuine VPN tunnel normally exists between the user and the provider. But it is an inadequate name for the complete service, and it has become actively misleading.

The geographically selectable feature is not the VPN. It is third-party Internet transit through addresses that external databases associate with particular territories. Those territories are not encoded in the addresses. They are estimates and administrative annotations layered on top of a routing architecture that was not designed as a map of nation states. Anycast alone is sufficient to show that a single address may have multiple simultaneous physical locations.

This is more than semantic pedantry. Precise terminology exposes system boundaries, and system boundaries expose trust. A user should know whether one is joining a private network, encrypting a path, moving a default route, replacing an upstream provider, changing an externally visible source address or attempting to manipulate a geographic classifier.

Those are different operations.

A VPN does not support countries. A VPN supports connectivity policy. And packets do not carry passports.

References

• [1] RFC 2764: A Framework for IP Based Virtual Private Networks
• [2] RFC 7359: Layer 3 Virtual Private Network (VPN) Tunnel …
• [3] RFC 791: Internet Protocol
• [4] FAQ - RIPE Database docs
• [5] Number Resource Policy Manual
• [6] RFC 8805: A Format for Self-Published IP Geolocation Feeds
• [7] RFC 4786: Operation of Anycast Services
• [8] RFC 6740: Identifier-Locator Network Protocol (ILNP) …
• [9] RFC 4110: A Framework for Layer 3 Provider-Provisioned Virtual Private …
• [10] RFC 4291: IP Version 6 Addressing Architecture
• [11] RFC 9632: Finding and Using Geofeed Data
• [12] RFC 7094: Architectural Considerations of IP Anycast

This article is tagged: Opinion, Security, How stuff works, Web, Internet, Network