Drop Package

This is just the normal chattiness of TCP.  It's the device at 95.XX.XX.36 that's sending a RST packet.  The UTM's connection tracker is dropping the packet because the connection was terminated.

Cheers - Bob

This is just the normal chattiness of TCP.  It's the device at 95.XX.XX.36 that's sending a RST packet.  The UTM's connection tracker is dropping the packet because the connection was terminated.

Cheers - Bob

Hi Bob,

Thanks for your reply,

If this would be just one or two drops I would agree with you, but in some cases i can see this happening 4 or 5 times behind each other.

Thanks

There are rare situations where a packet filter timeout needs to be extended.  You would notice connectivity problems, interrupted sessions, etc.  If you're not experiencing any such, it's not worth the time to analyze the firewall log any further.

Cheers - Bob

Hi Bob,

Thanks for you update,

Yesterday one of our customers complaint on  downloading files from a server on our side that is behind the UTM, there is a program that every night will download some pitctures from our image server to thier image server. he said that lately he see that some of files are not downloaded.

I did check the UTM, there is a NAT rule that allows connection to our server on port 22024. I did enable the login for this NAT rule and now I see some drop packages could this be the reson for thier download issue?

How can we have more detailed log information? we would like to see more info in the logs beside only the tcpflags="RST" I mean We would like to know for example the name of the files that being downloaded.

for example in the logs I can see that 3 times behind each other the RST rest!! any suggestion what this could mean and if this is the reson of the issue with download files?

/var/log/packetfilter/2017/07/packetfilter-2017-07-07.log.gz:2017:07:07-16:40:12 securitysrv1-1 ulogd[26224]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="54:d0:32:07:76:9a" dstmac="00:1a:9c:f0:0f:b0" srcip="46.XX.XX.237" dstip="62.XX.XX.184" proto="6" length="40" tos="0x00" prec="0x00" ttl="58" srcport="57018" dstport="22024" tcpflags="RST"
/var/log/packetfilter/2017/07/packetfilter-2017-07-07.log.gz:2017:07:07-16:40:12 securitysrv1-1 ulogd[26224]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="54:d0:32:07:76:9a" dstmac="00:1a:9c:f0:0f:b0" srcip="46.XX.XX.237" dstip="62.XX.XX.184" proto="6" length="40" tos="0x00" prec="0x00" ttl="58" srcport="57018" dstport="22024" tcpflags="RST"
/var/log/packetfilter/2017/07/packetfilter-2017-07-07.log.gz:2017:07:07-16:40:12 securitysrv1-1 ulogd[26224]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="54:d0:32:07:76:9a" dstmac="00:1a:9c:f0:0f:b0" srcip="46.XX.XX.237" dstip="62.XX.XX.184" proto="6" length="40" tos="0x00" prec="0x00" ttl="58" srcport="57018" dstport="22024" tcpflags="RST"

Those reset packets being dropped is normal with TCP and a stateful firewall.  If the problem is not on the client's side, then you need to look someplace other than the firewall log.

Cheers - Bob

Hi Bob,

Thanks for the reply,

By look someplace other then  firewall log you mean some other UTM logs or you mean on the image server behind the UTM?

Thanks

Hi Aresh,

These logs don't relate with the drops over the connection with the internal server. Look at the Packetfilter logfiles information on the UTM.

You can find the firewall logs by hovering the mouse pointer on the magnifier icon situated on the top right of the Web Admin GUI. The drops can be related due to certain things, you can request the customer to capture a .pcap file for the communication and verify the cause of disconnection.

Thanks

HI Sachin,

Thanks for your reply,

sorry I dont understand what you mean with

"These logs don't relate with the drops over the connection with the internal server"

then relate to what? there is a DNAT rule that allows connections over port 22024 to the IP 62.XX.XX.184 (one of the UTM IP's) and than the request must be forwarded to an internal server.

I also check the firewall logs from the location that you meantioned and as you know this only shows the live FW logs and have last information in it.

question remaining is why sometimes the UTM drop the  tcpflags="RST"?

Thanks

My mistake that I was not clear in my previous response. I suspect that the packet is dropped before it gets into the NAT table but let's concentrate on the possibilities of the drops. This might be caused due to IPS, check the ips.log in /var/log directory and monitor if any log line relates to these drop. You can note down the "sid" from the logs and create a rule modification in the IPS | Advance tab | Manual rule modification | Allow.

Any help?

Sachin, don't you think that these RST packets are dropped because conntrack has decided that the connection is closed?

I don't think there's any problem unless someone has a complaint about interrupted connections.  If those do exist, then the timeout could be increased, but I've not heard of that being needed except in remote locations in third-world countries, and today that might no longer be the case.

Cheers - Bob

Thank you for the explanation, I did check the IPS logs for the IP address of the customer that compalint, and I could not find anything.

any suggestion?