Sophos Firewall: v19.5 MR2: Feedback and experiences

We make changes to the SSL VPN settings here and there that require a new .ovpn file for users. I'll admit that I love Sophos Connect for this, since the changes essentially auto-deploy. Are you saying that a successful Sophos Connect connection won't necessarily reset the 90-day timer on User Portal access?

I may not be sure what you're referring to when you say "Using the Access" though. If Sophos Connect only defaults to pulling the .ovpn file when the locally cached .ovpn settings fail, then accessing SSL VPN won't usually reset the User Portal 90-day window. If it pulls the .ovpn settings every time in the background using the User Portal, then it would reset that window.

Ultimately I just want to know the best way to keep WebAdmin and User Portal access going for my clients where it's only used maybe a few times a year, and from possibly-changing public IP addresses. I can update an FQDN as needed for WebAdmin, but we've had clients in the past go from SSL VPN users connecting once a year, to once a week, because they transitioned some people to WFH. We can go in and re-enabled when this happens of course, but it's hard to explain to the clients why their SSL VPN stopped working if it's by design and can't be changed.

We would just prefer it stayed working, but just be hardened instead. Public-facing logins can be pretty locked down with industry standard stuff: 2FA, Captcha, geo-blocking, failure timeouts and IP auto-bans, active check-in and monitoring with error reporting, third-party code reviews, etc. Much of this is already implemented, but just not fully tied together.

RCEs happen. Geoblocking, 2FA, Captcha etc, cannot protect you against 0Day RCEs. Generally speaking, your strategy should be to keep services unavailable, if not needed. 

Every successful login to user portal / webadmin will reset the timer. So essentially, if you need to change the config of OVPN in generell, you could enable the user Portal again. By the way, as mentioned will there be a new way to download the config in the future without the User Portal. 

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.

One reason I don't want to upgrade, they limit home use to 6GB, yet forget about 64-bit usage and keep adding on mem usage.  I'm sitting at 70% on average already as it is.

I had that happen too during one of our HA upgrades. We had to remove and re-create the HA connection from scratch to get it to work. The secondary upgraded fine and took over but the primary was unresponsive, and had to be physically restarted to even get into it's GUI or SSH. Once we did that, we were able to go into the GUI, remove the HA completely from both, upgrade the primary, then re-create the HA.

Frustrating endeavor because it was an active-backup HA, and the secondary didn't take over the license in the re-creation process. Had to remotely add an evaluation license for the necessary firewall features for it to function properly while we did the work. Hopefully it doesn't happen again since that serial number has now burned it's evaluations, but we do also have the option of adding a 1-month MSP license to it through Sophos Central Partner in that case.

I think that the primary firewall should have another management IP address in case of these kinds of issues, separate from the regular address that they both take together when in HA, much like the secondary has. But it wouldn't have mattered in this particular issue as the only access available was console until it was rebooted. I'll need to set up OOB console access for these kinds of deployments going forward, or at least OOB power outlet access to force reboots. But I do hate shutting down non-gracefully, as that occasionally corrupts the PostgreSQL database.

I wonder if the hardware could include a small battery (similar to RAID controller battery size) that does a graceful shutdown when no AC power is found? But that's a huge ask, as it's not an easy thing to implement without possible false-alarm shutdown events, and would have to monitor at the hardware level to be reliable, not the software level. Maybe the higher end versions have this? I was using an XGS 2100 if I remember correctly, so I wouldn't be surprised if bigger models have it, but I haven't looked.

Hi Enrico van Egmond1  - We had a discussion on this issue internally. Can you please disable this "any" "any" rule(3rd rule in the list) from the SDWAN routes ? It should solve your problem.

After disabling the SD-WAN route the Static IP SSL VPN works good. Traffic is routed correctly from VPN connected device to LAN and from LAN to the VPN connected device with the static IP. It's still strange why this is no problem on dynamic IP's with SSL VPN connected devices.

This release appears to have broken our SNMPv3 monitoring.

We use AES Encryption and MD5 Authentication (because that is the only combination that fits with our monitoring software) and since upgrading, we can't connect.

I have tried deleting and recreating the settings on each end but it didn't fix it. For the moment we have changed to SNMPv2 monitoring.

70% is not particularly high for this type of device, it isn't a workstation or server. Memory management is generally pretty good. We have run multiple devices for years with a base of 4GB and 80-90% memory usage without issues.

Hi Enrico van Egmond1 

When SSLVPN is configured with a static IP address, SSLVPN service sets nfmark mark on SSLVPN tun interfaces.

ip link set tun0 nfmark 0x300

ip link set tun1 nfmark 0x301

Note: Based on the number of OpenVPN instances SSLVPN service will have an equal number of tun interfaces.

So if SSLVPN static IP connections have a matching SDWAN route then the 0x300 mark is overridden by the SDWAN route, which causes SSLVPN connections to send traffic on the SDWAN gateway instead of the tun interface.

Where as for SSLVPN dynamic ip, when we assign the Dynamic IP to the user, we provision the route on the client, which is in the same network as tun interface. Hence there’s no issue w.r.t the traffic.