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: 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="18.104.22.168" 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.
looks like to do not have a rule in place as it is being dropped "on output" - fwrule="60003"
so a filter rule…
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.
XG & UTM Architect (Systems: XG v18 & UTM 9.7 - Virtual, HW & SW)Curious enough to take it apart, skilled enough to put it back together, Clever enough to hide the extra parts when I'm Done!
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.
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