On 5/4/07, Pat Riehecky <prieheck@xxxxxxx> wrote:
I just put iptables on our squid box and noticed some very strange activity (IPs have been changed to protect the innocent): [44165032.820000] Dropped default (OUTPUT): IN= OUT=eth0 SRC=MY.PROXY.IP.ADDRESS DST=SOME.RANDOM.IP.ADDR LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=41807 DF PROTO=TCP SPT=3128 DPT=2660 WINDOW=7140 RES=0x00 ACK PSH FIN URGP=0 I have literally thousands of these where it looks like squid is actively opening connections (well trying...) to the outside world. The intervals are somewhat random (and if you really care I can extrapolate them).
It's probably a problem with iptables, not squid. What's probably happening is that your iptables rules include some rules that accept packets for sessions in a RELATED or ESTABLISHED state. And session management is the problem, because sesssions have their own timeout. So what's happening? Client connects to squid destination port 3128. TCP session state is initialized in two different places: conntrack (for the firewalling functions) and the local tcp/ip stack. Due to keepalive, the local tcp/ip stack might hold the state for a very long time - the peer might even be dead; conntrack ages things out more aggressively, and eventually some session will end up being discarded by conntrack even if they're still alive. When squid fires the next TCP keepalive packet (2 hours is the default TCP keepalive probe interval), the firewalling code will look for the session in the conntrack session table, not find it and the following iptables rules will just drop the packet. In other words, nothing to worry about (but you should probably lower your keepalive settings in squid AND tune your Linux TCP parameters) -- /kinkie
