Most Travel eSIMs Exit the Internet in Another Country: What That Does to IP Geolocation and Fraud Rules

Most Travel eSIMs Exit the Internet in Another Country: What That Does to IP Geolocation and Fraud Rules

On August 9, 2026, the travel eSIM reseller AeroSims published something its industry rarely volunteers: a list of where each of its plans actually reaches the internet. Of 392 active plans, 386 exit in a country other than the one the plan is sold for. That is 98.5 percent. A tourist in Tokyo on one of these plans shows up to every website as a visitor from Hong Kong. Plans for other destinations surface in the United Kingdom, France, the Netherlands, Singapore or the United States, and only six plans (domestic ones for the US, the Netherlands and Brazil) surface where the customer is standing.

A caveat before going further. The figures come from the live catalogue of AeroSims' upstream supplier, not from measurement, they cover one reseller, and the report itself warns that breakout regions "can change without notice." Still, they agree with independent work, and they describe a problem anyone running geo-restrictions or fraud rules has already met without knowing its name: a real phone, a real customer, and an IP address in the wrong country.

Right phone, wrong country

The best independent evidence is a paper presented at USENIX Security in August 2025, "eSIMplicity or eSIMplification?", by Maryam Motallebighomi, Jason Veara, Evangelos Bitsikas and Aanjhan Ranganathan at Northeastern University. They bought 25 eSIM profiles, activated them on a Pixel 4 XL and an iPhone 13 sitting in the United States, and wrote down the public IP each one received.

Ten of the 25 came up in another country entirely. Thirteen more received a US address, but one in Texas, New York or Virginia, at a US gateway and not where the phone sat. Only two behaved the way intuition says they should: T-Mobile and Google Fi, both domestic US services. A Holafly profile (Holafly is headquartered in Ireland) came up on 223.118.51.96, an address belonging to China Mobile International, and a traceroute from the phone crossed China Mobile hops in Hong Kong before reaching Google. RedteaGo surfaced on O2 in England. DENT and Yesim both exited in Poland, Eskimo in Singapore, MTX Connect in Oslo, BreatheSIM on the Isle of Man. The researchers streamed ViuTV, a Hong Kong service that is normally unavailable in the US, with no VPN involved.

Nathan Chiu, CEO of the Taiwanese ad-tech firm cacaFly, put it bluntly to the Taipei Times on May 12: "You could be in Japan, Thailand or Europe, but OpenAI, Anthropic and Google would still see you as Hong Kong users because the packets are routed through there."

Roaming data goes home before it goes anywhere

eSIM vendors did not invent this. Cellular roaming has carried data this way since GPRS, and the mechanism is the same one that pins domestic mobile users to their carrier's gateway city, stretched across borders.

A phone's packets do not meet the internet at the cell tower. The visited network's serving gateway wraps them in a GTP tunnel and ships them to a packet gateway (the P-GW in 4G, the UPF in 5G), and the public IP address is assigned there. In home-routed roaming, by far the most common arrangement, that gateway belongs to the operator that issued the SIM. The tunnel runs over the S8 interface (N9 in 5G) across an IPX, the private inter-carrier backbone, all the way to the home country. Tokyo to Hong Kong is about 2,900 km, so physics alone adds roughly 30 ms of round trip before the first byte touches the public internet. A plan that exits in London, 9,600 km away, pays about 100 ms, and real paths do worse.

The alternative, local breakout, puts the gateway in the visited network so the user gets a local address. It needs tight commercial and technical integration between the two operators, which is why travel eSIMs seldom get it. A third variant, IPX hub breakout, splits the difference: the IPX provider hosts the gateway in a regional hub, so a plan for Japan might exit in Hong Kong or Singapore. Regional, but still not Japan.

Home-routed roaming (most travel eSIMs) Phone Tokyo Visited network radio + serving gateway, Japan Packet gateway SIM issuer's core, Hong Kong Internet GTP tunnel over IPX ≈2,900 km Public IP assigned here: Hong Kong Local breakout (rare for travel eSIMs) Phone Tokyo Visited network radio, serving gateway and packet gateway, Japan Internet Public IP assigned here: Japan IPX hub breakout sits between the two: the gateway lives in a regional hub such as Singapore
The public address is assigned at the packet gateway. Where that gateway sits, not where the phone is, decides which country an IP lookup returns.

Travel eSIMs add a twist. The "home" network is usually not the customer's own carrier, and often not in a country the customer has any tie to. The brand on the app is a reseller. The IMSI inside the profile belongs to a sponsor operator that rents out its roaming agreements wholesale, and the phone is a permanent roamer on that operator's identity everywhere it goes.

A handful of networks behind dozens of brands

Read the ISP column of the Northeastern paper's Table 1 and the market shrinks fast. Airalo, eSIM Access, Flexiroam and Voye all received addresses from Webbing USA. AIRSIMe, BNESIM and Maya Mobile shared Telecom North America. Ubigi and USIMS sat on Transatel, DENT and Yesim on Sparks, in address space routed by the Polish operator Polkomtel, Holafly and CMLink on China Mobile International. Thirteen of the 25 brands, five networks.

The AeroSims catalogue shows the same concentration from the other side: seven named exit regions cover 364 of the 392 plans.

0 40 80 120 plans United Kingdom 103 France / Netherlands 83 Singapore 71 United States 57 Hong Kong 20 UK / Norway 20 Israel 10 BE, PL, BR, other 28 Documented internet exit region per plan, 392 plans, supplier catalogue of August 9, 2026
Where 392 AeroSims plans reach the internet, per the supplier's documentation. The top three regions carry 257 plans, about two thirds of the catalogue. Source: AeroSims.

IPinfo attacked the question from the address side earlier this year. Using ground truth from its mobile app and a month of cellular observations, research intern Shivani Hariprasad classified 258 IPv4 prefixes as roaming-only, another 1,480 as carrying both roaming and domestic traffic, and 303 IPv4 plus 47 IPv6 prefixes as likely home-routed. Nearly half of the likely home-routed IPv4 prefixes (48.5 percent) are /24s. That is a small, enumerable population.

What breaks when the exit is abroad

Geo-restricted content breaks first and most visibly. The Tokyo visitor gets the Hong Kong streaming catalog, prices in Hong Kong dollars, a refusal from any Japanese service that blocks foreign addresses, and a refusal from the AI services that do not serve Hong Kong at all. Support tickets for this get filed as "your geolocation is wrong." It is not. The packets really do enter the internet in Hong Kong, and a database that answered "Japan" for that address would be wrong for every other user behind it.

Payment risk is the expensive failure. A French card, a Japanese shipping address and a Hong Kong IP add up to three countries in one checkout, and most scoring models price that as fraud. The customer is a tourist buying a rail pass.

Impossible-travel rules do worst of all. The same traveler logs in over cellular from "Hong Kong", walks into the hotel lobby, joins the Wi-Fi and logs in again from Tokyo four minutes later. A velocity rule sees 2,900 km in 240 seconds and locks the account, during a trip, which is when people most need it to work.

Telling a roamer from a VPN

The instinct is to treat "IP country disagrees with everything else" as a VPN. The network data usually says otherwise, and the difference is in three fields.

We looked up the Holafly address from the Northeastern paper against our own API on September 20, 2026. It maps to AS58453, China Mobile International, inside the announced prefix 223.118.0.0/15, located in Hong Kong (region CN-HK, which our API files under country code CN), connection type isp, with every security flag false. (That says nothing about which sponsor Holafly uses today; it only describes the address the paper recorded.)

{
  "carrier": { "mcc": null, "mnc": null, "name": null },
  "connection": {
    "asn": 58453,
    "organization": "China Mobile International Limited",
    "route": "223.118.0.0/15",
    "type": "isp"
  },
  "ip": "223.118.51.96",
  "security": {
    "is_proxy": false,
    "is_relay": false,
    "is_residential_proxy": false,
    "is_tor": false,
    "is_vpn": false
  }
}

A commercial VPN exit rarely looks like this. It usually sits in a hosting network, carries a VPN or cloud-provider flag, and has no telecom operator behind it. A roaming exit belongs to a telco or a wholesale connectivity provider, and the AS name tells you which one.

It is not always this clean, and we checked. We ran all 25 addresses from the paper's Table 1 through the same lookup. Eighteen came back with every anonymizer flag false. Seven did not, including the two domestic controls on T-Mobile: they carried a VPN, proxy or residential proxy flag. These addresses were recorded more than a year ago and may have changed hands since. The flags are set per address and not per range: around the flagged Transatel and Better Roaming addresses, every neighbor we sampled in the same /24 was clean, while on the two T-Mobile ranges more than half of the sampled addresses carried the residential proxy flag. The likelier explanation is structural. A mobile exit is a carrier-grade NAT address shared by thousands of subscribers, and it takes one of them running a proxy app to flag it for everyone. On a mobile or roaming network, read an anonymizer flag as a score input, not as a verdict.

Two honest limits. The carrier block is empty in the lookup above. Carrier and MCC/MNC fields are populated for many mobile networks, not all of them, and this international wholesale range is one of the gaps. And even when they are populated, the MCC is the sponsor operator's. The Yesim address from the paper exits in Poland and reports MCC 260, Poland's code, consistent with its location, so the IP side alone can tell you "this is a mobile operator's egress" but not "this subscriber is abroad."

The roaming fact lives on the device. On Android, TelephonyManager exposes the SIM operator and the currently registered network operator separately, plus isNetworkRoaming(); a SIM MCC of 260 (Poland) registered on a network with MCC 440 (Japan) is a roamer, full stop. iOS is less helpful: Apple deprecated CTCarrier and it has returned placeholder values since iOS 16.4. If you ship an app, pair the device-side signal with the IP-side ASN. If you only have a browser, the ASN and connection type have to carry the decision.

IP country differs from the expected country Anonymizer flag set? is_vpn, is_proxy, is_tor, is_residential_proxy yes Anonymizer: apply your VPN policy, softened on a carrier or roaming ASN no Hosting or cloud network? connection.type, is_cloud_provider yes Ambiguous: step up authentication, unless the ASN is a known roaming hub no Carrier set, or ASN on your roaming list? carrier.mcc, connection.asn yes Likely roaming: skip impossible-travel, score on device and account history no Ordinary ISP abroad: run normal travel rules
A fraud rule for country mismatches that separates anonymizers from roamers. The hosting branch exists because some travel eSIMs exit through datacenter networks.

That hosting branch deserves a word. In the Northeastern table, Nomad's address belonged to Google LLC and Alosim's to Equinix Services. In our lookup of the 25 addresses, four come back with connection type hosting. A rule that reads "datacenter IP plus phone user agent equals bot" will catch those tourists too, which is why the list of roaming-hub ASNs should be checked before the hosting verdict is final. The list is short. Start with the networks named above, add the ones your own logs show carrying mobile user agents from a country that does not match the account, and review it every few months, since resellers switch sponsors.

Then score. A roaming ASN should cancel the distance penalty and soften a lone anonymizer flag, nothing more; stolen cards travel on eSIMs too.

What a geolocation provider can and cannot fix

We cannot move the exit. For a home-routed /24, "Hong Kong" is the correct answer to the question an IP lookup asks, and rewriting it to "probably Japan this week" would corrupt the record for everyone who needs to know where traffic really enters the internet, sanctions screening included.

What a provider can do is describe the address well enough that you do not mistake it for something else: the right AS and organization, a connection type that separates telcos from hosting, carrier and MCC/MNC where the pool is a mobile one, and anonymizer flags you can weigh against the fact that a roaming gateway is shared. Operators could help more than they do. An RFC 8805 geofeed has no way to say "subscribers of this prefix are elsewhere," and nothing in the RIR databases marks a prefix as a roaming pool, so today that knowledge is reconstructed from measurement, prefix by prefix, the way IPinfo did it.

Every Ipregistry response carries the ASN, connection type, carrier and security fields used in the decision tree above, so a roaming-aware rule is a few lines of code on top of one lookup. You can try it with 20,000 free lookups to get started.

Engage customers with in-app updates using Noticeable Keep users in the loop Ship release notes that get read. Try Noticeable

Get started with 20,000 free lookups: sign up