Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 6 subscribers
  • Views 911 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

Vine Thermostat

Scott Gottleber

I have vine smart thermostats and I can't get them to connect to the server on their end for updating.

I had them working until I installed my sophos UTM and now no matter what settings I have I can't figure out what is blocking it.

I keep getting

2020:09:14-00:00:25 ****** ulogd[623]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="eth1" mark="0x144e" app="1102" srcmac="40:62:31:13:f7:f3" srcip="52.52.126.248" dstip="192.168.1.8" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="80" dstport="49153" tcpflags="ACK PSH FIN" 

Thanks for the help.


This thread was automatically locked due to age.
  • 0

    looks like to do not have a rule  in place as it is being dropped "on output" - fwrule="60003"

    https://support.sophos.com/support/s/article/KB-000034242?language=en_US

    so a filter rule on eth1 is stopping it from working, and the destination ip of "192.168.1.8"

    you will need to understand what is going on and what rules are stopping it.

  • 0

    Hello Scott,

    Thank you for contacting the Sophos Community!

    Make sure you have the correct Firewalls to allow this traffic if as mentioned by Argo, there must be a rule or lack of one that is causing this drop.

    Try creating a Firewall rule for this host "192.168.1.8" with service ANY destination ANY make sure the position of this rule is on Top. 

    Regards,

  • 0

    This looks like a problem with the Vine server in Amazon AWS, Scott.  Its response to your thermostat's HTTP request was blocked because the UTM's stateful firewall thought that the conversation was over - probably because the server took longer than expected to respond.  Then again, maybe this is nothing to worry about and it's just another example of the "chattiness" of TCP - maybe the server had indeed finished updating the thermostat - can you tell if it was updated?

    If there is a problem, we'll need to try changing one of the ip_conntrack_tcp_timeout values.

    Cheers - Bob