Advanced threat protection breaking Home Assistant functionality with nothing in the logs

I run a "smart home" platform called Home Assistant which has a feature that allows for remote connectivity through their web service called Nabu Casa. Home Assistant runs on a Raspberry Pi 3. When remote control is enabled, this is what occurs during their authentication process:

SniTun server create a SHA256 from a random 40bit value. They will be encrypted and send to client. This decrypt the value and perform again a SHA256 with this value and send it encrypted back to SniTun. If they is valid, he going into Multiplexer modus.

With Advanced threat protection enabled, the remote control functionality is broken and the logs in Home Assistant shows there is a "challenge/response error with SniTun server". When I disable ATP, everything works fine. Unfortunately, with ATP enabled, there is nothing in the logs that shows ATP is actually blocking anything but I have tested this multiple times and positive it's ATP causing the remote control functionality to not work.

When remote control is enabled, I can see in the Home Assistant logs exactly what it's doing and the first step is:

2019-12-09 18:44:36 DEBUG (MainThread) [hass_nabucasa.cloud_api] Fetched (200)

I've tried adding both and to the Network/Host Exceptions in ATP, but it still doesn't work. It only works when ATP is completely disabled.

Any suggestions? It's a bit frustrating the Sophos XG logs don't show anything.

Edit: I also tried changing ATP to "Log" only, and it doesn't work. ATP must be completely disabled.

Edit: It's not just ATP, it appears using any Web Policy causes the same issue. However, if I select "Use web proxy instead of DPI engine", it works fine  Nothing in the logs either. So it appears it's being caused by the DPI engine which I'm assuming ATP is using?

  • Hi Shred,

    I think you will find the ATP uses snort.


    V18.0.x - e3-1225v5 6gb ram on 4 port MB with AP55/c - 20w. 
    If a post solves your question use the 'This helped me' link.
  • That's really strange it works fine with an app control and IPS policy, but not with ATP or a web policy. I believe all four of those functions use Snort.


    Sophos XG guides for home users:

  • As far as i know, there is currently a bug in ATP, if you enable it, it will break stuff. 

     Maybe this breaks your connection in DPI too? Do you have ATP enable? 


  • thanks for the suggestion, but I do not think so.

    I had 2 devs connected on my XG and they found the issue. I have uploaded all the possible logs and they are still investigating.

    I can try your suggestion but the developers should already know if that was the issue, didn't they?



    Security Architect

    UTM Certified Architect - XG Certified Architect

  • I would give it a try. As far as i know, the issue shows as "blank pages" for no reason in ATP. 


  • Tried yesterday, and no change in my case.



    Security Architect

    UTM Certified Architect - XG Certified Architect

  • Hi  

    Thanks you for the feedback. Let me send you PM for more detailing and further investigation.



    Nayan Manvar

  • Hi shred,

    Thank you for sharing a device Access. We are tacking this issue with ID NC-54818.

  • Hi Shred, 


    I took a look at the packet capture and system logs collected by Nayan. Specifically looking at the connection with src ip = and dst ip = that Nayan said was problematic, I can see that an unrecognized protocol is being sent over port 443.


    Unrecognized/invalid traffic will be blocked by default when the web DPI engine is enabled.

    As you have noticed, the web DPI engine is enabled if the web proxy is disabled AND any/all of the following are enabled:

    • AV scanning 
    • ATP
    • Web policy is configured (ie. web policy is not none in the firewall rule)

    I don't have device access to your box to see the firewall rule configured on your box but perhaps you can confirm that this is consistent with the behavior you have seen.


    Do you know what domain resolves to It seems to be an amazon aws server. 


    Here are 3 different ways to workaround the issue:

    1. create a firewall rule with a fqdn host (if you know the domain) or an IP host in the destination network field and ensure web policy is none, av scanning is unchecked, web proxy is disabled, and ATP is disabled globally. Only then will the problematic parser be bypassed.

    2. create a firewall rule with a fqdn host (if you know the domain) or an IP host in the destination network field and choose "allow all" web policy and check "Use web proxy instead of DPI engine". 

    3. enable relay_invalid_http_traffic via cish by following the instructions described here: This is the least recommended approach.


    Please let me know once you have had a chance to try out the workarounds.




  • Paul,

    The only two things I know were causing issues is ATP and web policies. I’m not sure what domain that IP address resolves to but the service Home Assistant uses for remote access is through Nabu Casa ( 

    The current workaround solution I have is I’ve created a separate firewall rule for my Home Assistant device and have “Use web proxy instead of DPI engine” enabled with all my typically policies and AV scanning in place.

    Is it possible to classify this as recognized/valid traffic such that the web DPI engine doesn’t block it?


    Sophos XG guides for home users: