First impression and feedback

Hi All,

I migrated my home box from MR7 to v17 and all good.

In my case, the IPS did not start automatically after the reboot.

The other thing is the UI is faster than v16 but the Network menu is very slow compared to the others. I have only 2 NICs and 2 VLAN.

Last thing, where is the policy test?

Parents
  • Hi All,

    in my personal opinion i will change:

    - NAT and WAF Rules on different pages. Firewall ACL is another security concept

    - on Dashboard no Health status about Power redundancy

    - on Dashboard no Health status about disk, or mirror disk. Only one way to discover problems is to go on DataCenter room and listen to the alarm...

    - on Dashboard on Web Hits, we would see the number of HTTPS connections and HTTP

    - We need a full log export, in case on Deep analysis on Forensic analysis. Reports are goods for Executive and for POC but you partner need to be able to answer who did what,when, wich protocol and wich port where used.

    - IPS Engine/Policy. If you need to exclude a single signatures only for a restricted number of users/pc you need to create two rules and play with priority: ok, but if you are on middle market customer how many rule you need to do to secure the customer? This is the same for Application policy

    - About metrics, decide to Use Kbit (kb)or KByte (KB), but with the right Sintax.....If you play whit BWM too many misunderstanding on the GUI and Documentation

    - Help us with O365 creating an Hidden Feed RSS to automate the download and the population of O365 IP/FQDN service to exclude from Proxy. Too many errors and problems about it.

     

    Thanks

  • I have always complained about the static gui. It shows very limited information and most of it is not important as a snapshot. Also completely agree with kilobit and kilobyte problem. It is really not that difficult... ALL live traffic including QoS rules should be in kilobit/mbit since we get the traffic from our ISP in kilobits/megabits and our network cards are also in megabits/gigabits etc. However the aggreagate traffic, like how much traffic did TOM use or the total amount of traffic should always be in kilobytes/megabytes etc. Maybe v18...

     

    Edit: On a side note, I have a different bug report about the firewall passing all traffic as soon as it is connected to the network. Did you guys know about this behavior? It has been there since v16[:#] https://community.sophos.com/products/xg-firewall/sophos-xg-beta-programs/sfos-v170-beta/f/sfos-v170-beta-issues-bugs/96108/bug-firewall-starts-passing-all-traffic-before-running-the-wizard 

  • Unknown said:
    Something that really throws me is that of the top 15 ideas, all are under consideration or planned with no targeted release at all or under consideration with only 2 actually having a targeted release version and even then it's ambiguous.

    Hi Emile, 

    The ideas site is only one source of feedback, and isn't strictly taken as the order of priority. We do far more research into features, before deciding what goes into it. Also, some issues being requested there, are costly in ways that make them only possible in future releases. What went into v17 is improvements to the areas that have caused the biggest pain for users thus far on XG - with the single exception of many of the planned logging improvements. (Coming now in beta 3!)

     

    Unknown said:
    I'm struggling to find the Sales reasons to create a Wizard for an Enterprise system. You don't see Cisco, Fortinet and Palo Alto focus on a first time set up Wizard so why are Sophos? That's just a single example.

    Our efforts around MRs were driven by feedback from partners, our sales teams, and from support. While XG sales exploded, so did quality concerns. We worked through every support case and licensing issue, and looked at not just the bugs being reported, but the reasons people were contacting support. The outcome of all of this, was that we needed to fix the registration process (not a surprise) and also the initial setup experience. We also had the opportunity to improve security, by removing the notion of a default password - at least for the web ui. 

     

    Unknown said:
    So my issue is that it has been pointed out there has been 6-9 months development time that is split over ~150 engineers and the only primary driver since v16.5 is bug fixing. But features are what prevent stagnation and what show to Gartner and the Partners that there is a strong focus on the product.

    Yes, we need to keep innovating, and improving the capabilities of the firewall. v17 is an important milestone in that regard. While there are not so many huge features in it, what is there is carefully chosen. We are also now working on some epic improvements for the future, which you and I have discussed, but what we have not yet discussed, is the roadmap between v17 and v18. I will begin discussing that, as we get to the end of the beta. We do have plans for more v17 features in several smaller subsequent v17 feature releases starting Q1 next year, though. 

  • I hope that you will change the XG project completely by going back to quality and not quantity. XG OS is cyberoam-based and still planty of issue, mess on it. With the right code, you can import features on XG easily and add new one, but with this OS you are banging you head against a wall.

    I hope that in v18 we will see almost the same GUI but with a new OS. Customers are already moving to other vendor, even if you numbers are good (because Sales made a great job on convincing people) but once the license will expire, customers will move to something else.

    I know already other people over the world (thanks to community) that are moving away and I agree with them.

    I know you will never admit that XG OS at the moment is a flop (in terms of basic features) but this is what we see at the moment. In v18 you should at least add 100 features. The story that XG is not UTM parity is not a true story because it does not make sense for a company to have 2 products that require double efforts and time to develop and maintain them.

    No one in the industry is doing the same! I'm really really really disappointed.

  • edit: moved to correct sub-forum

    ---

    Sophos UTM 9.3 Certified Engineer

  • Luk, the basic OS is ubuntu (atleast the kernel part). Its the daemons that they want to reinvent and keep carrying from cyberoam. I guess for compatability with cyberoam CLI. For example VPN, if they had chosen openvpn open source code, they would already know what are the limitations and they could have tailored it to their own requirement with the huge number of programmers they have on their payrol. But they reinvent everything or atleast try to improve the functionality of existing daemons. I guess they think they will have to do it eventually (like http proxy daemon in UTM) so might as well start now. Problem is that writing a daemon is a lot harder than writing shell scripts and its showing up in the speed of development of XG.

    MTA is the prime example. They took awarrenMTA, which wasn't designed as a mail server daemon in cyberoam and have been trying to fix it for two years. In the last year, they added the functionality of smarthost. I just shake my head... there are so many open source MTA servers available, heck the UTM has an open source MTA that has been rock solid forever. Recompile it or postfix for XG and then add cli integration later. Most of the cli stuff is not needed anyway if gui was capable of handling this stuff. Cli is nice in cisco routers or even vyatta when it was alive but XG strength is its gui. Vyatta was successful because they had juniper cli and still linux underneath. XG has limited cli and they have completely locked the linux part down. Someone was trying to change the NDR times on XG, not a problem in UTM or any linux. In XG... I don't think so. What good is CLI if it hinders instead of helps with the OS. I hate CLI anyway. I like gui, and there are billions of people who also like gui otherwise apple and samsung would make fancy CLI instead of beautiful gui. I don't want to look at packet captures etc. I want the gui to tell me that the packet got dropped for such and such reason like the UTM does. Is it too much to ask? Packet capture on a client... yes. Packet capture on the firewall because the logs don't tell you where the packet went is incompetence[:'(]

    Another problem I have is that since the daemons are created in house, they keep giving friendly error messages like here https://community.sophos.com/products/xg-firewall/sophos-xg-beta-programs/sfos-v170-beta/f/sfos-v170-beta-issues-bugs/95959/bug-404-page-error-translation same with MTA and other daemons. Lets keep the errors to industry standard and not try to make them easier to read. I was reading a thread about MTA where the error was the remote server abruptly ended connection. If they had used error codes, it would have been easy to troubleshoot but now this could mean anything. That is why they are having a hard time producing UTM style logs. If regular error codes were being generated, grepping the log file is easy but not if you are making your own error names.

    I am sure sophos is aware of all this and every beta we complain about the same items. The web portion of the team that  is a part of has always done a great job. Its the low level kernel tweakers and daemon writers that can't produce stuff fast enough so that the people that work on gui can impelement that stuff on top. 

    They need object based items like UTM started in v7/8. That made UTM suck for a little while with memory leaks and slow downs in conf daemon but it was necessary. You can name anything whatever you want. The REF_ in conf daemon knows what the object was so naming an interface Timbuktu is no problem in UTM. Not so in XG and there is cost associated with this because PORT1 is hard coded everywhere, you can't just rename it in the GUI. You can't create Qos rules and then try to rename them. This is basic stuff yet XG cannot do it.

    This is so frustrating...

  • Thanks .

    Whatever the OS is, XG does not match up to our expectations. work? The group where he is working in all the time make a great job (apart in the v17 the content filter windows is too small when you need to edit a web profile) but the XG web section is great and the layout/idea used behind I love it.

    Daemons created in-house? Sophos is trying to look like Fortinet, where they develop everything in house. Fortigate AV does not work and web filtering? Forget it (it misses so many ADS and web content).

    A company can produce a limited number of good products but not all. UTM's strength was the usage of third-party modules developed by others SW houses, like the Web Filtering (McAfee), MTA, etc.

    CLI? I love the CLI and also can give some flexibility and also will cover all the customers that love CLI. This is one of the reason that Customers choose Fortigate. You can create Firewall rules, objects, users, VPN settings from CLI. Their CLI is well-ordered!

    I think that Sophos has the best features sets on the market but they are spending time or bending their head on how to make things work. If you do not have a solid base, your castle will fall down as soon you will add more floors on it (and this is already happening).

    To be honest, I do not have other words to show how frustated and disappointed I am, Bill.

  • When v17b is finished and in GA land I will have to rebuild my test box as a UTM again because so far the lack of fixes is disappointing.

    No IPv6 improvements, country blocking not fixed, MTA still not built correctly, reports well they are still broken, logs might get included in v17 GA or maybe MR1?, clienteles users still require an email address, hang on they are clientless. Waiting until tomorrow to see the change to daylight savings affects the report generation time? No-one appears to be tracking this bug?

    Ian

    XG115W - v20.0.3 MR-3 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • Ian,

    I can confirm that with v17 I receive daily reports with 2 hours of delay.

  • ChrisKnight said:
    So realistically we're still years away from seeing feature parity with UTM

    My point was not to explain future velocity, and it would be completely misleading if you try to interpret it that way. I only meant to illustrate that new features are typically too expensive to develop during the timeline of a beta.

    We've been working on v17, since v16.5 shipped, with the exclusion of a period of several months, where we focused on increasing our ability release higher quality code. That means that what you see now, was developed during that period, and that's it. That's not to say that all of our engineering capacity was working on v17. Some of our development teams have in that same time, have already been working on the foundations of the next major version of XG, and we'll talk later, about what that brings, but I believe it will answer a number of important criticisms. 

    As for email specifically, you can expect any significant remaining gaps with UTM9, to be closed early 2018.

  • rfcat_vk said:
    country blocking not fixed

    What is broken in country blocking?

  • Speaking more generally to the many other recent replies, I understand that a number of you are disappointed with the improvements in this release. There are two general complaint buckets. One, is that you want more in v17. I was not planning on outlining what's coming next until the end of the beta, but Ill prepare something for later this week, to at least roughly outline what our next step plans are. I think it there is enough concern over feature velocity, that this is needed sooner than I hoped. The other main complaint, is that there are directional concerns, on why we're doing one thing over another. 

    As frustrating as raw feedback can be at times, I do always appreciate it. Rubbing a rough block of wood with silk, won't make the wood any smoother. I'll try to summarize and respond to some of those, in the near future, also. 

     

Reply
  • Speaking more generally to the many other recent replies, I understand that a number of you are disappointed with the improvements in this release. There are two general complaint buckets. One, is that you want more in v17. I was not planning on outlining what's coming next until the end of the beta, but Ill prepare something for later this week, to at least roughly outline what our next step plans are. I think it there is enough concern over feature velocity, that this is needed sooner than I hoped. The other main complaint, is that there are directional concerns, on why we're doing one thing over another. 

    As frustrating as raw feedback can be at times, I do always appreciate it. Rubbing a rough block of wood with silk, won't make the wood any smoother. I'll try to summarize and respond to some of those, in the near future, also. 

     

Children
No Data