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.
Parents
  • Will there finally be an accurate live bandwidth view to see which users \ IP hosts are using data ?  ie Mikrotik's 'torch' 

  • AndrewMillard said:

    Will there finally be an accurate live bandwidth view to see which users \ IP hosts are using data ?  ie Mikrotik's 'torch' 

    This is what is so frustrating about XG and I can imagine the prioritization that  has to do on which features need attention right away.

    For example: My old Asus Rt68U that I bought almost 3 years ago as a play toy for the gigabit connection I was getting can:

    1. Use any port for open VPN while XG still cannot.

    2. Has live bandwidth showing which appliance is using how much bandwidth and the total bandwidth being used. I can then control each of those devices right there from the live screen and use sfq, codel, or fq_codel by providing my own limits on either the clients or my total bandwidth. While XG has great granular QoS control, who is using what kind of bandwidth or assigning bandwidth to the interfaces in multi wan configurations is missing.

    So while some of us are asking for the basics that even a 150 dollar router has been providing since 2014, other users are asking about more business related stuff like ikev2, improved vlans, enhanced MTA etc. Plus sophos wants to add their own stuff on top to improve their return on investment. That's how we ended up with XG v16.

    Don't get me wrong, an arm processor based router is not a substitute for a business class intel UTM, but its interesting to see the limits being pushed. Also, to be fair, the MR releases have been coming at a steady pace and the base system has been improving greatly. This gives me hope that sophos is finally getting serious about XG as a contender and not just another firewall with hype.

    While v17 won't satisfy everyone, I am hoping that all the quirks have been fixed by now and we will have a stable, fast, and dependable firewall that is easy to work with and easy to troubleshoot. How successful is sophos in delivering a quality release? We'll all find out soon enough...

    Regards 

  • Hello Alan,

    Do you mean the first week in September (two weeks from today) or the first full week in September, from this day in three weeks?

    ;-) 

    Regards

    alda

     

    P.S. I saw your mistake with October and I almost got a heart attack ... ;-) ;-) ;-)

  • FormerMember
    0 FormerMember in reply to alda

    Hi Alan,

    Thank you for the new information!

    How long would the beta take?

    When would be v17 finally released?

    Regards Meghan

  • Hello Meghan,

     is ( was ) planed to the end of September or early in October.

     alda

  • I'm looking forward to loading the v17 beta up on my XG Home box!

  • FormerMember
    0 FormerMember in reply to alda

    Hello alda,

     

    this is good News!

     

    Regards Meghan

  • Thank you for taking the time to give us another update and for addressing some of our questions and concerns.

    Like I said before, I mostly like XG over UTM, but I also see some features missing that prevent my company from using it in production. That said, I agree with you that everybody has different needs. I also don't think that you need to proof yourself. I believe most of us are here to make a good product even better.

    Anyhow, I am looking forward to take a look at v17 in September.

  • If this helps alleviate your concerns, I'm running XG as a VM on a Dell R230 with fiber Gb to my home. The VM is limited to the Home limitations re: cores and memory. I have 78 devices at home + however many guests show up when the family comes over. I have 28 rules setup in Firewall. I can easily saturate my full Gb connection during speed tests or lengthy downloads/uploads and the CPU never breaks beyond 20%. Even at full bore downloading, and with all the rules and connected devices, the RAM hovers around 50% - 55% utilization. I was never able to approach this when running as a VM with UTM9 so this has been quite the step up in terms of raw power. It's true that some features are missing but I've managed without them and found alternatives that work more effectively for things like internally hosted web servers (hello Nginx) and remote access via web (Guacamole is perfect here). All-in-all, I'm very happy with my move to XG and am only looking forward to the new features and developments in v17.

  • This was released on partner portal today:

    When is v17 Coming?
    Beta start: Week of September 4 (likely Wednesday, September 6)
    GA: Mid-October

    While things are subject to change, a public beta build for v17 is currently scheduled for announcement during the week of September 4. The beta is expected to last four to six weeks, and thus we are expecting the final build of v17 to be available to everyone in mid-October.

    What’s new in XG v17?
    XG Firewall v17 includes a new game-changing Synchronized Security feature as well as an impressive set of top-requested features.

    The problem with app control today:
    One of the problems with all next-gen firewalls today is that they rely on signatures for identifying application traffic on the network, and unfortunately, the dirty little secret of the firewall industry is that signatures are largely ineffective, particularly against custom apps, evasive apps, or apps that rely on generic web connections to communicate. As a result, the promise of next-gen firewalls to identify and control application traffic is largely unrealized… until now.

    The solution: Synchronized App Control:
    Thanks to Synchronized Security, XG Firewall can take advantage of its information sharing connection with Sophos endpoints to instantly identify applications generating unknown traffic. This is a game changer because it will suddenly make all other next-gen firewall app controls obsolete.

    In addition, v17 includes a ton of other new features that customers and partners have requested that make XG Firewall a lot easier to set up and manage on a daily basis. Features like more powerful firewall rule management, particularly helpful managing large rule sets. 

    Some of the top requested features in v17:

    • Improved logging and troubleshooting tools
    • Web Keyword Monitoring for child safety in education (a requirement in the UK)
    • IKEv2 support and VPN setup enhancements
    • Object-based business rules (e.g. you can now set TCP and UDP port-forwarding in a single rule)
    • IPS and app policy UI improvements to support smart lists
    • Wildcard FQDN support
    • And much more

    What features are not yet in v17?
    We will be publishing a detailed feature gap comparison between XG, SG, and CR before launch, but here’s a couple of often-asked-about features that are not yet in v17 but are coming soon:

    • Configurable SSL VPN port – coming in the next 17.x release
    • Additional email feature gaps like per-user block/allow lists – coming in a follow on 17.x release
    • SNMPv3 – coming as part of v18

    Of course, there are also all the great innovations that are coming next year in Project Nemo such as IoT discovery, device provisioning, endpoint stonewalling, superior SSL inspection and hardware accelerated performance.

    What version of Endpoint is required for Synchronized App Control?
    At the start, any version of Intercept X v2 starting from Early Access Program 0 (EAP0) and onwards will support Synchronized App Control with XG Firewall v17, which means customers and partners will be able to test this fantastic new feature as soon as the beta build for v17 becomes available.

    Synchronized App Control will also work with Central Endpoint Advanced (Windows and Mac), although it may not be supported by the start of the v17 Beta. We will provide additional details on the specifics of CEA support in future updates.

     

    What about SG to XG migration tools?
    Enabling our vast SG customer base to migrate to XG is now a top priority and the product team is working on a solution to enable partners and customers to do some portion of the migration automatically. The focus will be on automating the most time-intensive tasks like transferring objects. We will have more to say about this shortly, so please stay tuned for more information in the days and weeks ahead. Your continued patience is very much appreciated.

  • Thank you for the detailed release information to the forum.

    I note there is still no native IPv6 external interfaces, also no IPv6 tunnels eg HE.

    No DNS or NTP proxy.

    Ian

  • Hi Ian, you mention you're looking for a few features, mostly IPv6 related:

    • no native IPv6 external interfaces

     IPv6-only interfaces are fully supported on XG today, even for WAN connections. 

    • no IPv6 tunnels eg HE.

    There isn't yet authenticated tunnel broker support, but we support 6in4, 6to4, 6rd, and 4in6 tunnels, and I have HE tunnels on my firewalls today. 

    • No DNS proxy

    XG has a DNS proxy, and offers DNS static host entries, much like UTM9 does. 

    • No NTP proxy

    Correct. This is on the backlog, and we are debating when to add it. Not much demand for it yet, though.  

    There are IPv6 features we don't have. Most notably, DHCP-PD, but we are fully invested in IPv6 in XG. v17 is already "IPv6 Ready" certified (https://www.ipv6ready.org/db/index.php/public/logo/02-C-001622/)

Reply
  • Hi Ian, you mention you're looking for a few features, mostly IPv6 related:

    • no native IPv6 external interfaces

     IPv6-only interfaces are fully supported on XG today, even for WAN connections. 

    • no IPv6 tunnels eg HE.

    There isn't yet authenticated tunnel broker support, but we support 6in4, 6to4, 6rd, and 4in6 tunnels, and I have HE tunnels on my firewalls today. 

    • No DNS proxy

    XG has a DNS proxy, and offers DNS static host entries, much like UTM9 does. 

    • No NTP proxy

    Correct. This is on the backlog, and we are debating when to add it. Not much demand for it yet, though.  

    There are IPv6 features we don't have. Most notably, DHCP-PD, but we are fully invested in IPv6 in XG. v17 is already "IPv6 Ready" certified (https://www.ipv6ready.org/db/index.php/public/logo/02-C-001622/)

Children
  • AlanT said:

     

    There are IPv6 features we don't have. Most notably, DHCP-PD, but we are fully invested in IPv6 in XG. v17 is already "IPv6 Ready" certified (https://www.ipv6ready.org/db/index.php/public/logo/02-C-001622/)

     

    I would just like to add that I hope DHCP-PD gets some priority because this is how most if not all major US cable operators are doling out IPv6 addresses to customer CPE. 

  • As previously noted, at this point I am not nit picking on feature comparison between XG and UTM. As  noted, the performance of XG is clearly better than UTM. Even starting at v15, network performance with snort (Intursion Protection) enabled, XG impressed me compared to UTM. All the fancy features become secondary if your firewall chokes on the available bandwidth.

    I am also feeling optimistic with the pace of MR releases where we don't have to worry about waiting for minor functionality improvements till the next major release of the OS. Looking forward to v17, and if the performance and troubleshooting/logging are top notch, the stuff that is available is ALL WORKING as advertised, then Sophos should indeed be applauded for their efforts.

    Regards.

  • Bill Roland said:

    I would just like to add that I hope DHCP-PD gets some priority because this is how most if not all major US cable operators are doling out IPv6 addresses to customer CPE. 

     

    Understood, though it shouldn't stop you from connecting to such an ISP today (DHCPv6 is supported on XG) but you would have to NAT your local clients, to come from the firewall's IP. 

    DHCP-PD is the top priority IPv6 feature on the XG backlog. 

  • AlanT said:
     
    Bill Roland

    I would just like to add that I hope DHCP-PD gets some priority because this is how most if not all major US cable operators are doling out IPv6 addresses to customer CPE. 

     

     

    Understood, though it shouldn't stop you from connecting to such an ISP today (DHCPv6 is supported on XG) but you would have to NAT your local clients, to come from the firewall's IP. 

    DHCP-PD is the top priority IPv6 feature on the XG backlog. 

     

    Thanks Alan.  Really looking forward to v17, I believe this will really be XG's coming of age.

  • can you spend here some words about the project "Nemo"?

    It seems that you are changing again so we should except a new XG version with new core, cli and kernel and not cyberoam-based OS?

    Community will appreciate it.

    Thanks

  • lferrara said:

    can you spend here some words about the project "Nemo"?

    Nemo is just a code name for part of what we're working on for v18. I plan to talk more about roadmap as we get closer to the end of the v17 beta. While there are some very cool plans underway for v18, It's too soon to go into any detail for it. To answer your specific questions, there will be some notable improvements to the underlying system, but that's not really what's interesting in v18. Those aren't product features. Architecture is the framework we build features on top of, and not features in themselves. We will move to a newer kernel, and base it off of a more mainstream distro, so that we can spend more time working on features, than on kernel maintenance. By itself, this won't result in any significant changes to the firewall. 

    The CLI today is Busybox, which is a great choice for security hardening. We may keep that, or we may switch to a regular BASH shell. Regardless, you don't see Busybox, until you leave the default XG login shell, which may get some work done, but isn't going away. Either way, we will make some improvements here.  Also, we've made a few small improvements to the advanced shell in v17, such as more tools, and scp support. 

    Those are really the boring bits of Nemo anyway. Nemo is really about the next generation of our fast-path packet optimization. We do some interesting things in XG already, but technology evolves, and there's a lot more we can do. Nemo looks to take it up a notch. Even still, that's more of a datasheet improvement, than a feature. Picasso is another important codename for v18, and is where the more visible architecture changes are. I've been hinting about that for a year or more, both here, and on the feature forum. That's where we get to remove the limitations you don't like today in XG, like not being able to rename many objects (or name some at all), short name limits, more universal enable/disable support (SMALL improvement to this in v17 already), and some UI and config handling architecture improvements, that let our engineers work more effectively. 

  • Thanks Alan. Personally I still do not like the XG at 100% (70% maybe) because there are some limitations that come from the base. I am sure you learned a lot from community, partners and customers about v15 and v16.

    If you will improve the base and move what you have done until now you will succeed.

    XG at the moment is still cyberoam like (you changed a lot but the os is the same). You have added Sophos features but I am sure you know how to improve and make the XG a better product. With the feature sets XG and UTM you have, XG seems a Ferrari that is running with small wheels and reduced engine.

    We should see the real power into v18+.

    Again, thanks for your time and reply.

    Now we are ready to criticize v17 and improve it.

  • Hi AlanT,

    Thank you for taking the time to answer my post.

    I have  HE tunnel, so bno IPv6 on the external interface. If you use a IPv6 router on your link then you get IPv6 on the external interface, but not native using PPPoE.

    I will try the XG DNS static function again and see what I was doing wrong with the configuration, I suspect it has to do with using DHCP and clientless devices.

    Ian

    Update:- I found  my new Telstra adsl2+ connection does native IPv6 over DHCP. This is good, I have an IPv6 on the external interface, but there is nowhere that I can see that shows me the assigned /56 for internal use. The other issue I hope that is being addressed is having to create a dummy network both 4 and 6 just to get addresses assigned to the vlans.

    I can get the /56 address range I have been assigned from the UTM, but that is not a good way.

    More updates :- I am going to kill the UTM and build another XG so I can test the IPv6 without upsetting the wife and her facebook activities.

  • AlanT said:
     
    Bill Roland

    I would just like to add that I hope DHCP-PD gets some priority because this is how most if not all major US cable operators are doling out IPv6 addresses to customer CPE. 

     

     

    Understood, though it shouldn't stop you from connecting to such an ISP today (DHCPv6 is supported on XG) but you would have to NAT your local clients, to come from the firewall's IP. 

    DHCP-PD is the top priority IPv6 feature on the XG backlog. 

     

    Is there a document or something that describes how to do this?  How do the clients behind the XG get the IPv6 addresses?

  • I don't think there is a kb on it, but it would really just be exactly the same type of setup that you might do with IPv4, and using a private IP range internally. You can have XG's DHCP give out IPv6 addresses to your clients, and you would enable NAT on your ipv6 firewall rules, to masquerade all of your clients behind the single IPv6 IP that your firewall received.