some packets dropping 443
sohand
Newbie ✭
Hey all
Having an issue with a device another company has put in not communicating with their cloud system. its a clock that records staff entering and leaving the building. its replaced an older clock but new clock connects a different way. Thye just told us they put these newer clocks on other sites of ours and i can see them but we didn't have to do anything on the other sites. No rules of any kind and its working on these others sites. new system uses port 443 and i can see a lot of packets forwarded but then get the odd random drops. Error code 736. Disabled all security and even the vpn on it just to try. Updated firmware also just in case, still dropping.
They cant tell me if they are seeing anything traffic at all hit their systems, not sure if they wont or just cant check it. cant.
Im not familiar myself with doing pact captures dont really understand what im looking, but from what i do know when i see a dropped packet that means its our own SW dropping, its not even trying ot send the packet?
Answers
@sohand as you can see the "cache add cleanup drop the pkt" means that an unclosed/timedout connection is dropped from the connection cache, this is pretty common and nothing to worry. If it interrupts your service you might consider to increase the TCP timeout for that specific destination via Access Rule to keep the connection longer in the cache. This is usually not necessary when something like KeepAlives are refreshing the default 15 Minutes timeout.
--Michael@BWC
Hey Michael
Ta for this, them forwarded packets does that mean they have left the premises and are trying to hit their systems then?
the router here is in bridged mode and the SW has the PPPOE configured on it. Any chance the system is failing there or fact its in bridged mode doesnt come into it?
all they keep telling me is the clock isnt connecting, im getting zero feedback re any traffic hitting them at all.
@sohand yes the forwarded packets meaning that there was traffic flow, according to your screenshot there was some exchange between the systems. If the cache clean drop is the only packet dropped you're golden and it might have some other reason when the communication isn't working out.
I guess 192.168.9.40 is your system and 46.22.142.118 the destination? If you have a look at the forwarded packet you might see the SYN, SYN/ACK handshake and in the ACK packages the certificate exchange? Is DPI-SSL involved, if yes you might exclude the clock from it.
--Michael@BWC
cache clean drop on all dropped packets alright is all im seeing.
yes on the ip's there alright
with the handshake ive set a filter on the monitor to just show IP and the source ip of the clock (192.168.9.40) will this filter out the full handshake?
no dpi-ssl involced on this firewall
@sohand I would go with these Packet Monitor settings, they cover everything from the clock which touches the Firewall.
Another thing to think about, when the clock of the clock 🤣 is completely out of sync the https handshake might fail, but this would be a big design flaw of the system itself.
--Michael@BWC
no dropped packets on the other firewall that has the clock running ok.
not big on wireshark meself but could see with the help of someone that there was a handshake but then on another tcp stream it would drop.
The clock could cause this if the time is set wrong really on it itself? i can ask him to check but on the local web interface to access it it will only show the time there once the first sync has taken place. not sure if they can tit manually themselves. i have ni access ot it to check
got this going by getting them to change the clock to use the port forwarding option. this now is the same setup as the old clock before it died.
All working now.
on this whole packet capture and understanding what im actually looking at, any chance you know of a good starting point for this for me to lookup at all?
@sohand just for my understanding, what did you changed to get it working? You changed the NAT that the connection is initiated from the WAN to your clock instead the other way around?
IMHO a good start into Wireshark and Packet analysis is this guy here:
Over time you'll get more experienced, as always, learning by doing is key.
--Michael@BWC