Unable to setup an Awair Glow device

Hi Shred,

have you setup the modified default firewall block 0 so you can see what is being dropped?

Required WiFi Specifications

Glow is only compatible with 2.4GHz B/G/N WiFi networks. Glow can operate on dual band routers (2.4GHz and 5GHz), but we recommend giving each band a separate SSID before connecting to the 2.4GHz network. We also recommend turning off the load balancing feature for dual routers, as this can occasionally move Glow to the 5GHz network. Your firewall must also allow access to TCP ports 8883, 123, and 443.

Ian

Yeah, it’s on a separate VLAN and I turned on logging for that firewall rule. I don’t see anything being dropped.

I've tried everything I can possible think of with this one. It works perfectly fine when I pair it to my phone as hot spot, so I'm fairly confident the device is fine. It never had any issues on Sophos XG v17, so something under the hood with v18 it does not like.

Did you try to disable the DPI Engine? (Disable and / or the Off Switch - Try both).

Do you see something in the TLS Logviewer? 

Hm, I did try all that before but I just gave it a shot again and it seems after disabling SSL/TLS inspection by turning the entire thing off, it's now able to connect. I'm confused as to why this is though. This device is on a separate VLAN and separate firewall rule that does not have SSL/TLS scanning enabled, so why is this setting affecting that firewall rule? This separate VLAN is for my guest network and only has one firewall rule, which has no scanning at all.

Hi Shred,

SSL/TLS scanning happens on all none proxy rules according to the experts.

Ian

You should be able to make an exclution for your device for the DPI engine.

https://community.sophos.com/products/xg-firewall/f/recommended-reads/115976/sophos-xg-firewall-v18-xstream---the-new-dpi-engine-for-web-proxy-explained

//Rickard

I guess I no longer understand how Sophos XG works.

If I have a device with:

• All policies set to None on the firewall rule
• All options under Web Filtering deselected on the firewall rule
• No SSL/TLS inspection rule defined
• ATP turned off

My understanding is that is no longer using the DPI engine or proxy.

Can someone explain how the DPI engine is still being used?

Secondly, why would turning SSL/TLS inspection to off make any difference for a device that wasn't using SSL/TLS inspection to begin with?

Hi Shred,

I asked about setting up a firewall rule without DPI during the EAP. MichaelDunn responded with a very detailed explanation of how it all works.

I will search the EAP forums and up date this post with link to the answer.

Ian

Hi rfcat_vk 

Are you looking for this - https://community.sophos.com/products/xg-firewall/f/recommended-reads/118753/sophos-xg-firewall-v18-troubleshooting-problems-with-the-dpi-engine

Hi Keyur,

thank you, that is probably a better link than the one I was after.

Ian

I have read his posts (which are extremely helpful and informative), but that is why I'm confused. If you read my post, it's covering the steps he mentions. Specifically, in regards to IoT devices, he mentions:

If you have an IoT device that does not work, my recommendation is to first have it working with no filtering/scanning/decryption. Once this is working, administrators can then make changes that improve security around these devices.

Firewall Rule - The IoT device should hit a rule that has no web policy and no malware scanning. When you open the rule the Web Filtering section should be unexpanded. The Other security features should be be set to None.

SSL/TLS inspection rules - The IoT device traffic should hit a rule that is Don't Decrypt with a profile Maximum Compatibility, or it should have no matching rule. If you have some TLS decryption rules for some things, you can create a higher level rule with don't decrypt that uses source of your device, similar to your firewall rule.

Let me highlight the steps he mentions:

• "no filtering/scanning/decryption" - I did that.
• "no web policy and no malware scanning" - I did that.
• "Other security features should be be set to None" - I did that.
• "or it should have no matching rule" - I did that.

So again, I don't understand why turning SSL/TLS inspection to off (the "master switch") has any affect for a device that wasn't using SSL/TLS inspection to begin with.

I have read his posts (which are extremely helpful and informative), but that is why I'm confused. If you read my post, it's covering the steps he mentions. Specifically, in regards to IoT devices, he mentions:

If you have an IoT device that does not work, my recommendation is to first have it working with no filtering/scanning/decryption. Once this is working, administrators can then make changes that improve security around these devices.

Firewall Rule - The IoT device should hit a rule that has no web policy and no malware scanning. When you open the rule the Web Filtering section should be unexpanded. The Other security features should be be set to None.

SSL/TLS inspection rules - The IoT device traffic should hit a rule that is Don't Decrypt with a profile Maximum Compatibility, or it should have no matching rule. If you have some TLS decryption rules for some things, you can create a higher level rule with don't decrypt that uses source of your device, similar to your firewall rule.

Let me highlight the steps he mentions:

• "no filtering/scanning/decryption" - I did that.
• "no web policy and no malware scanning" - I did that.
• "Other security features should be be set to None" - I did that.
• "or it should have no matching rule" - I did that.

So again, I don't understand why turning SSL/TLS inspection to off (the "master switch") has any affect for a device that wasn't using SSL/TLS inspection to begin with.

It doesn't matter, since the DPI engine will still look in to the traffic. So you need to make an exception for the URL/IP-address the device is trying to access.

I know, this is not the answer you would like, but this is who it's works today. I agree that if you choose not to scann and decrypt the DPI engine would NOT play with the traffic, but this is the way it works right now.

You can also make a rule the uses the "v17.5" version "use proxy instead of DPI" and add the url as the destionation. This will work as well.

//Rickard

I'm just trying to understand how Sophos XG works, which even after a couple years, I'm still not quite sure. :)

So you're saying all traffic, regardless of policies, ATP, etc. go through the DPI engine which is what's causing the issue. That's fine, but I still don't understand why:

1) When I turned off SSL/TLS inspection (the "master" switch or whatever you want to call it), why it started working? Does this cause all traffic to bypass the DPI? I don't think that's the case, because I can still have ATP enabled or other policies enabled on a firewall rule that use the DPI engine.

2) One of the first things I tried was "use proxy instead of DPI", but it still didn't work.

Again, the only thing that worked is turning off the overall SSL/TLS inspection toggle, which is why I'm confused.

This one continues to remain a mystery. I have two Awair devices, the original Awair device and the Awair Glow. This issue only occurs with the Awair Glow. The original Awair device has no issues what so ever with Sophos XG. However, the Awair Glow only works if SSL/TLS inspection is completely turned off, even though the Awair Glow is using a firewall rule with all scanning turned off.

There are improvements hence IoT Devices in the future releases of XG v18. 

I would rather say, your Awair Glow uses systems, which are kinda break the DPI Engine. 

If you dump such traffic of your Glow, you will likely see some odd stuff of the communication. IoT developer are kinda "Funky" in their way of implementing stuff. 

For example, there are IoT Devices which are ignoring all Best practices and RFC of communication via TLS. They connect to devices, ignore the certificate validation and doing downgrades within the connection. Such stuff could properly break the DPI stream connection. 

Long story short, expect some improvements in the next releases of V18. 

Thanks for the info! I'll be sure to test it out with the upcoming releases of v18.