Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 5127 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Country Blocking & False Positives.

dimaestro
Has anyone else experienced false positives for country blocking within the past week?

I found that my UTM was blocking all communication with any google servers, claiming that they were based in china (Yes, I block all comms to china).

Anyone else see this?


This thread was automatically locked due to age.
  • 0
    Hi, dimaestro, and welcome to the User BB!

    Google and others do have servers in China, so you will need to craft some exceptions for that.

    Cheers - Bob

    Sorry for any short responses.  Posted from my iPhone.
  • 0 in reply to BAlfson
    Yep, Seems to be an issue. TTT
  • 0
    I also have China blocked on the UTM, and I'm having the same issues with accessing Google services. It first happened when trying to access a blog on Blogspot. Now I accounts.google.com is blocked, which means I can't log into Google accounts.

    The weird thing is that when I try to access Blogspot, I get the UTM's standard "Content blocked" page notifying me the URL matches a forbidden country. But accounts.google.com just tries to connect until it finally times out. I had to check the firewall's live log to find out it was the firewall dropping the packets due to country blocking.

    However, when I run a trace route to the IP address for accounts.google.com, whether using an online tool or from a utility within my network (with country blocking disabled, of course), the geolocation for the IP comes back as USA.

    This makes sense, because regardless of whether Google had servers in China which could serve the data, it wouldn't make any sense to do so for a US-based request simply from a performance standpoint.

    Which of course begs the question, why then is the firewall's Country Blocking dropping connections to Google services?

    For what it's worth, I'm running version 9.111-7.
  • 0
    You'll want to check the logs on the UTM to verify why the UTM is doing what it is doing.  The live log info is handy but the full (raw) logs should be checked as well.

    However, you won't find the destination IP in the proxy logs when it blocks because of a bug:  https://community.sophos.com/products/unified-threat-management/astaroorg/f/81/t/65755

    Other recent threads on the subject of country blocking include more information on the GeoIP system, and websites & scripts/commands to run to check GeoIP information:
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/t/46298
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/41517
    https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/41527
  • 0
    Apparently, conntrack takes effect before country blocking, so just blocking traffic "From" China should allow responses to your requests to Google.  Any luck?

    Cheers - Bob

    Sorry for any short responses.  Posted from my iPhone.
  • 0 in reply to BAlfson
    Thanks, teched and BAlfson, for the information. I appreciate it.

    When the next geoip update window rolled around on the 11/12th of the month and the UTM continued to block access to accounts.google.com I did some checking using some geoip services. None of the services I tried
    placed the IP for accounts.google.com in China.

    So I changed Country Blocking for China from "All" to "From," and I can confirm that access to the formerly blocked Google services has been restored, BAlfson.

    For what it is worth, here is full log entry from the UTM for a blocked request to a Google domain when I had Country Blocking set to "All" for China: 

    2014:05:10-02:55:49 remote ulogd[4401]: id="2021" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped (GEOIP)" action="drop" fwrule="60019" initf="eth0" outitf="eth1" srcmac="[REDACTED]" dstmac="0:15:5d:1d:4f:3" srcip="192.168.2.54" dstip="74.125.70.84" proto="6" length="52" tos="0x00" prec="0x00" ttl="127" srcport="51029" dstport="443" tcpflags="SYN" 
  • 0
    The obvious issue with "to" "from" is that most viruses don't setup an external port on your firewall for traffic to arrive "from". So they will send traffic "to" the listening server on the other side. This will often go over port 80/443/53,etc (common ports), so blocking "to" all of a sudden is important as you might not notice common traffic types going out to malicious listening nodes. China, russia, turkey, the U.S.A, etc are all hot spots for traffic to travel "to". DDoS attacks and the like will bring traffic in from all over the planet so blocking "from" helps in that case, however it's likely the connection, middleware or logging will come to a halt and blocking "from" will not matter anyway.