CloudFront Geo Blocking Behind a VPN: Diagnose the Exit

A geo restriction is a decision about an IP address, and a VPN changes which address the service sees. That single sentence explains most of the confusing reports that reach a support queue: "the site works at home and fails on the tunnel" and "the site works on the tunnel but nobody else in the office can load it" are the same mechanism producing opposite outcomes. This runbook walks the diagnosis in the order that rules causes out, starting with what the edge actually told you. The same exit address can pass one control and fail the next, because each control evaluates a different property of that address.

Read the 403 before changing anything

A geo block and a WAF block both arrive as 403, and they are fixed in different places. Capture the response headers and the first line of the body, because CloudFront includes a cache header and a reason string that tell you which layer answered:

curl -sS -o /tmp/body.txt -D /tmp/headers.txt https://d111111abcdef8.cloudfront.net/
grep -i "x-cache\|via" /tmp/headers.txt
head -c 300 /tmp/body.txt

When the distribution itself blocked the request for geography, the body carries a message naming the country restriction. When a WAF rule blocked it, the body is usually a generic forbidden page and the distribution request ID in the headers is what you take to the WAF logs. Getting this wrong sends you to the country allowlist for a rate-based rule problem, which is a day of work that cannot succeed.

Step 1: confirm which address the distribution sees

Ask the network what the outside world sees, from the same machine and the same route the failing browser uses. curl -s https://checkip.amazonaws.com returns the caller's public address, which for a VPN client is the exit rather than the subscriber's home connection:

curl -s https://checkip.amazonaws.com
nslookup d111111abcdef8.cloudfront.net

If that address belongs to your provider's exit in another country, the geo decision has already been made and nothing on the client will change it. Write the address into the ticket before you touch a setting, because it is the only fact in the report that both you and the service agree on.

Step 2: separate country from reputation

CloudFront resolves viewer location from a third-party GeoIP database keyed on the request's source address, and the mapping is approximate and regional rather than a precise fix. When the location cannot be determined, the documented default is to serve the content. So there are three possible states: the exit maps to a blocked country, the exit maps to an allowed country, or the database has no opinion and the request proceeds.

A user in a blocked country can appear to be in an allowed one if the provider has an exit there, and a user in an allowed country can be blocked because the exit is registered elsewhere. Neither outcome proves the restriction is broken. Both are the restriction working on the address it was given, as the CloudFront geo restriction documentation describes.

Reputation is the second axis and it survives the tunnel. The AWS WAF managed anonymous-IP rule group is built to block requests from VPNs, proxies, Tor nodes and hosting providers, so a request that passes the country check can still be refused because of what the address is, not where it is. If the block started when you moved the tunnel to a cloud host, this is the likely layer.

Step 3: check the quota behaviour

Shared exits fail in a third way. Per-IP rate limits and session counts treat one address as one client, and a consumer exit carries many subscribers at once, so a request pattern that is unremarkable from a home connection looks like automation from the exit. The symptom is throttling or a temporary block that clears on its own, not a geographic error message.

A distribution can also count sessions per address deliberately, for example with a Lambda@Edge function writing to DynamoDB. That does not identify the person behind the exit, but it does make one address behave like one client, which is often the actual intent. Log the distinct addresses behind a complaint before tuning any threshold, since a corporate NAT fronting two hundred desks looks exactly like a busy exit from the outside. Expect false positives from corporate NAT, a university network or a large household that all present a single address.

Look at the WAF sampled requests and rate-based rule metrics before blaming geography. A rule that fires on the exit's request volume leaves a clear signature, and it also tells you whether the fix is a limit adjustment or a different egress path.

What to change, and in what order

First decide what the control is for. Keeping a regional catalog, limiting abuse and enforcing a contract are three different goals, and only the first is addressed by a country list. If the goal is abuse control, the exit is the wrong unit of identity, and no amount of allowlisting will make a shared address trustworthy.

If a stable address is genuinely needed for an allowlist, a dedicated or static exit helps because the address can be registered and does not rotate. It does not make the address residential, and it does not change the country a GeoIP database assigns to it. Rotating exits until one works is a temporary reputation change, not a fix for the policy.

Then write the outcome in the terms the requester used: this address is blocked by country, by reputation or by rate, and this is the control that will change. Anything vaguer invites the same ticket again next week with a different exit.