Country blocking dropping unblocked countries.

Question

I have country blocking enabled and find that I can't use some tools. 
 I have installed and running a v9.510-5. 
 When viewing the live log, I see some entries indicating a "Country blocked" for IP addresses which GEOLOCATE shows as being in the US, which is not blocked. example: 
 11:26:02 Country blocked TCP 192.168.0.58 : 57769&rarr;35.201.70.64 : 443 [SYN] len=60 ttl=63 tos=0x00 srcmac=a4:08:ea:28:6a:31 dstmac=34:97:f6:27:76:9f 
 
 All IP location tools I've tried indicate 32.201.70.64 as "Mountain view, CA" 
 I have "United States" set to "OFF" in the firewall Country Blocking tab, so why is this IP being blocked? 
 I also tried adding an exception as shown below, but this did not work. Am I doing it incorrectly? 
 
 Also, I tried adding an "exception" for this IP address, and this does not seem to work. I added a "host" exception with the

DouglasFoster · Accepted Answer

The easy part first. Yes, your exception is configured incorrectly. When the referenced object is remote (public IP), the country list must be left EMPTY. When the referenced object is internal (private IP), one or more countries are required in the list. The help attempts to explain this, but it does not do it well. 
 You show a fragment from the packet filter live log. For the packet filter log only, the live log is abbreviated for performance reasons. Always check the archived version of the full log using the Log Search tab, the current day log view, or the archived log download. However, in this case it will not help. Unless something changed recently, the full packet log will not show the country name either. 
 Since this is a web connection, I suggest enabling web logging, even if it is just in allow-all mode, because the web log will show the country name. It will also show whether the connection uses a host name or an IP address for the connection. This allows you to match the exception to the need, without allowing more than necessary 
 Outbound country blocking is not widely used, so it may not be rigorously exercised logic, and you may have found a bug. Equally likely, the country assignment may be incorrect. The matching logic is an imperfect science. If there is an IPv4 to IPv6 translation in the process, the detected location will be at the translation point rather than the point of origin. 
 Inbound country blocking is pretty intuitive: "I am not travelling in Russia, so I don't want to allow remote access connections from Russia." 
 Outbound country blocking is more nuanced: If a Russian company and a French company share a hosting service in Canada, which country name applies? Whichever country is chosen, does blocking that connection leave me better protected than if I did not block it?" High usage websites are hosted on networks like Akamai, using servers all over the world. DNS is used to direct you to the data center that has spare capacity and sufficiently close to your location. The actual destination can be different on different days. 
 I say all this from experience and from conversations with product management. We use country blocking in both directions, but we are an exception.