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 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.



This thread was automatically locked due to age.
  • 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.

  • Aditya,

    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?

  • 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.

  • 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

  • Aditya,

    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. 

  • , 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.

    Thanks

  • Hi

    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?

    Thanks

    Greg

  • 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.

    Greg