Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 6 subscribers
  • Views 2543 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 Purposefully Designs bugs into their Firewalls: Episode2 – Email Alerts, Green Statuses, and Routes

Steve Klassen

I’m documenting my numerous issues with SOPHOS Firewalls so that others can be aware of what they are getting themselves into.

Episode 1

community.sophos.com/.../sophos-purposefully-designs-bugs-into-their-firewalls-episode-1---vpn-failover-and-wan-interfaces

 

Issue # 2 – Email Alerts, Green Statuses, and Routes

               

As an administrator, it’s impossible to check every system under our management multiple times a day. So it is very commonplace that systems have alerts that will let you know when something is amiss. Under the SG Firewall, the alerts were very robust, not so for XG.

  • For one example I was alerted when anyone signed into a firewall. Under the new XG Firewall, this is not an option.
  • On SG if an AP went offline for some reason the alert noted the name of the AP(if you named is) so you’d know right away which AP was offline. On XG, you can name the APs as well, however it only lists the serial number of the AP that went offline. So you now need to go check which AP has that serial number before you can go track it down.
  • Same goes for HA Appliances. You have a notification if one goes down and the other becomes primary, and instead of including the name of the device, it tells you (node1) and the serial number. So now you need to go track it down. It includes a whole host of other information you don’t need, and excludes the information you do need. It seems like Joe from shipping\receiving is the one that makes the design choices. And the sad part is they OWN a well-designed product they could steal good ideas from while they design the new OS.

 

Secondly…

                I had a strange routing issue. We have IPSEC VPN Tunnels, and each tunnel has 6 routes. If you go into the VPN connection details, there is a button you can click on and it will show you the routes and a green light beside each, indicating their status. Green means good, Red means bad.

 

                When this issue happened, one of the 6 routes was not working. This VPN had been functioning for 3 months flawlessly and then in the middle of the day, one route stopped working. I proved the behaviour it by confirming that our domain controllers could not be reached(which was also the complaint of staff). I checked the VPN route statuses and they were all green, including the route that was not working. I contacted SOPHOS immediately as I’ve had all sorts of strange issues happen with these firewalls and now I had a live case for them to see.

 

                The tech I spoke with confirmed that the firewall showed all was good (green statuses everywhere), and also confirmed that the route was definitely not working. I knew if I bounced the VPN tunnel the issue would go away, but I didn’t want to touch it as I wanted SOPHOS to see and diagnose the issue.

 

                The first thing the tech wanted to do was see the VPN config, however, when you have your VPNs configured in a failover, you have no way of seeing the VPN configs anymore. Joe from shipping\receiving(who is the Designer for these Firewalls), must have figured it wouldn’t be necessary. I’ve run into this issue multiple times already in 4 months, when I’ve called SOPHOS for support. SOPHOS Techs support want to double check settings and literally can’t without taking our VPN offline. I checked with SOPHOS design people on this, and they assured me it was “by design” and “working as intended”. SOPHOS tech support did not agree.

 

                Next the SOPHOS tech decided to open up a packet capture on the firewall. The second he enabled the packet capture, it caused the routing issue to start working again. Very strange.

 

                After that he grabbed all the logs, however, he was unable to determine the issue because the logs were not in debug mode. So I asked him to put all the logs in debug mode and he said that the firewall would cease to function if he did that. So unless the problem is repeated and recurring, you can’t diagnose it because the logs don’t capture the necessary data in non-debug mode. I’ve had this happen on multiple calls with SOPHOS, where lack of debug mode means “problem not solved, case closed”. I’ve also never experienced this issue with logs being insufficient with the SG Firewalls. Somehow, that logging could capture the necessary info, where XG logging cannot. I’m sure this is “as-designed” too.

 

                So I’m working on my clairvoyance degree now, so that I can ensure we enable debug mode before problems happen. This way we’ll hopefully be able to troubleshoot issues.



This thread was automatically locked due to age.
  • 0

    Very interesting read. Do you have any experience with the new XGS Firewall?

    We had the option to initially get the XG instead of the SG, thank god we went with the SG after reading about all the Problems the XG had already back then.

    Now we have to migrate from SG either way, so I wonder if the new XGS has all these Problems you are experiencing.

  • 0 in reply to MikR

    I've used an XG for about 5 years in one location with very simple needs. So I knew what I was getting into as far as the interface being far more unwieldy than It needs to be. The operating system is very bloated and on XG the performance was abysmal, so you dodged a bullet there. The interface worked, but it was a terribly slow experience.

                  The story above IS our experience with the XGS 2100 hardware we bought in February. The operating system (SFOS) is the same on XG and XGS albeit they release new versions as the years roll on. One major difference I was told on the XGS, is that there is additional processing to handle the clunky user interface, and the performance is certainly is better than on XG. That said, we have 18 firewalls and we've been rolling them out over the last 4-5 months. These firewalls do have a lot of features, and can do a lot of things, however the 3 key overall issues I have are:

    1) On the new XGS(SFOS) system, SOPHOS has designed the product in a way that will likely not give you the flexibility you want, and will force you to do things their way, rather than your way. They'll remove features you are using for the "greater good" and force you off of them. This has already happened once in the 4 months  we've been on XGS.

    2) You will certainly run into issues, bugs, design flaws, etc... If you place service calls, often they won't be able to determine the cause due to the logging level not being set to DEBUG MODE. And you can't leave logging on DEBUG MODE as it will negatively impact your firewall. So unless your issue is repeatable and occurs regularly, you won't have much success in solving these issues. Also, for the issues that SOPHOS can diagnose, you will also often get the answer of "we designed it that way" and that's the end of the diagnosis. Even if it's causing you issues, if it was designed that way, then too bad. It's a good "get out of jail free" card for them.

    3) If you take to the forums to express issues you have with a feature that your Firewall offers, be ready for LuCar Tony to tell you all about how you are doing it wrong. He's a SOPHOS employee who I've had lots of interactions with. He'll say all kinds of wild and fun things. He's knowledgeable and he's dedicated to his company, but he's lost sight of the fact that he represents his business, and that you (and I) are the customer. Rather than assist with a legitimate complaint you have, he'll tell you not to do it that way, and to do it another way. And perhaps his way is better, or perhaps its just another option... but the point is that he won't help you with your problem... but only guide you to a different way of doing things that avoids the problem. Because SOPHOS seems to be avoiding solving customer issues by saying it was "designed that way", in an effort to make you do it their way. 

    We too had to migrate from SG, and this is the experience thus far.

  • 0 in reply to Steve Klassen

    We have to migrate as well, but at least we got too good of a deal to pass.

    Our Infrastructure is not as complex as yours, so the simplicity will probably save us from having many of these Issues.

    Hopefully Sophos will somehow react to your complaints and try to solve these issues, but I doubt it. Most of the time the best way to get someone's attention is by taking your business elsewhere. But in many cases, yours included, its not really viable to simply switch.

  • 0 in reply to MikR

    The question is: Do you want to stay in the old world or do you want to adapt newer technologies? In many ways: I will not interact with you anymore, as you are not intend to follow any kind of feedback i am giving (The entire Route based conversation). 
    By the Way: I am not a Product Manager nor developer - I cannot fix or change anything in the product. I did only give you an better way of handling your situation, but if you do not want to follow up on that - it is fine to me. 

    __________________________________________________________________________________________________________________

  • 0 in reply to MikR

    Yeah I'm hopeful as well. Hence why I'm not just giving up, and I'm trying to get attention on the forums. 

  • 0 in reply to LuCar Toni

    That's not my question. And that's fine, I wasn't specifically asking for your interaction.

Unfiltered HTML