Next EAP release date?

Hi

Michael McCoy said:

 

Want to understand the "random reboot" issue you have been facing with EAP2. Please provide some more details around what you have experienced. Thank you very much for your feedback.

The next EAP - EAP3 - has been put to final test in our own production systems. In a positive path - it usually go through a week or 10 days of soaking before we release it to our community contributors. Stay tuned.

Catalina MacOS issue has been discussed here: https://community.sophos.com/products/xg-firewall/sfos-eap/sfos-v18-early-access-program/f/feedback-and-issues/115757/compatibility-caa---mac-catalina---bug

Thanks PMParth. I hope you fix all the issues with DPI as some users are not able to use it as expected. I am one of the user.

FYI, I opened the thread on Catalina OS and worked with some devs to understand and share logs why the CAA does not work. Please keep going and improve performance on UI and web experience surfing.

Regards

At this point, I am not seeing any reason to run DPI instead of proxy. Don't want this thread to turn into DPI problems since we have other threads for that but proxy works so much better than DPI that it is not worth the headache even in a test environment. Also separate exception lists are just more overhead for admin to keep up with. I personally wouldn't use DPI until DPI Performance is clearly better than proxy and the exceptions lists etc. are more streamlined throughout the system.

I agree with Luk that the next release should focus more on polishing the system and eventually revisiting a GUI redesign in the near future where its easier to manage the workflow of the whole system instead of other new shiny functions that are not fully integrated yet.

Regards

Bill

Billybob said:

At this point, I am not seeing any reason to run DPI instead of proxy. Don't want this thread to turn into DPI problems since we have other threads for that but proxy works so much better than DPI that it is not worth the headache even in a test environment. Also separate exception lists are just more overhead for admin to keep up with. I personally wouldn't use DPI until DPI Performance is clearly better than proxy and the exceptions lists etc. are more streamlined throughout the system.

Hi folks,

DPI works very well with devices that you cannot install a CA on eg IoT devices.

Ian

Hi folks,

DPI works very well with devices that you cannot install a CA on eg IoT devices.

Ian

Gentlemens, there is potential in DPI. Remember that this is an early access phase. Not everything goes well, some pages are not decrypted, but the mechanism itself seems to be OK. Let's give the Sophos a chance to prove themselves.

The idea is innovative, but it needs to be refined. That is why we are a community to help in this. Instead of complaining, let's report bugs - thanks to this next releases will be much better.

rfcat_vk, in my case DPI is introducing more issues than proxy. I am using SSL decrypt and scan since v16 and not big problem.

darnoK, "the idea is not innovative". Other brands are using DPI since several years and I can remember the frustration at the beginning with another vendor when the customer moved from UTM 8 to the new brand. SSL/TLS was painful. Many websites stopped working.

Using DPi is the way to go for a NGFW instead of UTM as the same packet is analysed once (or very few times) compared to UTM where the same packet is open/closed and analysed by many different engines.

I fully understand how difficult is to integrate everything with snort engine but for the moment, a part my issue and some others, they did a great job with DPI. From v18 GA, DPI can only improve.

XG suffers other big problems at the moment and I hope they listen and they stop to close features that are not yet completed, as they do not.

Regards

You mean, that works very well with devices that you CAN install a CA?

It won't work well on IoT because you CAN NOT install a CA.

I just want to undestand you statment correctly.

Hi,

you read my post correctly. I am using DPI on my IoT devices and they connect other internet where as the same devices with the web proxy and https inspection fail.

I suspect the reason they connect is they are using the do not decrypt part of the web rule.

I do find it a ;little sctrange in that I did create a ssl/tls specifically for my IoT devices that did not pass traffic even after I disabled the default rules.

So a little unclear as to what is happening.

Ian

Update: - I looked the logviewer after 24hrs and found that two of IoT devices without CAs are passing the decrypt function in my TLS/ssl rule.