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

Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 139 replies
  • Answers 4 answers
  • Subscribers 76 subscribers
  • Views 47068 views
  • Users 0 members are here
Options
Suggested
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: v19.5 MR2: Feedback and experiences

LuCar Toni

Release Post:   Sophos Firewall OS v19.5 MR2 is Now Available  

The old V19.5 MR1 Post: Sophos Firewall: v19.5 MR1: 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. 



This thread was automatically locked due to age.
Parents
  • 0

    Would be a relief to be able to also use FQDN objects in ACL exception rules, so you can use a DNS entry for proper remote support address maintenance

  • 0 in reply to ddcool

    Hello ddcool,

    a FQDNs have long been supported in ACLs...

    Regards

    alda

  • 0 in reply to LuCar Toni

    I agree that no software or hardware is perfect. Bugs happen, and it's impossible to say otherwise in any solution. And I don't like keeping access open when not necessary, especially in a security device. The smaller the surface area, the safer!

    I'm just saying that the tools aren't finished yet to maintain management. (FQDN in ACL rules, and multi-tenant rule deployment.) We really, really need those tools to retain manageability across > 1000 devices. As FQDNs are not available in ACL rules, we have to manually update all our firewalls in case of an access IP change.

    We currently rely on SSL VPN with 2FA as our backup access. As that doesn't get accessed much for firewalls that don't need SSL VPN, the .ovpn files can become outdated, since the process to retrieve them isn't automated. That makes our backup access unreliable going forward. It also means that the user portal needs to be turned back on and off manually any time a client needs to add a new remote-only worker, or anytime an existing worker needs to use SSL VPN if they haven't used it after a change that triggers a new .ovpn file.

    Usually the latter gets discovered by a user after-hours, so this will trigger an increase in after-hours support calls for us. A way for Sophos Connect to not need the User Portal is also needed ASAP for these scenarios, and should have coincided with this charge.

    I want to note that I'm not trying to be argumentative for the sake of argument. I applaud the charge to disable WAN access in a default deployment for the people who just drop in a firewall without actually understanding the necessities of security. I'm just arguing for a focus on the features needed for those of us that manage multi-tenant deployments, which is pretty much every MSP out there. Shutting down other access should be done *with* the roll-out of other solutions, not when in a "coming soon" state.

  • 0 in reply to Joshua Drost

    We will not install the update for our customers for precisely these reasons. We don't care about the user portal itself. But the VPN configuration must be able to be retrieved or updated at any time.

  • 0 in reply to Gerhard Seemüller
    Gerhard Seemüller said:
    We don't care about the user portal itself. But the VPN configuration must be able to be retrieved or updated at any time.

    I raised this issue in this post - Sophos Connect and delivery of configuration via User Portal

    At the time,  reported that Sophos plan to change this behaviour:

    "We've brought your concerns up internally and our Development Team is currently in the works for a new method that would eliminate the need for the User Portal to be exposed on the WAN for SSL VPN RA use. We plan to implement this in the future release."

    Can someone at Sophos confirm that this is still planned?

  • 0 in reply to JasP

       - Yes, that feature is being worked on and is planned for v20.0

  • 0 in reply to Giridhar Katti
    Giridhar Katti said:
    JasP  - Yes, that feature is being worked on and is planned for v20.0

    Thanks for confirming that, it is good to hear.

    I was a little concerned that with the changes in this release regarding WAN access, that this had been dropped, and the current changes were regarded as a solution to the problem, which they clearly aren't for this particular issue.

  • 0 in reply to Giridhar Katti

    How long do we have to postpone updates then?

  • 0 in reply to Gerhard Seemüller

    You shouldn't have to postpone updates. You can keep the WAN access to the user portal with an ACL rule like this:

    Or even better, if you know that VPN access only comes from specific countries, lock down the Source Network to only those countries.

  • 0 in reply to jamesharper

    I'm curious if that won't be overwritten.

  • 0 in reply to Gerhard Seemüller

    No, ACL rules won't be overwritten, even if User Portal is not actively being used on WAN. 

    However as others have said, keeping User Portal or Admin open on WAN when not required/in use is a security risk, and not recommended.

  • 0 in reply to bobbylam

    Good to hear. It is necessary for VPN provisioning. In some environments, the user portal is also used for clientless access connections, so turning it off is out of the question.

Reply Children
No Data
Unfiltered HTML