How do you determine if a device is behind China's great firewall with the iOS SDK?

Question

Because of issues reaching our normal endpoints hosted outside of China reliably when the user is behind the great firewall, we're looking for a way to reliably determine if the user is currently behind the great firewall and use a different set of endpoint urls hosted within China.

What we would like to do is some kind of check that the client can make, like accessing a url that we know will always be blocked by the firewall forever (or is only accessible from within) or checking some property of the network configuration.

Things currently being considered:

1. Checking the device's IP against a list of netblocks assigned to China
   • Won't work if the device is behind a NAT firewall
2. Doing a traceroute from the device to a host known to be outside of china. If packets are being routed through hosts that are in China (see above) then the device must be in China.
   • Might work, but will introduce delays before the app can make calls while it.
3. Just ask the user
   • Worst case, this may be the best option.

Answer 1

IP address ranges or you can check a key few of the top blocked websites... maybe Facebook, Google, Wall Street Journal? Choose a variety.

Answer 2

I suspect that any method which attempts to check the great firewall directly will be unreliable, probably in the short term and definitely in the longer term. However since your goal is to select servers either within China or outside of the country, I suggest using the device time zone as a quick and dirty "where am I?" check. If the time zone name is Asia/Chungking, for example, use the Chinese server. If it's Europe/Amsterdam, for example, do not use the Chinese server. Check for every time zone in mainland China and you'll probably be fine.

You can get the time zone name as TimeZone.current.identifier.

Answer 3

A more technical approach may be to analyze the TCP RST packet begin sent by the firewall. This (page 5) white paper shows how researchers were able to differentiate a TCP RST from the firewall from their server by fixing the TTL value and noticing when it is different (61 vs 42 in the paper).

When a customer is possibly in China (determined by other info) you could force a RST on the first connection, save the TTL value and then notice when you get a RST of a different value.