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

Firewall policy "drop" shows block page on HTTP connections

When I configure a policy to "drop" on all destination IPs and ports, I expect it to drop the traffic without notifying the user. However, I am receiving the "Stop! This website is blocked" page when I try to view any HTTP website. I would like it to drop the packets silently. How do I configure this?

I am running SFOS 18.0.1 MR-1-Build396



This thread was automatically locked due to age.
  • Hi,

    I think this is part of the expected behavior from Web > User notifications.

    I tested on my XG with the same build, a Drop rule would notify the user when browsing to HTTP (or decrypted HTTPS).

    If you add a Reject rule instead of Drop, then the user gets a TCP RST response from the firewall instead of the HTTP block page. Not a silent drop but no notification or web redirect to a block page.

    You can also add an Allow rule for HTTP with Deny All as Web Policy, then go to the Zone of the firewall and turn off the Captive Portal:

    System > Administration > Device Access > remove Captive Portal*

    Note: 

    Turning off access to captive portal stops user notifications from appearing. Example: Web filter and Sandstorm notification pages

    this is a little different than Reject (TCP RST) because the user might get redirected to the XG IPS block page (in the browser URL bar) but the page will not display.

    Ex: XG_HOSTNAME:8090/.../default

    hope that helps,

    Patrick

  • Patrick is correct, that is the way it is intended to work.


    If you hit a firewall rule for Block on port 80 or 443, the XG will complete the TCP connection and will display an HTML block page.
    If you hit a firewall rule for Reject on port 80 or 443, the XG will not complete the TCP connection.

    If you are using AD SSO and there is no authenticated user:

    If you hit a firewall rule for Block on port 80 or 443, the XG will complete the TCP connection and will redirect to port 8091 to in order to attempt AD SSO authentication.

    This is a feature used by many customers to perform authentication.  Basically it is "if you hit a block rule then authenticate".

  • Is there any way to drop the packet silently? I am currently null routing, but that's a dirty hack that I'd like to avoid. 

  • AFAIK, firewall rule Reject, as I posted.

  • Kia ora folks,

    I'm new to Sophos XG and so far I'm really liking it but it seems very odd to me that a firewall can be incapable of dropping packets on a drop rule! I have a /29 of public IPs routed to me by my ISP and when some hits them externally they get a Sophos blocked page. I really don't want this. I understand I can use a reject rule but I really just want to drop the packets silently. Just like a firewall would do. I also understand I can also do a clunky workaround with a DNAT rule to NAT it to nowhere, but not ideal. 

    The response to this feature request seems to suggest there is a way to turn off the redirect to the blocked page in version 18? But I haven't been able to 

    "...redirection to the proxy is now optional."

    https://ideas.sophos.com/forums/330219-xg-firewall/suggestions/34371889-port-80-and-port-443-is-not-blocked-by-the-firewal

    Cheers,

    Rhys


  • Please make sure that your external port is set to be WAN. Make sure that you have no firewall rules with source WAN/Any and Service 80/443/Any. An external client trying to use your XG as a proxy into you network should get a block page from the web proxy. That suggests a poor configuration.

    If you are trying to host internal webservers, look at the "Web Servers" tab on the left. This uses firewall "business application rules" (v17) or "server access assistant (DNAT)" (v18). As far as I know if neither of these are configured, you should not be getting a block page.

    The link and reply refer to LAN->WAN access.  For LAN->WAN typically you don't want to block all web traffic, you want to do something like block all unauthenticated web traffic.  In order to support that, it is harder to configure completely dropping internal to external traffic.

  • Hi Michael,

    Thanks very much for your reply. I'm quite ok with internal clients receiving a block page. It's just the external visibility I'm concerned about. I don't want to advertise that there is anything there at all.

    I'm not actually using any of the /29 addresses at the moment - they are the 202 addresses and the 123 address is the PPPoE WAN address which they are routed to. I've just got a couple of services being DNAT'd from the WAN IP -  SSH and another app on port 52341.

    It's worth noting, I don't get a blocked page when hitting the WAN (123.x.x.x) address, only when I hit the /29 202.x.x.x addresses. 

    As far as I can tell I've got everything configured as per your advice. Here are my interfaces, rules, and zones: 

    *edit* Full size images can be viewed here 

  • I am not an expert in the full firewall or network.  I'm an expert in the Web proxy.  So I may not be able to help.

    Can you open up Log Viewer, use the icon to switch to detailed view, change the log to just Web Filter.

    Replicate the problem.

    Is there anything about it in the Log Viewer?  If so, can you post here?  This should show the firewall rule that is being hit.

  • Edit your Default Drop rule.

    Switch ANY (in Source zone and Destination zone) with all zones.

    Do not add WAN in the Source zone, instead all other zones. 

    That should do the trick. 

    __________________________________________________________________________________________________________________

  • Thanks LuCar. Yes that did it! Thanks! Although I'm not 100% clear about what I've done or why it works. Are you able to explain a little more.