Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 9 replies
  • Subscribers 44 subscribers
  • Views 1865 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

v18 IoT Dyson PureCool not working.

BLS

Hi,

 

The Dyson PureCool IoT device is not working with v18 - out the box configuration with HTTPs rules - worked fine with v17.x

 

See this in the logs

messageid="16002" log_type="Content Filtering" log_component="HTTP" log_subtype="Denied" status=" fw_rule_id="24" user=" user_group=" web_policy_id="12" web_policy=" category=" category_type="Acceptable" url=" content_type=" override_token=" response_code=" src_ip="10.1.1.101" dst_ip="52.16.169.92" protocol="TCP" src_port="53494" dst_port="80" bytes_sent="0" bytes_received="0" domain=" exception=" activity_name=" reason="HTTP parsing error encountered." user_agent=" status_code="403" transaction_id=" referer=" download_file_name=" download_file_type=" upload_file_name=" upload_file_type=" con_id="2394122112" app_name=" app_is_cloud="0" override_name=" override_authorizer=" used_quota="0"

 

Regards

 

-Tim



This thread was automatically locked due to age.
  • 0

    Check your Pattern of SAVI and Avira. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    It's up to date...

     

    If it was that then surely it wouldn't still work when DPI is disabled?

     

     

    Tim Grantham

    Enterprise Architect & Business owner

  • 0 in reply to BLS

    My gut feeling is that it's getting blocked by the DPI engine (HTTP parsing error encountered).

    Tim Grantham

    Enterprise Architect & Business owner

  • +2 in reply to BLS

    BLS said:
    (HTTP parsing error encountered).

    SSH in to XG and execute: "set http_proxy relay_invalid_http_traffic on" at the console.

    See if It works.

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

    Ryzen 5600U + I226-V (KVM) v21 EAP @ Home

    Sophos ZTNA (KVM) @ Home

  • 0 in reply to Prism

    Just funnily enough tried that - and we are back in business :) 

    Tim Grantham

    Enterprise Architect & Business owner

  • 0 in reply to BLS

    I get the feeling that this could make things more interesting - seems that Dyson are their own CA.

     

    Tim Grantham

    Enterprise Architect & Business owner

  • 0 in reply to BLS

    XG SSLx starts to show you very weak / strange IoT vendors.

    I saw a camera with mismatching self signed certificates, which should not be deployed like that.

    Invalid certificates, expired certificates. 

    Looks like, they do what they want... Some vendors ignore TLS errors and simply build connections to any TLS website. 

    We are going to move more and more to IoT devices and those vendors have not enough knowledge to build Wireless devices at all. 

    Just my two cents about this. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Couldn't agree more - they are a law unto themselves.

     

    It's at the point where you need a separate BSID and VLAN just for the IoT devices to do what the hell they like - in all honesty it's been that way for a while...

     

    If they cut corners like this, who's to say what they are allowing into your network?

    Tim Grantham

    Enterprise Architect & Business owner

  • 0 in reply to BLS

    If I may add to this, I had a similar problem with my TP04 fan after upgrading to SFOS18.

    However, my logs revealed that while the firewall allowed the traffic out to the WAN from the "untrusted" VLAN I have for these pesky IoT things, the same rule was then reporting "Invalid TCP State" for the incoming/return traffic.

    So in my case, I also had to go into the console but I had to use the command:

    console> set advanced-firewall tcp-seq-checking off

    I don't like switching off things that are normally on but it seems this was the only way to resolve this. I guess my question is two-fold:

    1) Can this checking be applied to a firewall rule instead of the overall config from the shell?
    2) What risks do I present to the security of my system by having this setting disabled?

    Apologies if I am hijacking this thread and I should be creating a separate one, despite the common denominators being Dyson and SFOS18.

Unfiltered HTML