Default Drop Rule

Hi,

I am seeing entries in my packet filter logs where the "Default Drop Rule" is dropping packets from the outside interface of my ASG box to the outside world.
 
19:45:29 Default DROP TCP 67.78.124.162 : 44550 
 → 204.0.3.64 : 80 
 [ACKFIN ] len=52 ttl=64 tos=0x00 
 
 
Any ideas/reason why the box its self would be connecting to this site?

The connection is probably either from a client that is connecting through the firewall (and gets masqueraded on the outside interface) or he is connecting through the proxy on the ASG.



Nevertheless, dropped ACK-FIN packets are usually observed on TCP connections where the shutdown of the connection takes to long (IP conntrack
requires the FIN packet to arrives in 60 seconds after the last packet). 


So if the delay between the last packets are >60s, the kernel removes the connection tracking entry, and drops the packet as he has no connection where this packets belongs to.

The same happens if the connection was unexpected shutdown by a RST packet from the other side.


In most cases this is a condition that can be ignored - if that is not the case, i would start looking what's causing this delay.


Cheers,


Sven.

Hi,

I am seeing entries in my packet filter logs where the "Default Drop Rule" is dropping packets from the outside interface of my ASG box to the outside world.
 
19:45:29 Default DROP TCP 67.78.124.162 : 44550 
 → 204.0.3.64 : 80 
 [ACKFIN ] len=52 ttl=64 tos=0x00 
 
 
Any ideas/reason why the box its self would be connecting to this site?

The connection is probably either from a client that is connecting through the firewall (and gets masqueraded on the outside interface) or he is connecting through the proxy on the ASG.



Nevertheless, dropped ACK-FIN packets are usually observed on TCP connections where the shutdown of the connection takes to long (IP conntrack
requires the FIN packet to arrives in 60 seconds after the last packet). 


So if the delay between the last packets are >60s, the kernel removes the connection tracking entry, and drops the packet as he has no connection where this packets belongs to.

The same happens if the connection was unexpected shutdown by a RST packet from the other side.


In most cases this is a condition that can be ignored - if that is not the case, i would start looking what's causing this delay.


Cheers,


Sven.

And how would I know if that were the case?  Is it not possible to code the packet filter reporting  in such a way that it gave an accurate descriptin of what is going on?

If no one is complaining, then you should be able to assume that nothing is broken, and ignore the stray ACKFINs.

They're caused by different timeouts on different systems, as well as MS's TCP shortcuts in IE and IIS. I've ranted about this here before.

Barry