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

XG v17: what's coming next

Hi Everyone, 

You're all overdue for an update on current and next steps, so I wanted to take some time to share a brief update. Since v16 launched last year, we've seen a huge increase in deployments worldwide! It's great to see that the feedback and effort you've provided has really been helpful to shape a successful v16 launch! Thank you to everyone who has used XG, and shared your feedback. It's been immensely valuable, and a big factor in the success thus far.

We've also launched v16.05 (Also called 16.5 sometimes, by lazy people like me..) which closed off the last high-level feature gap between XG and UTM9. I've seen some questions on why this release didn't contain more, so I'll take a moment to go over why we released only what we did.

Earlier in 2016, we launched Sophos Sandstorm on both UTM9 and Sophos Web Appliance, to MUCH greater success than we had initially expected. This resulted in far greater demand to launch it on XG, and left us with a tough choice. We could delay v16 significantly, or leave Sandstorm until v17, as originally planned. We believed that delaying v16 by even a few more months, would have caused significant problems for our existing XG partners, and waiting until v17 to launch Sandstorm was just too far out. With that in mind, we looked at what it would cost to deliver Sandstorm sooner. Our web and email teams were already going to begin working on Sandstorm as soon as they finished with v16, so if we limited the features in a release to just Sandstorm, a 16.05 release was possible, without causing a meaningful delay to v17. If we included more features, quality testing would take too long. With this in mind, we decided to launch a highly focused 16.05 release, dedicated to delivering Sophos Sandstorm by end of December. This would get 16 out when it was needed, and also get Sandstorm out close enough to the 16 launch, that we could reduce the problems caused by 16 not having it. So far, the decision has proven to be justified, as the launch of 16.05 has significantly accelerated the already fast growing v16. This sort of smaller feature release, on a fast timetable, isn't something we normally want to do - but in this case, the circumstances called for it.  

While our web and email teams were working on v16.05, the rest of our teams began working on v17, and we're marching towards a beta start around April or May. I can't go into too much detail on all of it just yet, but here are some if the highlights of what you can expect:

  • Troubleshooting and Visibility
    • Improved log viewer v2 - Unified view of all log sources, better filtering and searching, improved readability and display of log contents, unified view of live and historical logs
    • Improved Log Retention - Persistent storage of logs, retained for 1-2 weeks, to improve troubleshooting issues that are days old
    • More insightful log contents - firewall logs will now log meaningful reasons for "invalid" packet drops, web logs will include more details for troubleshooting
    • Rich Policy Test - Enter criteria to check,such as source, destination, user, etc.. and find out what firewall rule will allow or block it, what policies will be applied, and for web traffic, a full analysis of what rule within the web policy will be matched, and what action will be shown to the user
  • Firewall Rule Management - sliimer layout, custom grouping, cool design
  • IPsec VPN engine Improvements - IKEv2, Suite-B protocols, Reliability Upgrades
  • NAT Business rule improvements - Object based, more familiar to UTM9 users, more powerful
  • Synchronized Security - changing game for application control
  • Email - UX Improvements, Spam improvements, Outbound relay
  • Web - streaming improvements, faster content filtering
  • Zero-touch firewall deployments (not strictly part of v17, but part of a parallel project)
  • Licensing and Registration- more usable, less mandatory

This forum has a heavy hand in what shapes our roadmap, but it isn't the only source. For example I and other PMs have frequent calls with customers and partners, and even competitor's customers and partners. Usability study participants, Sophos support, and ideas.sophos.com, also contribute valuable feedback. Quite often these sources are at odds with the community feedback. It rarely differs in whether a feature is desirable or not, but it often differs in importance, and we have to factor all of it into our planning. 

I mention this, because I know that after reading the above list, there will be immediate questions about "what about feature X?", or "Why not feature Y?". To that, I say:

  • If we're not doing it in v17, we're more than likely still planning it, but the order of priority might might be different than you prefer
  • Some of you will disagree with one feature being chosen over another, and perhaps even disagree very strongly. Just know that this doesn't mean we're ignoring your feedback. The majority of the features and focus of v17 are driven by requests coming from these forums. We're listening!
  • The above list isn't exhaustive, or detailed. What you're looking for might still be planned for v17, but I can't outline all the details just yet. Stay tuned for the start of beta.

Finally, I want to call out a group of features I know you're going to ask about. Renaming/disabling interfaces, and other objects. It's obviously important, and highly desired in the community. Some more enabling/disabling options may be added in v17, but not interfaces, and there won't be improvements in what you can rename just yet, either. I know it's a big annoyance for some of you not have those features, but we need to do it right. (Bring on your apple, copy/paste analogies.. :) ) I worked with the teams to see if we could come up with a plan that included at least interface enabling/disabling in v17, but it wasn't practical. There are hidden costs, that aren't obvious, and there are also other projects in the works, that will significantly reduce those costs. At the risk of being too much of a tease in this post, we have a plan to implements enable/disable, renaming, and many other ui usability niceties everywhere. It depends on completing a project that's been in the works for a while, that I can't discuss just yet. Rest assured, it's all coming, and you're going to like the results! Be patient, and stay tuned!

Best Regards,

Alan Toews

Sr. Product Manager, XG Firewall

 

 

 

One last tease.. 

     



This thread was automatically locked due to age.
  • Alan

    This is good news but also a little frustrating as I was told time and again by support that we had to have every specific subdomain to use url groups.

    I have been asking about this from support for at least a year and they seem to have no idea that it natively did wildcards.  This would have saved me hours and hours of work if support or the installers I have dealt with knew this.   I know have to rebuild all my web filtering and test this since we had to do a ton of workarounds based on what support told us.

     

    Thats brings up a another good point as I often get from support them saying I am not really up to date on XG I know UTM.   So we often struggle with support being able to help us and creates delays in getting help.


    Any update on whats going on with support side to get the team up to par on the XG to better support users?

  • Brett, I'm sorry for your frustration. This is actually something that's quite well documented within the product. When editing a URL group list, you'll see the following text displayed by the entry screen:

    "The URL Group will match any requests for these domains or their subdomains."

    BrettMcNerney said:

    Any update on whats going on with support side to get the team up to par on the XG to better support users?

    Our support teams have been receiving a great deal of network and XG specific training, and we've been hiring support engineers with very strong networking backgrounds over the past months, so you should already be seeing significant improvements. We're certainly seeing it on our metrics, and hearing increasingly positive feedback from partners and customers. 

    Ultimately, support is always challenged when we grow rapidly - which we've been doing a lot the last few years. we're very focused right now, on making sure support is able to grow ahead of the company growth, and on making sure that the products we sell are better tuned to reduce support volume. For example, one of the most common support calls, is on how to bridge on-box wireless, to the local network. This is something we know wasn't a great setup experience, but getting the feedback from support helps us to prioritize it properly. As a result, you'll see some important fixes coming to XG very shortly, to solve this.

     

    Cheers,

    -AT

  • ,

    thanks for updating this thread. I really hope that soon you organize a Webinar where you show to us what we are going to have next August.

    After 18 months XG is still poor on basic features. Few weeks ago we discovered that Anti-port scan is not even available. Make sure that users can have basic feature because and I think that something completly should change. Having basic feature is requiring too much time and this is not a "good signal" from XG implentation.

    Change VPN Port, disabling interfaces, Anti-port scan, MTA improvements. Also make sure that even the UI is revisited. Customers are not ablet o find NAT. Now it is "hidden" under profiles and the "Show settings" on VPN and Log should disappear in order to have a smooth GUI.

    Lastly, CLI commands: make sure you use the same syntax all the time. Sometimes commands are inside SET, sometimes in SYSTEM. Make sure to perform a standard even on CLI workflow.

    Have a good working time!

  • Thank you for the update Alan!

    I can only agree with the feedback from Luk. He makes some good points with regards to the GUI and some functionality.

    I personally would like to add the following feedback:

    • Hardware Compliance List: Many folks who help with testing are using SG in their corporate environment and XG in a test or home environment. As such, it would be nice if some hardware beyond Intel would be supported (e.g. proper Realtek drivers like in the SG). This would take the frustration out of testing! Basically, it should be in alignment with SG hardware requirements.
    • Code optimization! At the moment, everything feels kind of slow (IPS, GUI, etc.) on reasonable hardware for the task (e.g. 4 Core Intel CPU with 6GB of RAM). Especially, RAM usage seems to be excessive at times!
    • We all want shiny new features, but we shouldn't loose track of features desired by corporate users at the same time (e.g.IPv6 DHCP-PD)

    While code optimization might be a bigger item, the other two could be implemented prior to v17. I mean adding some drivers could easily be part of a maintenance release and folks have been asking for DHCP-PD for quite some time now.

    Anyhow, I would like to finish on a positive note. I had the opportunity to take a look at some competitor products and I must say that most of them don't get close to the features and functionality offered by Sophos SG. I also feel strongly about the Sophos XG solution. While it isn't quite there yet in my opinion, I do like many of the new features. I also mostly like the revamped GUI and the change in the approach of how configuration is done. It just needs a little bit more work!

    So, please keep up the good work and surprise us with a great v17 later on this year!

  • FormerMember
    0 FormerMember in reply to JensStraten

    Thank you for the Update, but I agree to Luk too.

     

    I think the following very important Features are missing:

    I'm very happy with your new GUI! It is very easy to operate with it!

    If you add the Features that I described above, XG would be the best soloution!

  • it's good to see that XG is advancing, but i have to strongly disagree that XG and UTM have feature-parity.

    Xg is still nowhere near production ready, maybe for something small like 5 or 10 users in a vacuum is doable, but for anything else it's a nightmare and if you have an UTM already onsite the customer will throw that XG box at your head and burn it after they try to use it only to hit a wall of problems.

    a TON of important stuff is still missing from XG and a lot of others are done in really strange ways on the back and require some arcane workarounds.

    some examples:

    • there's no network monitor: i have NO way of knowing the traffic going through each interface in realtime, there's s single "bw monitor" graph for the entire system, it's nuts...
      let alone shaping/blocking in realtime like in UTM network monitor.
      For a mom and pop shop with a single dsl this maybe good, but on every customer i have from 2 to 5 ISPs all with different speeds and all need close monitoring
    • There's no BW declaration for QoS per interface: there is simply no way to tell the system what's the BW for any interface for auto-aos balancing, you have to bidn and make rules by hand and remember to not exceed the uplink/downlink of whatever you bound the rules to.
    • No object reuse: back to the 1990s/chinese cheap routers that when you do a DNAT you need to enter the port number by hand, even when on FW rules you have a list of objects, insane... simply insane. A minor annoyance is that the included service/group definitions are a fraction of what's in UTM and you end up having to waste time configuring stuff that should already had been defined out of the box(and then having to go back to the service definitions and noting port/protocol when you do a DNAT, good luck in a year+ when you see those rules and wonder what the heck is that port number for in that rule with 20 forwards...)
    • In UTM you never touched the console except when someone went south very hard or support needed you to run something.
      In XG for every one action you do in the GUI you need to do 3 arcane workarounds in the console because the defaults are useless and do things wrong(like implementing a cover NAT for site-to-site vpn, who even thought that was a good idea?!?!, or when we had to hack a lot with the https scanning fiasco, or even trying to use stas/ad auth) or simply it's not exposed in the GUI for who-knows-what reason(which again might be acceptable for a home router, not for a enterprise border device).
    • No upgrade/update scheduling: something as simple as updating the XG is done terrible, in UTM the system checks AND downloads the updates for you then you can SCHEDULE the installation(specially useful if you have several), in XG you have to login... go to check update, and then you need to click a button to download it, after that you have to press INSTALL, all done interactively, an absolute mess of usability and management overhead you have to make your admins log from their home to download and upgrade the XGs at off hours. How come this even passed the smallest QA?

    Until XG has a 1:1 feature and USABILITY parity with UTM, then it's not production ready and i'll keep using UTM forward to v9.x and 10(i hope it's still developed).

    I had to install an XG in a customer remote office with a UTM in place because for pricing and delivery constraints we had to go with the smallest cyberoam that can only be converted to XG, it's been months and i'm taking flak nonstop because the thing works horribly, all problems...

    a pet peeve of mine is that when you buy a XG appliance and you change it to UTM they call it "downgrade", downgrade my ****s it's clearly an UPGRADE.

     

    edit: added point of updates

  • If I could have thrown all my boxes at my reseller without getting in trouble I would have!

  • I guess I've just been incredibly lucky, my XG works great and has since I wiped out the "wizard" configuration and configured it manually.  I do agree that it is in need of some features asap (no DHCPv6-PD in 2017?  Seriously?) but overall I think its pretty good already and sounds like its about to get a lot better.  Call me an optimist.

  • Hey Biil,

    what features of the XG do you use?

  • I'm in the same boat as Bill.  I've been extremely fortunate and we have been deploying since v15.

    I'm optimistic in the current team and I think we can all see their efforts to close out bugs with the monthly releases.  Here are some features we use, with success (few hiccups here/there):

    1. Basics like web filter, app filter, firewall, IPS, IPsec tunnels, etc.

    2. SSO via STAS/SATC (mixed results, especially with RDP and local logoff issue).

    3. RED tunnels to other UTM/XG devices.

    4. Synchronized Security (biggest reason we sell and implement XG).

    5. Sandstorm.

    6. WAF for Exchange and basic web servers.

    7. SFM for centralized management, change tracking, logging, etc.

     

    We do not use them for:

    1. Mail filtering.

    2. Wireless.

    3. Advanced routing.

     

    The above isn't exhaustive of everything we use/don't use, just an idea on what we are deploying successfully.

    Looking forward to more positive changes with v17 and v18.

    Cheers,
    John