Country Blocking Not Working for a WAN > LAN Rule

Hi.  It seems like country blocking is not working for WAN -> LAN (or any other protected network behind XG Firewall).

I have tested this with a proxy in the blocked countries.

I have this rule at the top of the list and network traffic still passes even though the rule shouldn't allow it, basically ignoring it.  The rule is never triggered thus always stating in 0 B, out 0 B.  I have tried every combination of Source/Destination/Zone/Network and still it doesn't work.

  • In reply to Aditya Patel:

    Hi Aditya,

    the country blocking does not work even after a restart from power off. I am talking about incoming and outgoing. If as I tested earlier you block all countries that works, but specific countries no that does not work. Yes, I have the rule at the top.

  • In reply to Aditya Patel:


    I have been testing using a public facing web site behind my firewall and the tools Geoscreenshot and Localbrowser to test.  I'm just looking for the site to be inaccessible from blocked countries.

    I have two country blocking rules in my configuration, but only one is enabled at a time.  This is the first is a network rule.  This rule does not work.  When it is enabled (and the other rule disabled) Geoscreenshot and Localbrowser are able to load my site from blocked countries.  I have not seen this type of rule block stop any traffic.

    This is the second rule.  This rule uses the workaround that BenVerschaeren explained earlier in this thread.  This rule works.  When it is enabled (and the other rule disabled) Geoscreenshot and Localbrowser timeout when trying to access the site from blocked countries.  This workaround is a good bandaid, however it is not an ideal solution.  With this rule, my network actually allows connections on all ports from blocked countries.  The traffic is sent to a black hole address, it is not actually dropped.  This results in additional interest from port scanners, that results in increased malicious traffic headed towards my network.

  • I have read through this thread and forgive me if I missed it, but it wasn't clear to me whether or not this is a confirmed bug in the XG or not?  I've seen some various workarounds offered (thanks for those) but has Sophos confirmed this is a bug?  If they say its not a bug (I have no idea how that could be true) is there a feature request somewhere we can upvote?

  • In reply to Bill Roland:

    No, this issue has not been recognized here by anyone from Sophos.  It is also still missing from the known issues list.

    In his post on page 2, Aditya Patel demonstrated that the IP to country mappings are working correctly (which had already been proven in this thread).  But there has been no other information about the actual issue that blocking by source country in a Network Rule is broken in XG.

  • Finally had a chance to update to MR3.  This issue remains unfixed, and is still missing from the known issues list.

  • In reply to JD MaC:

    Hi All, 

    You may need to check the scenario, for instance, if you have created a DNAT rule a Business application Rule is needed not simple firewall rule. Additionally, you may check my taking a VPN connection and test from the address of another country and Allow/Block the country host . 

    In any instance, the issue occurs that the host is not blocked you may need to check the command mentioned earlier to verify the country reported on XG and verify with any third party website to validate . 

    There is an ongoing issue for Wrong Country Classification for IP address and need to confirm if that is the case here. Reference: NC-17519

  • In reply to Aditya Patel:


    Just to remove any confusion, I am not seeing any issues with country classification.  If you see my example earlier in this thread, the Business Application Rule used as a workaround is using the same country definitions and is working correctly (although with the limitations I describe in that post).


    Here is the scenario I am trying to work through: I have several DNAT Business Application Rules doing port forwards.  I would like to prevent connections from specific countries from accessing these open ports.  I have created the Network Rule in my example above to attempt to prevent this.  If I am reading your reply correctly a reject Network Rule will not override a DNAT Business Application Rules?


    If that is the case, what is the correct method to apply country blocking to a series of DNAT rules?  I am assuming (hoping) that I do not need to use the Blocked Client Networks in every single DNAT rule instead of managing this centrally in a single blocking rule. 

  • In reply to Aditya Patel:

    , how is the status of Country blocking?

    It simply does not work on Wan to LAN Firewall rules. This is a bug and it is not even tracked. Users cannot use this features.

    Can you update us? We expect to see Reference NC soon.


  • In reply to lferrara:


    I can see this thread has gone on for a while and there has been a lot of confusion.

    The issue that Aditya referenced above (NC-17519) relates to incorrect classification of IP address to country definition in certain cases, so I don't think that directly relates to the original issue in this thread. E.g Country blocking WAN to LAN simply not working at all.

    I'll try and setup some tests here to test this behaviour, as it isn't something i have come across before, and update you.

    In the meantime, if anyone has anyone support case references where this has been raised or "NC-" reference numbers that they have been given by Sophos Support in relation to these symptoms can you private message them to me?



  • In reply to lferrara:

    Hi All,

    I can confirm that this is something that has been logged and the intention is to change how this behaves in v17 MR1. The reference for this change is NC-17413 in case anyone needs an update on the release version from Support.

    Interestingly, the root cause of this isn't specifically connected to country blocking itself, but is more related to the way that zones work internally in relation to DNAT and business application rules. I'll spare you the technical details, but suffice to say the plan is to change how this works so that it aligns more with how one would expect the configured ruleset to behave.

    In the meantime, IP based access to a given DNAT can be controlled either within the DNAT rule itself, or by placing another DNAT rule above it to blackhole the traffic as already mentioned in this thread.


  • In reply to GregH:

    thanks for your reply and info. What is strage and unacceptable is that Sophos took more than one year to give us an official answer and a NC number.

    This should never happen!

    Many users have forgotten this feature or even explained to customers that the feature Country Blocking is half working (not in all area).

    Really disappointing thing!Angry

  • In reply to lferrara:

    Hi Luk,

    I agree this thread has become a little confused with discussion of the IP classifications which hasn't helped the communication, which is why i wanted to try and clear this up.

    The advice we would always give to get an official answer on potential bugs or changes to the product is to log a case with Sophos Support, they will then be able to provide the correct information along with the reference IDs where applicable. I can see support cases have been logged for this particular issue and the correct information provided to the customers logging those cases, but that hasn't filtered down to this thread.

    This thread was brought to my attention via a support case that was logged earlier this week.

    By the way, on an unrelated note, thanks for all the posts and information you contribute on this forum, it is appreciated.


  • In reply to lferrara:

    Hi Luk,

    As Greg mentioned, the issue is not completely related to the Country Blocking module but it affects the discussed feature. I understand your concern towards the delay in creating the NC-ID but looking at the issue there was a working work around to blackhole the IP addresses and meanwhile, there were a lot of bug fixes during this time. Please be asure that we are continuously working on the XG firewall and  the accountability of bug fixes are considered on the basis of the criticality of the issue. 


  • In reply to sachingurung:

    Silence and sometime in the future are quite different period of time and they have different meaning. If there is SW code there are bugs and no one complains on that. What we are not happy and really angry here is the silence for a long time and then...pooof someone from Sophos reported the NC and gave even an expected release version.

    So be sure to properly report time and NC most efficently here and to all users. Another issue that is around the forum are bookmarks. There is an NC number but it does not cover all issues (I guess).

    Taking a year to have an answer is more than alot. Be sure to at least inform as that it is a bug, your are investigating, or whatever phases you are but the silence is the worse phase users accept.

    Silence means poor quality!

    Kind Regards

  • In reply to lferrara:

    We understand the concerns but the NC-# was not created until v16-MR1 and the JIRA was not directly referenced to the country blocking issue, which is one of the reason my team was not sure to reference it. We were already discussing this internally but we were not able to get a solid case reference on this issue. The cases were mostly resolved configuring a blackhole business rule and it is an accepted solution as we see. 

    We work as a tangant team between the Support and a Customer hence we can only report and expidite the NC-# if they are already created & reported but we cannot emphasize on creating one of the NC#. The reason we were not able to provide an update on this issue is because, the workaround was accepted and the cases were never reported in the escalations or went cold. 

    I will take the responsibilities of such unresolved thread, please PM me and I will make sure they are immediately looked upon by us and the support team.