Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

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

Sophos Firewall: v20.0 GA: Feedback and experiences

Release Post:  Sophos Firewall v20 is Now Available  

The EAP Post:  Sophos Firewall: v20.0 EAP1: Feedback and experiences  

The old V19.5 MR3 Post:  Sophos Firewall: v19.5 MR3: Feedback and experiences  

To make the tracking of issues / feedback easier: Please post a potential Sophos Support Case ID within your initial post, so we can track your feedback/issue. 

Release Notes:  https://docs.sophos.com/releasenotes/output/en-us/nsg/sf_200_rn.html 



This thread was automatically locked due to age.
Parents
  • Hello,

    And still no lets encrypt support.  Dont tell me to use some extra software, sorry. This should be done by the FW.

  • Thanks for your feedback. Lets Encrypt is on the roadmap for a future version. 
    You can automate it with things like Sophos Factory or a script based approach, if you want. (Even better by doing it by the Script based, as you get a Wildcard Certificate, which is usable for multiple instances). 

    __________________________________________________________________________________________________________________

  • For now I had a WAF rule with path specific routing pointing to a server to /.well-known/acme-challenge/ That would auto update the certs on the server. Since upgrading to version 20 that rule no longer works. It always worked fine under v19. Any ideas why that would now break and where in the logs do you think I could look to find an answer?

  • Check the /log/reverseproxy.log if the WAF in general work. 

    __________________________________________________________________________________________________________________

  • I actually did find it. It is treating now as a Bad Reputation with the message SXL category IPCAT_BOTS. I might try to see if I can get around this some way.

  • Hi Barry, if it gets blocked by IP rep, then disabling reputation based blocking should solve this.

  • That was the first thing I tried. I can even set Protection to None and Intrusion Prevention to None and it still gets blocked. The only way I can get it to work now is to NAT to the server, but I would prefer WAF worked as before. Is there any other place to add an exception? The firewall shows the traffic is coming from letsencrypt.org

  • That doesn't sound normal. If you have no protection and IPS policies, then the request shouldn't be blocked on IP reputation, unless it is caught by a different rule. At the moment I doubt an exception would help here. I think you should open a support case and then we can take a closer look at the system. Or you can just share the log with me over PM, and I can take a quick look to see how to proceed further.

  • I got it to work. I disabled the reputation based blocking. At first I was disabling that on the WAF rule I had set for the acme challenge, but the rule that was actually blocking it was the WAF rule for the website itself. I changed it on that rule and it worked. Thing is I would like to have reputation blocking on the website rule.

  • Without seeing your configuration it's hard to tell for sure, but I assume you have two rules for the same domain, one on port 80 for the HTTP challenge, and then one for port 443 for the actual site over HTTPS. If that is the case, then the two rules should be independently configurable in most cases.

    What might be an issue is HTTP redirect in the HTTPS rule. If you have that ticked, then it might catch all port 80 traffic for that domain, the challenge request included, and then the rules from the HTTPS rule will apply. In this case you could disable HTTP redirect, or try to set up a separate site path route in the HTTPS rule for the ACME challenge path and use a policy there with disabled reputation based blocking. This way the rest of the site will be able to use reputation based blocking. Whether the second approach works depends on how Let's Encrypt handles when the challenge goes through the redirect from 80 to 443. Since it worked for you in the past, it might work.

Reply
  • Without seeing your configuration it's hard to tell for sure, but I assume you have two rules for the same domain, one on port 80 for the HTTP challenge, and then one for port 443 for the actual site over HTTPS. If that is the case, then the two rules should be independently configurable in most cases.

    What might be an issue is HTTP redirect in the HTTPS rule. If you have that ticked, then it might catch all port 80 traffic for that domain, the challenge request included, and then the rules from the HTTPS rule will apply. In this case you could disable HTTP redirect, or try to set up a separate site path route in the HTTPS rule for the ACME challenge path and use a policy there with disabled reputation based blocking. This way the rest of the site will be able to use reputation based blocking. Whether the second approach works depends on how Let's Encrypt handles when the challenge goes through the redirect from 80 to 443. Since it worked for you in the past, it might work.

Children
  • What you are describing is exactly how I have it set up. I do have http redirect on the website rule. That's a good idea, I will give that a try. BTW, I did disable the acme challenge rule and it did not work, but in that case the http redirect would have still been in effect. I'll post back after I test this.

  • I tried the path rule in the HTTPS website rule and unchecked the HTTP redirect, but it did not work. What was strange is that the log now showed the ACME challenge rule now blocking the request. The challenge rule has always been before the HTTPS rule in order of processing. I do know that prior to trying this the log showed the HTTPS rule doing the blocking. What I did next was change the HTTPS rule back like it originally was and created another policy just for the challenge rule to not reputation block. That now works everytime. However, since I made this change I now longer see the request at all in the Webserver Protection log either for allow or deny. Anyway, its working. What I am trying to understand is why the rule that was doing the blocking changed in the logs with me not changing the order. Also, I tried the new policy on the challenge rule yesterday and it still showed the HTTPS rule as blocking the request. Very confusing.