Guest User!

You are not Sophos Staff.

  • I have a really interesting problem with my updated Sophos XG

    Previously i updated to V18.5 MR4 the problem is still exists in SFOS 19.0.1 MR-1-Build365

    The problem:

    WAF is not working reliably, for you to understand after the upgrades i needed to remove any kind of protection policy to make it working again or if i had any interface what didnt have an ip address or disabled and this interface has attached to a WAF policy the whole WAF has stopped working (ALL OF OUR INTERNET FACING WAF RULES)!
    Now if i create a new WAF policy they simply just dont work, they dont respond to any requests!
    One interface that attached to some waf policies is working normally.

    This is happening after reboots or after these upgrades.


    Has anything been changed in the firmware that would affect these?

    The setup is:

    3 WAN

    Example WAF1: #Port1
    Example WAF2: #Port2
    Example WAF2: #Port3


    Now only the Port2 variant working

    if i use curl to try a request just a "Connection refused" what i get.

    This is not happened before V18.5 MR4 or V19

    Thanks for any kind of suggestions about this!

  • Hi,

    I think there's two separate issues here. 

    WAF is based on Apache, and Apache needs an IP address and port combination to bind to. So you cannot have a WAF rule on an interface that doesn't have an IP address, it would result in an incorrect configuration and Apache won't start. That might be what you see.

    The second one, WAF not working until you remove the protection policy might be the result of a known issue, where the WAF configuration becomes corrupt during upgrade or backup/restore if you use static URL hardening, form hardening or cookie signing in the protection policy. This corruption will prevent Apache from starting up. You can check log/reverseproxy.log on the device and look for errors there, a clear indication of this problem is a line saying 'invalid encrypted key'. If you see that, you can reach out to support, they have a workaround ready to handle this case. Or you can disable these features in the protection policy, that should also allow WAF to start.

  • Hello!

    Thank you for the first one, that  was is dont thinking about... my fault

    The second one thank you, but the interesting thing is now i have an interface what has an ip address and im bind it to a waf rule  then the waf not responding to it

  • That could be due to the second problem with the database corruption, unless you already removed all protection policies from all WAF rules.

    Check reverseproxy.log for errors, or you can open a support case and someone from the development team will take a look at the box.

  • Hello there,

    Most likely a database issue. 

    You can confirm by checking the csc log in debug mode; look for "monitorid" in the log after you have put csc in debug mode and replicated the issue.

    Also the postgress should show some error related to the same "monitorid"

    Regards,

  • I revert back my HA to 18.5 MR4 the same thing happened, but i recreated the WAF rules and now it seems to be working...
    And i had a 40min outage because i switched between HA...

  • We have just changed our site to site IPsec VPNs (Tunnel Interface) to use specified local and remote subnets (instead of 'any' and static routes). There is a small bug in that you can't rename the xfrm interfaces in the Network, Interfaces section. Gives the error message "You must configure at least one IP family" (which you can't do if you use specified local and remote subnets).

  • Did you change the IP Family in the IPsec tunnel? 

  • Just noticed that the DPI engine / Application Filter isn't picking up iCloud+ relay traffic.

    The link below provides the details

    https://developer.apple.com/support/prepare-your-network-for-icloud-private-relay

  • DPI Engine cannot use QUIC Protocol. But you can block it, if you want. 

    Apple seems to use QUIC for this feature. iCloud Private Relay uses QUIC, a new standard transport protocol based on UDP. QUIC connections in Private Relay are set up using port 443 and TLS 1.3, so make sure your network and server are ready to handle these connections.