Sophos Firewall: v18.5 MR2: Feedback and experiences

The good bad and the ugly

1/. the reports are now showing local time - good

2/. VPN lighter is back - bad

3/. ultra surf proxy is back - bad

4/. CPU usage is still higher then previous version even after a restart - not so good

5/. DHCP no improvements in the display of IPv6 addresses - ugly

6/. seems to suffer poor communication with CM - indicates IP4 connection failures in email messages but not IPv6 failures - bad. I would expect if the IP4 link is down so would the IPv6 be down.

7/. GUI slow after restart but then improves after about 5 minutes - good

8/. no FQDN selectable in IPv6 destination networks - bad

Ian

On the subject of CPUs, how many are running on Atom based machines, I'm looking at pressing an e3845 atom back into service, but I'm also looking at some of the C3000 atom options.

I previously ran it on a Dell PowerEdge R220 with an  Intel Xeon E3-1240L, but trying to reduce power consumption of kit.  I've got a Dell T320 running TrueNas, which will be pretty juicy.

I might have found something. I noticed openssl repeatedly in top on the virtualized XG that's showing increased CPU. So I went on and investigated. It appears that every 20 seconds openssl is trying to generate something:

while : ; do pgrep -lf openssl ; sleep 0.5; done

4956 openssl genrsa -aes128 -out /tmp/hbtrust.901Y38Gn_m/server.key -F4 -rand /dev/urandom -passout pass:ozaywt5Xxlu1F8_d5X 4096
4956 openssl genrsa -aes128 -out /tmp/hbtrust.901Y38Gn_m/server.key -F4 -rand /dev/urandom -passout pass:ozaywt5Xxlu1F8_d5X 4096
4956 openssl genrsa -aes128 -out /tmp/hbtrust.901Y38Gn_m/server.key -F4 -rand /dev/urandom -passout pass:ozaywt5Xxlu1F8_d5X 4096
4956 openssl genrsa -aes128 -out /tmp/hbtrust.901Y38Gn_m/server.key -F4 -rand /dev/urandom -passout pass:ozaywt5Xxlu1F8_d5X 4096
4956 openssl genrsa -aes128 -out /tmp/hbtrust.901Y38Gn_m/server.key -F4 -rand /dev/urandom -passout pass:ozaywt5Xxlu1F8_d5X 4096
~20 seconds
5130 openssl genrsa -aes128 -out /tmp/hbtrust.rOckAvqxgb/server.key -F4 -rand /dev/urandom -passout pass:eq4Kntm2LePbMIItgw 4096
...
5130 openssl genrsa -aes128 -out /tmp/hbtrust.rOckAvqxgb/server.key -F4 -rand /dev/urandom -passout pass:eq4Kntm2LePbMIItgw 4096
~20 seconds
5347 openssl genrsa -aes128 -out /tmp/hbtrust.tZT4TgMZWx/server.key -F4 -rand /dev/urandom -passout pass:9jvJJ83hprZ4KlQQAzyc4Q 4096
...
5347 openssl genrsa -aes128 -out /tmp/hbtrust.tZT4TgMZWx/server.key -F4 -rand /dev/urandom -passout pass:9jvJJ83hprZ4KlQQAzyc4Q 4096
~20 seconds
5607 openssl genrsa -aes128 -out /tmp/hbtrust.U5TMYmug4p/server.key -F4 -rand /dev/urandom -passout pass:Dy4tYYloBN_W3A3h8SWZ 4096
...
5607 openssl genrsa -aes128 -out /tmp/hbtrust.U5TMYmug4p/server.key -F4 -rand /dev/urandom -passout pass:Dy4tYYloBN_W3A3h8SWZ 4096

  PID  PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 6873  20   0  5960 2252 2044 R 99.4  0.1   0:02.01 openssl

You get the pattern.

I'm not seeing that on HW Appliances running 18.5.2.

I see the same thing on my VM. Hardware version like you mentioned does not have this issue.

Running the Mac SpeedTest app (to a Cloudflare server, if that matters) fails during the upload phase. Sophos Application log indicates it thinks this is Torrent Clients P2P traffic. I can see how they might look alike, but..

I think it's a combination of factors: sometimes Application Control is unhappy, sometimes it might be Intercept X, sometimes it might've been due to macOS Monterey (the SpeedTest app had a recent update), and sometimes it's Little Snitch stopping the app from contacting google analytics. Just throwing it out there that at least in two of the tests I got 4-5 errors logged in the firewall's Applications log. (This is running the latest MR2.)

What is "VPN lighter"? Based on #3, I'm guessing these two are misclassified traffic by Applications Control.

It's very much appreciated that Cloudflare DDNS support was added in 18.5 MR2 and not to be too critical here but it uses the global API key for authentication:

Cloudflare deprecated using global keys for its API for some good security reasons. Switching over to using API tokens would be beneficial in a future release.

After the update to 18.5 MR2 and a restart, all interfaces were down. No lights! XGs reinstalled with ISO "HW-18.5.1_MR-1-326.iso". Update to 18.5 MR2 and XGs set up again, everything seemed to work, even after some reboots. After about 20 hours, the XGs no longer works with the same error (all interfaces are down, no lights)!

Can you create a Support Case to keep the supported process rolling? Thanks for the Feedback! 

 I have opened a support ticket with my distributor