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.

Hi shred 

Is there a way you can check the IP of the Glow device?

Could you please try to capture packets on the ports used in communication?

Hi,

what I found wasn't the device but the application required access to a lot of unpublished ports which the camera support people only acknowledged after I sent a support request with the limited range I had discovered. The actual range was port UDP 0-65535.

Also found that the application was trying to talk to countries I had blocked, the web logviewer showed a connection, but the firewall rule logviewer should blocked.

Ian

Yes, I see the IP address being registered by the DHCP server. The only thing I see in the firewall logs is an attempt to connect to a destination IP of 8.8.8.8 on UDP Port 53 (DNS) and both 52.26.177.117 and 52.40.15.135 on TCP 443. I did a packet capture from the Diagnostics page and this is what I'm seeing:

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.

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.

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