Sophos Firewall: v18.5 MR2: Feedback and experiences

Suggestion:

• Add Dark theme. 
• Add option to display Host in the browser tab to identify which firewall it is. This helps when working on multiple firewalls at the same time.
• When adding a new interface such as VLAN, give an option to create another one while the first one is been created. GUI takes forever to create the VLAN and then drop you back to the Network tab. This is really time-consuming when creating multiple VLANs during the initial setup.
• Add DHCP creation at the end of the new interface creation window. Give a check box for enable when created.
• Create a link from the DHCP lease to reserve the select lease. (Instead of copying the MAC, go into DHCP, then add there.)
• Give an option to NOT monitor and interface state. Sometimes, we left one LAN interface open and only use it to configure directly when all other interfaces are VLAN and there is no managed switch to use. Because this port is configured but unplugged, the home page always shows yellow on the interface. 
• In general, GUI is too slow even on high-end CPUs. To much wait time on each action. On a fast CPU(E3-1220), 20% of the time is waiting for GUI to load or action to complete. On a slower CPU(J1900), this goes up to 60-80%.
• Remove the WiFi interface or option to turn it off. In any case, there is no wifi directly on the firewall but connected via other interfaces.

Bugs(?):

• When WAN is on DHCP and WAN port state changed, WAN IP is not auto retrieved after the WAN state becomes online. WAN interface requires a change from the GUI to update the DHCP information. (In other words, when changing the WAN to a different IP, auto-update either take forever to happen or never auto-update.)
• When accessing Admin HTTPS from WAN, sometimes, the view log window from the GUI will cause the session to terminate. This requires a firewall reboot to fix. (I know WAN access is not recommended. This is only used for stagging..)
• From time to time, firewall rules drag to change orders stop working. (Suggestion: add the move up/down button directly on the rule/group.)

Hi,

I have managed to fix this issue on my machine.

For some reason, after the 18.5.2 MR2 upgrade, the files /conf/sysfiles/heartbeatd/server.key and /conf/sysfiles/heartbeatd/server.crt get deleted.

After a lot of fussing around, I found this fix works.  Get to the Device Management Shell (#) and run the following,

cd /conf/sysfiles/heartbeatd

cp /conf/certificate/internalcerts/ClientAuthentication_cert.pem server.crt

cp /conf/certificate/internalcerts/ClientAuthentication_cert.key server.key

chown root:heartbeatd server.*

service heartbeat:restart -ds nosync

service enhancedappctrl:restart -ds nosync

If you now look in /log/heartbeatd.log everything is working just fine.

Hope this helps,

--Thomas

Can you please provide a download link?

through Sophos Central and the download portal I only van download the MR 1 version still

See: Firewall Installers | Sophos

I am looking for the VMware installer. I tried to download:

https://download.sophos.com/network/SophosFirewall/installers/VI-18.5.2_MR-2.VMW-380.zip

But this is not a valid link somehow.

For the HW image it works:

https://download.sophos.com/network/SophosFirewall/installers/HW-18.5.2_MR-2-380.iso

The software image is also not available:

https://download.sophos.com/network/SophosFirewall/installers/SW-18.5.2_MR-2-380.iso

Kind regards,

Roger

this was a known issue in the release notes for the upgrade 

in mySophos License Portal I can also only see 18.5 MR1. 24 days after announcing this version.

We're on 18.0 MR6 and 18.5 MR1 is unsupported target version. I'd like to have the full installer available as backup to re-image the appliance if needed.

Thanks siuswat, I ended up sending the Qotom machine back (2nd time) and just got a Vnopn machine, which works without a hitch.  I did notice that the BIOS was more up to date on this one compared to the Qotom and for the Qotom, it was impossible to grab the latest BIOS to apply (any search would lead to dead links to the latest BIOS).  Finally ready to start getting this going.

DangoPC said:

When WAN is on DHCP and WAN port state changed, WAN IP is not auto retrieved after the WAN state becomes online. WAN interface requires a change from the GUI to update the DHCP information. (In other words, when changing the WAN to a different IP, auto-update either take forever to happen or never auto-update.)

I have the same problem with my 2nd WAN connection, its a DHCP LTE connection. I used it as a backup connection with WAN Link Manager, and the whole XG would become unstable with services crashing after some hours. Since I disabled/unbound the port where the LTE modem is connected, everything went back to stable.

we're having the same issue after upgrade

The clients will not pick a new hb certificate unless we pull the sophos installer from central, disable tamper protection, install over the existing intercept-x installation. when the installer want's to reboot, there is a new certificate in C:\ProgramData\Sophos\Heartbeat\Config\Heartbeat.xml

what a mess, this is so disappointing

the clients can obviously reach central, the firewall has a new certificate but the endpoints sit there like a duck, just throw SSL/TLS errors and you cannot do nothing else than reinstall.

XG:
[2022-01-08 07:20:51.369Z] WARN HBSession.cpp[30041]:344 bufferDisconnectEvent - Incoming connection from 172.16.xxx.xxx failed. SSL error: SSL routines:ssl3_read_bytes tlsv1 alert internal error
[2022-01-08 07:21:51.404Z] WARN HBSession.cpp[30041]:344 bufferDisconnectEvent - Incoming connection from 172.16.xxx.xxx failed. SSL error: SSL routines:ssl3_read_bytes tlsv1 alert internal error

Client:
2022-01-08T06:25:02.216Z [ 6952:10608] A ----------------------------------------------------------------------------------------------------
2022-01-08T06:25:02.218Z [ 6952:10608] A Starting Heartbeat version 1.15.783.0
2022-01-08T06:25:02.219Z [ 6952:10608] A ----------------------------------------------------------------------------------------------------
2022-01-08T06:25:02.279Z [ 6952: 7568] E TLS authentication failed after connecting.
2022-01-08T06:31:53.752Z [ 6952: 7568] A Connection failed.
2022-01-08T06:32:44.793Z [ 6952: 7568] E TLS authentication failed after connecting.
2022-01-08T07:09:19.245Z [ 6952:10608] A ----------------------------------------------------------------------------------------------------
2022-01-08T07:09:19.247Z [ 6952:10608] A Stopped Heartbeat
2022-01-08T07:09:19.249Z [ 6952:10608] A ----------------------------------------------------------------------------------------------------
2022-01-08T07:09:20.519Z [15420: 9900] A ----------------------------------------------------------------------------------------------------
2022-01-08T07:09:20.520Z [15420: 9900] A Starting Heartbeat version 1.15.783.0
2022-01-08T07:09:20.522Z [15420: 9900] A ----------------------------------------------------------------------------------------------------
2022-01-08T07:09:20.573Z [15420:15380] E TLS authentication failed after connecting.
2022-01-08T07:22:19.214Z [15420: 4968] A The connection configuration has changed. Reloading settings.
2022-01-08T07:22:19.221Z [15420: 4968] A The connection configuration has changed. Reloading settings.

Support was no help so far: case ID 04793577 

FWs re-registered to Central already

KB-000043489 is a dead end

KB-000037006 - which is for v17 and earlier has been applied by support. did not change anything

As far as i know, the certificate on the client (the content of the heartbeat.xml) will be updated by the policies. Which seems not to work in your case. 

What was the error in Endpoint self help, why did the client not fetch a new policy? "Update now" essentially gather new pattern etc. not Policies. (You can bypass the policy "Overwrite for 4 hours" as well on the Client). 

I would recommend to always check the tcpdump on the client and follow the traces, how the client updates its policies. The KB about DNS essentially talks about a problem, that the firewall will close basic communication to a service (like DNS) before the client can reach the central server. 

The SSL/TLS errors are expected, if the certificate is not trusted. So in general you need to update the policy from the client. Most customers i know, resolve this issue by simply waiting. The client itself gets the new certificate after some time. 

Restarting a MCS service seems not to trigger a policy update for your heartbeat or result in a error. So if you restart MCS, you could perform a tcpdump to see, if there is any kind of block by the firewall. 

LuCar Toni said:

The client itself gets the new certificate after some time. 

We've had this problem at least twice, once with this release and once when we had to re-register the firewall with Central (which causes a new certificate to be generated). Just to repeat, the problem for us was because the clients could not resolve DNS to connect to central to get the new certificate (it was blocked by our Heartbeat policy, No Heartbeat -> no connection to our DNS -> no connection to Central). So, in both those circumstances, the behaviour is expected, not a 'bug'. We have now removed the requirement for Heartbeat to reach our DNS so we don't have this issue in the future. It wasn't really adding much to our network security, especially as we allow non-Windows devices access to the DNS without a Heartbeat. In each case, once we resolved connection to the DNS, the clients updated their certificates quickly, within minutes.

The other posts I have seen about this are all related to this DNS issue so if you are sure your clients can resolve DNS then you appear to be suffering from something different and obviously LuCar is your best chance of resolving this. The only thing I would question is you say :

LHerzog said:

the clients can obviously reach central

but it isn't clear from your post how you reach that conclusion.

On a side issue:

LuCar Toni said:

I would recommend to always check the tcpdump on the client and follow the traces

Are there any good guides to using tcpdump on the XG? You often fire this off as a response to technical issues but I don't think you appreciate how difficult this is for users who may have never done this before or only do it once in a blue moon. I'm taking about a guide to capturing the data, not interpreting it.