Does any one know if XG is roughly at feature parity with the UTM yet?

Not sure this question makes total sense in a general way. You can have a general "feature parity" that fails spectacularly because of one noe-quite-there feature. For example, XG still does not have IPv6 PD, though if you have a static IPv6 for the XG it works fine. So there might be a sort of "parity" but if you have an ISP that gives you your IPv6 via PD, the XG won't work for you.

Similarly, the UTM has historically. had a more polished and user-friendly interface, but I've read about some things lately where it's apparently not superior. But then, does UI count or do you mean operational features (IPv6 PD, SD-WAN rules including QoS) or performance (XGS acceleration), or something else? There are probably some features of XG that would be worth putting up with downgrades in other areas from UTM... for some use cases.

Personally, I'm a happy XG user who never used UTM, and have only used XG since 18.0 or so, and it's had a fairly good development momentum now that working with the Fastpath acceleration (XGS hardware) is behind them. I'm sure the preparation for the new mechanism bottlenecked a lot of other feature work during the pre-18.5 era.

Thanks Wayne. We are a UTM customer that's been advised to move to XG/XGS instead of renewing our UTM license in 2023. So i'm wondering what features XG does not have that UTM does. So far I found that XG does not support forward proxy, which we are using, but that's probably not a show-stopper. Also logging seems to better in UTM, logs are kept until the disk fills up, but XG only seems to keep the logs for 24 hours.

Both points are not correct. 

SFOS supports logging for Logviewer and an external Log module. Logviewer is a database on the firewall - (from my perspective the better approach to live log on UTM). Logviewer saved data based on the available storage. But its not a Reporting tool. If you want reporting - SFOS saves reporting on the firewall itself and can do it in Central as well. In Central you can build your own reports. It is free for 7 Days log retention. 

Forward Proxy - SFOS does support a WAF, if you mean this by using a forward proxy. 

The logging in the free version of cm does not allow for email or export of the reports. You have to view and analyse all reports on line.

ian

Thanks LuCar. We don't need reporting, but we do need to see 7 days of logs.

Thanks Ian. I didn't know that. I am using the free test version, that's why I guess.

Logs or Report? What is the specific use case you want to address? 

With the default annual XG license, I get 30 days log retention on Sophos Central. (Currently there's a bug where my XGS87 stops logging to SC after 4-5 weeks, and Sophos is looking into it, but in theory I get 30 days.) And I think you can pay for more.

I switched from XG control of my AP to Sophos Central control of the AP and I think that's a better solution, so there are issues where maybe UTM is better (though maybe not) that are essentially moot, too. So specific features and use cases really make the difference at this point.

Reading about UTM, I've felt that XG is way behind UI-friendliness-wise, but I've read a few UTM release notes and it seems to be behind XG in several areas. So the specific features and use case matters a lot. XG is the future (hardware acceleration), and they keep moving UTM features to the XG over time.

With the default annual XG license, I get 30 days log retention on Sophos Central. (Currently there's a bug where my XGS87 stops logging to SC after 4-5 weeks, and Sophos is looking into it, but in theory I get 30 days.) And I think you can pay for more.

I switched from XG control of my AP to Sophos Central control of the AP and I think that's a better solution, so there are issues where maybe UTM is better (though maybe not) that are essentially moot, too. So specific features and use cases really make the difference at this point.

Reading about UTM, I've felt that XG is way behind UI-friendliness-wise, but I've read a few UTM release notes and it seems to be behind XG in several areas. So the specific features and use case matters a lot. XG is the future (hardware acceleration), and they keep moving UTM features to the XG over time.

One of the very things that keep me away from XG is the fact that the UI literally makes no fluid sense to me.  UTM is organized, XG is not.  What I believe to build in XG as a simple rule doesn't ever work.  It's not fluid, it feels clunky, and simple things like LetsEncrypt isn't even available - one of the most requested features of XG that still hasn't made it into the software.

It really ticks me off that we have no access to a migration tool after we were told one would be available, then it just went the way of partners/resellers only.  If I could see my configuration of UTM to XG, see how the rules are applied in XG, how everything carries over - I might actually support going to XG and take some people with me that need business class service over there for their needs.  I'm a visual learner, reading something doesn't always comprehend with me so visuals really make it simple.  Seeing how my config would lay out in XG would be a big help.

At any rate, glad to see XG is being updated often and hopefully more features are coming into it (and hopefully quickly).  I keep waiting for the EoL announcement for UTM, because it's pretty much maintenance mode now and I get the feeling it's just more of a pain in the ass for Sophos to develop.  I understand pushing the new shiny thing to get more people to use it, but if it's not user friendly, not feature-driven and those of us with complex setups with no migration tools available will go in kicking and screaming.

What is actually "not making sense" to you in SFOS? 
Because if take a closer look, most is similar or even "more logical" compared to UTM. 

My job for the last 4 years was to migrate customers from UTM to SFOS. And trust me - i saw a lot of UTM configurations. 

The problem is, UTM configs does not make sense in the cosmos of SFOS. That is the real blocker for most UTM customers. 
It starts with the firewall rule set. UTM only controls "the left over packets" with Firewall rules. Then UTM uses "automatic generated" + user generated rules within one rule set. SFOS could do much simpler rule sets with User based rules or zone based rules, if you want. You could copy/paste your UTM Rules, but most of them would look ugly and are inefficient. 

Example1:

Does not work in SFOS. SFOS does not have a "Internal(Network) object". SFOS works with Zones. So you would have one zone here: Called LAN. ANY could be better with Zone LAN. 

SFOS does this with User Based Rules in a better manner. (Groups?). 

Looking at other modules of UTM: 

Webfilter is a mess in UTM to be honest. It is complex way to tell what you want to filter over 3 different levels (Profile to policies to filteractions). This is something you hope create one time and never touch. SFOS does this within the filewall rule. You are setup it in a policy (something like the filteraction) and attach it to the firewall rule, you need it. 

Intrusion prevention is something on UTM like "Fire and forget". 

SFOS does this on the firewall level. You can break it down to one rule, if you want and attach it to each and every rule, if you want. 

NAT is something similar. Only downside, it does not offer a "create a firewall rule to match this NAT" (UTM: Automatic firewall rule). This is frustrating for administrators. But most Admins start to work with the NAT Helper in SFOS, which does the configuration after a guided process. 

SFOS offers a feature called Import/Export. You can create a XML file with configuration, which you can "reuse" a bunch of times. So partners start to generate different files for each scenario and simply upload the files one after another to the target appliance to setup everything. For example: You are going to create a VLAN for Wireless for your customer? Prepare one XML, which generate the VLAN Interface, the SSID, the Firewall Rules, the IPS, the Webfilter etc. You can reuse it all the time and save a lot of time. This kind of work is manually on UTM - all the time. 

I am still wondering, how SFOS can be "not logical" to users in the end. You have so many tools at hand to generate the rules. All the customers, i am migrating are actually happy to use the SFOS platform for different reasons. Sometimes they are missing stuff like drag and drop or other Quality of life features. But the UI is far away from "does not make sense". 

Probably because when I look at XG interface (which the dashboard is great) and create (what I believe) is a firewall rule that looks like it's simple to me, actually doesn't work at all because the same flow you would see in UTM isn't the same as XG.

But - I've been with it since Astaro v5 or v6.  It's something that I have grown accustomed to for the past 20+ years?  The XG interface, while it may seem logical to you, won't seem logical to others just because you think it does.  For me, the flow just doesn't work and building rules as an example isn't obvious.

Your implementations also have you as the hand-holder for clients, and I am sure that someone (if not you) has been showing them how to make it work.  I don't have that personal experience of having someone show it to me in the face, so to speak.  I have to literally take down my environment that works, implement something almost completely foreign to me and make it work all over again within a couple of hours' time.

You will wonder why things don't make sense, because you are not us.  You have been involved with it since day one.  You are asking people to be at the same level with little to no learning curve.  I don't mind learning but realize that others don't learn at your or my pace, and you have had a totally different experience and exposure to the product than the majority of us here.  Your XG user base on these forums for the most part came from using nothing like XG or UTM, so it's going to be a lot easier, frankly.  It's like teaching someone who has never shot a firearm before to shoot.  It is actually easier to learn that way because you have no bad habits to get rid of, you can teach them how you want them taught with nothing to compare it to, and they learn a skillset that they know nothing more about than what is in front of them.  Then compare them to some of us that have had 20 years in 'the field' who have been exposed to so much in our lifetime.  It's not the same.  And that is why you will always wonder why something 'isn't logical' to others.  Then you outlined exactly the issue:

LuCar Toni said:

The problem is, UTM configs does not make sense in the cosmos of SFOS. That is the real blocker for most UTM customers. 

I think folks who say its not logical might be referring to the hierarchical menu system and how things are grouped. For example, Traffic Shaping is broken into two menus (overall settings and rules) and appears under System Services when maybe Network or Routing might make more sense.I know there a couple of functions I never remember where they are.

But I think the recent addition of the Search function might make this more of a moot point.

Not sure how UTM handles, for example, Traffic Shaping. In SFOS it's complex because you can have Application-based shaping, Firewall-Rule-based shaping, User-based shaping, and another kind I can't remember, and there's one place to define these policies but four places to attach them. And the Traffic Shaping settings has bandwidth limitations that essentially don't work well so you want to set them to the max and then control everything via policies.

Also, as you say, SFOS has Zones and also other different ways of doing things that don't directly translate into UTM concepts.

Could you please elaborate on what "a firewall rule that looks like it's simple to me, actually doesn't work at all because [of the flow]"? Do you mean that the order of rules matters in SFOS but not UTM? Do you mean SFOS firewall rules operate after NAT and UTM operates before NAT? Or that SFOS firewall rules have more options (IPS, etc) attached to them that on the UTM operate independently of firewall rules?

I don't understand the "flow" part of things, though again I'm not doing fancy things with NAT and other features of SFOS that might change things before/after firewall rules. And I'd like to understand, both for myself and for the SFOS product itself (or at least what I advocate for in SFOS' roadmap).

(I"d also potentially push back a bit that perhaps the UTM does things strangely but you've warped your brain around it. I can say that I had no firewall experience before SFOS and I've never had a firewall rule not work at all. Though I spent quite a bit of time trying to get Traffic Shaping working and my changes were having no effect until I understood it's a two-step process.)

Lets recap some points here: 

I am not talking at all about what UTM/XG does in terms of functioning how it's supposed to function.  That's an obvious expectation.  I am speaking specifically in regard to the interface and creation of rules.  Frankly, I don't care how either firewall does the job - as long as it does so in the fashion it was created.

My complaint about XG isn't functionality.  It's simply ease of use, call it a learning curve if you wish.  The "flow" for me is NOT function, I guess you would call it an aesthetic or simplicity and how easy it is to use.  If I create a firewall rule and I think it works, i.e., opening a specific port, like UDP 1194 for a specific application.  I go into XG and use its interface to open that port, then test it, I found that what I was in was either not at all where I was supposed to open the port, or the port isn't open because of some other issue.  Well obviously, it must be me, right?  I am going to XG to what I believe is an obvious spot to create that rule, and yet I am nowhere near where I should be in XG.  If I have to hunt and peck an interface just to figure out where I need to go to set something up that simple of a task, that is not a good "flow".  That is not simplicity.

LuCar Toni said:

You can do the same kind of configuration, like you did on UTM, on SFOS as well, if you really want. And i am fine with that, if you want to "do the extra step and recreate everything as it was" but you do not have to. 

Why would I NOT want to?  That's exactly what I am looking for, not only to learn how XG shows it in the interface, but because my configurations actually work - and work very well for my environment.  Hell, I've spent enough time with this product of doing it over and over again, but now I have other things to spend my time on.  I don't want to rebuild my UTM every other version because things stop working for whatever reason pops up in the version (yes that was happening in early 9.7 releases). 

I am actually wondering: If you say, you want to open a Port like 1194, it should be 100% the same on UTM like SFOS. 

But as 1194 could be a potential OpenVPN application, SFOS is doing other stuff in the backend, which "could" cause issues in the past. Sophos did some work in the latest releases (talking about the last years) to tackle such behavior changes.

The problem is quite simple: As UTM is only a firewall, you have to look only at firewalling (conntrack/iptables) to allow something. SFOS is a next generation firewall with multi level of system in place. Most of them are disabled per default. But in the past, there were issues, which could interrup such traffic (generally speaking). But those are likely addressed by now. 

So you open a port like 1194 on SFOS: Go to the firewall rules, create a rule, Jobs done. That is how the system was and is design to work (beside the potential issues described above, which is not a configuration flow part, instead a "bug"). 

And i guarantee you, you do not want to rebuild your config 1:1 UTM to SFOS. Simply because there is no need to do this anymore. You can shrink and simplify alot. But as i mentioned. Feel free to copy paste everything. You will end up with a lot more objects, a lot more rules without the need of even generating them. 

But at this point, i can understand where you are coming from. And as i mentioned: You will likely not see any kind of migration tool for your setup, as there would be no way to implement such a tool (for your purpose).