XG / XGS ongoing issues list

That's all fine and good. Yet, here is a forum with complaints from a real customer. And the replies are pushback. Not, let's look into that. 

The marketing I get is, move to XGS, it's better. Then I do that in one spot and I say... "this is not better". This is broken. And the response is not, we should look at that. It's pushback.

Fair marketing should be "it's better, but it's gonna hurt". If keeping existing SG features is not on the roadmap.

Its better, if you are looking for a security upgrade. SFOS is in all aspect more secure. I am wondering, if this is not your focus? Do you want to increase your IT Security? 

And i cannot give you anything else, as i am a sales engineer, not a product manager. So if you want to get a respond by the PM team, you should get in touch with your Sophos peers to discuss this further. 

I am giving here simple answers on the current state of the implementation and what i would recommend to do. 

Issue #3 - you are talking from hearsay here. I can't confirm this at all for V18.5.x and V19.0.1 and we have several customers using XG/XGS

Not heresay... 

I admitted I don't have an example to test myself, and I have a credible resource who has many clients with XGS and they have had a bad go of it. So, I am looking for confirmation and feedback from the community if it's an issue, or that it's not. I'm just not looking to dive in, and arrive at a problem.  

All I can say from my own experience: XG/XGS is a different platform from SG-UTM. So test the functions you need step by step and try to achieve your goals. There is no 1:1 replacement.

Vishal, the issue is that the WAN link manager can detect the WAN service is down, but then does nothing about it to try and recover it.

We have seen this very issue with NBN services in Australia delivered via DHCP'd IP. The fault occurs when there is an outage where the XG does not see a physical interface down (as it would in some sense with PPP). The service comes back, but no traffic till a new DHCP request goes out, the WAN link manager knows the link is down, but nothing happens till the timeout.

On one hand the argument is you should have dual WAN, but that's not always going to be the case, and additionally your second WAN may be of a lower service as it's primarily a backup, it could be 4G/mobile data which also could be costly. So it really should do more to restore the service as fast as possible to return to both reduce costs, but also in many cases bring performance level back to normal thus reducing end user impact.

XG's in HA can also exacerbate the problem, as they will never see a physical interface go down in the normal sense, because there will often be something else in between to provide the WAN to both XG's. In many setups we have two XG's in HA, going into two switches (stacked or otherwise), so the WAN is delivered either as a VLAN to the XG, or a port on the switch, so they are in a sense abstracted away from the ISP's equipment and thus again never see a physical drop.

Now the other part of the problem is that we don't see this with other vendors. One client had both XG and Sonicwall, and when we saw the same outage knock all the XG's out (funnily enough were all on the same NBN POI so they had the same "exchange" so to speak and all saw the same fault where the fibre link didn't physically drop), the Sonicwalls recovered within minutes, the XG's needed a reboot or someone to go in and click save on the interface to issue a new DHCP. So if Sonicwall can manage to do this, why can't XG?

And to be honest using the statement around "oh well we follow the RFC" isn't really a good response, I've had that kind of mentality come from a few vendors and it's beyond frustrating when it's just not how the real world works. Or worse and sadly often the case, that while it is true they are within spec of an RFC, they could fix the problem by implementing the optional or extended parts of the spec. For example the way the Sonicwall seemed to get around it (at the time from what we saw anyway) was sending regular/early renews, which is not invalid based on what I can see in the RFC?

"A client MAY choose to renew or extend its lease prior to T1. The server may choose not to extend the lease (as a policy decision by the network administrator), but should return a DHCPACK message regardless."

https://www.rfc-editor.org/rfc/rfc2131

Though to be perfectly honest none of this stuff about the spec really matters, because the WAN link manager knows the service is down, so why not use that to trigger the WAN interface that is "down" to just do a release/renew? Just a tick box or something to enable it to trigger it? Do something to try and recover that link.

But there may be some light at the end of the tunnel, we have been chasing this with Sophos for some time now, and there is a feature request to try and resolve this under the following SFSW-I-1139. So I would suggest anyone seeing this DHCP issue, grab a list of the affected clients, XG serial numbers and chase your account manager, because as we were told "the best way for this FR to make noise is to align this up to as many customers as possible"

And finally, don't get me wrong about Sophos/XG firewalls, I like the XG product, and no firewall vendor is perfect, I've got gripes with all firewall vendors. But really do like the XG/XGS product, and use it daily at many different sites.

Th question that then follows is, what is the value of the WAN link manager?

Ian

I don't have a huge sample size but I've used the onboard mail relay a few times without a problem. I'd be interested in hearing what the actual problems are though.

Me too. I would be interested in real world experience.

We've used the relay functionality at just about every site, anywhere we have migrated to Office 365 and no longer have Exchange on premise. I've not really seen any issues with it, it seems to work fine as long as it's been configured correctly, often see people forget to change the HELO name it uses (defaults to "Sophos") and a few other quirks, but just seems to work.

It's funny but the exact thing that was mentioned on #3 about using it for multifunction's, is exactly why we use it, would have systems that wouldn't talk TLS properly and freak out if trying to relay via 365. Plus it has made diagnosing issues far simpler as we can jump on the XG and see the email transaction, whereas when scanners were talking directly to 365, you'd not always get data in the message tracking to identify what was going on.