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

How to fully block/drop packets from a malicious WAN address?

Hi,

Since upgrading to V18 where NAT and Firewalls have been separated. How would I be sure to fully block and Drop a malicious WAN address traffic from hitting our web facing services?

I have written a drop rule containing a list of IP Addresses as sources from WAN zone and placed it at the top of my firewall rules, but I'm still seeing Allowed traffic against my Port Forwarding Rules (example shown)

Do I also need to write a specific NAT rule to block these malicious WAN IPs? If yes what would this look like?

Thanks,

Craig



This thread was automatically locked due to age.
  • Hi  :  Please share the snapshot for rule id 71 and NAT ID 35 here for reference. 

  • Hi Vishal_R

    Thanks for your interest in my question.

    Please see below screenshots of FW Rule 71 and NAT Rule 35

    Thanks,

    Craig

  • Hi  :   Thanks for sharing the snapshot. With current XG architecture under certain circumstances, when there is a DNAT rule for port 443, but there is also a DROP rule for inbound traffic on port 443 from the WAN zone, the connection is being passed to awarrenhttp (web service ) to reflect or responds with a block page of Sophos. 

    So your traffic is dropped only by firewall but you are able to see this with action as in allowed  in log viewer due to above behavior. 

    If you will check by generating traffic for any other port apart from 80 and 443 from outside IP by adding it in block list then you will get the expected result.

    Currently this is known behavior and it is in scope of improvement in near future and probable fix version marked is V18 MR-5 as of now.

  • Hi Vishal_R

    Thanks for your very informative answer. I have further checked the logs and can see that ports other than 443 are indeed getting blocked (Denied) with Appliance Access as the Log reason.

    Also thanks for confirming that this will be fixed in a future release, I look forward to it.

    Best Regards,

    Craig