Are you by chance doing any rate limiting actions in your firewall or on your box? Is there any type of balanced connection in place? Port rewrites, etc? -----Original Message----- From: netfilter-bounces@xxxxxxxxxxxxxxxxxxx [mailto:netfilter-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Carlos Pastorino Sent: Wednesday, March 29, 2006 9:06 PM To: Steven M Campbell Cc: netfilter@xxxxxxxxxxxxxxxxxxx Subject: Re: It seems I've found why conntrack blocks some packets The test showed that blocking pop-ups does not generate the desired behavior, because the 3-way handshake completes normally, even for the blocked pop-up. So I dug a little deeper. I checked other connections from the same customer, that were also around the same time. They didn't caught my attention before because there were no packets blocked FROM the webserver. The problem is, this shows that the problem can be in my firewall after all. Here are the connections. First, the blocked packets on the firewall: Mar 28 14:46:50 SRVA kernel: FORWARD blocked: IN=eth0 OUT=eth1 SRC=customerip DST=webserverip LEN=40 TOS=0x00 PREC=0x00 TTL=26 ID=1 PROTO=TCP SPT=2184 DPT=80 WINDOW=0 RES=0x00 ACK URGP=0 Mar 28 14:46:56 SRVA kernel: FORWARD blocked: IN=eth0 OUT=eth1 SRC=customerip DST=webserverip LEN=40 TOS=0x00 PREC=0x00 TTL=26 ID=1 PROTO=TCP SPT=2184 DPT=80 WINDOW=0 RES=0x00 ACK URGP=0 Mar 28 14:47:08 SRVA kernel: FORWARD blocked: IN=eth0 OUT=eth1 SRC=customerip DST=webserverip LEN=40 TOS=0x00 PREC=0x00 TTL=26 ID=1 PROTO=TCP SPT=2184 DPT=80 WINDOW=0 RES=0x00 ACK URGP=0 Mar 28 14:47:32 SRVA kernel: FORWARD blocked: IN=eth0 OUT=eth1 SRC=customerip DST=webserverip LEN=40 TOS=0x00 PREC=0x00 TTL=26 ID=1 PROTO=TCP SPT=2184 DPT=80 WINDOW=0 RES=0x00 ACK URGP=0 Mar 28 14:48:20 SRVA kernel: FORWARD blocked: IN=eth0 OUT=eth1 SRC=customerip DST=webserverip LEN=40 TOS=0x00 PREC=0x00 TTL=26 ID=1 PROTO=TCP SPT=2184 DPT=80 WINDOW=0 RES=0x00 ACK URGP=0 Mar 28 14:57:34 SRVA kernel: FORWARD blocked: IN=eth0 OUT=eth1 SRC=customerip DST=webserverip LEN=40 TOS=0x00 PREC=0x00 TTL=26 ID=1 PROTO=TCP SPT=2184 DPT=80 WINDOW=0 RES=0x00 ACK RST URGP=0 and now the tcpdump on the webserver: 14:46:46.153552 customerip.2184 > webserverip.80: S [tcp sum ok] 290916053:290916053(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 120, id 41051, len 48) 14:46:46.153561 webserverip.80 > customerip.2184: S [tcp sum ok] 4139392508:4139392508(0) ack 290916054 win 5840 <mss 1460,nop,nop,sackOK> (DF) (ttl 64, id 0, len 48) 14:46:50.527630 webserverip.80 > customerip.2184: S [tcp sum ok] 4139392508:4139392508(0) ack 290916054 win 5840 <mss 1460,nop,nop,sackOK> (DF) (ttl 64, id 0, len 48) 14:46:56.527621 webserverip.80 > customerip.2184: S [tcp sum ok] 4139392508:4139392508(0) ack 290916054 win 5840 <mss 1460,nop,nop,sackOK> (DF) (ttl 64, id 0, len 48) 14:47:08.527607 webserverip.80 > customerip.2184: S [tcp sum ok] 4139392508:4139392508(0) ack 290916054 win 5840 <mss 1460,nop,nop,sackOK> (DF) (ttl 64, id 0, len 48) 14:47:32.727574 webserverip.80 > customerip.2184: S [tcp sum ok] 4139392508:4139392508(0) ack 290916054 win 5840 <mss 1460,nop,nop,sackOK> (DF) (ttl 64, id 0, len 48) 14:48:20.927521 webserverip.80 > customerip.2184: S [tcp sum ok] 4139392508:4139392508(0) ack 290916054 win 5840 <mss 1460,nop,nop,sackOK> (DF) (ttl 64, id 0, len 48) As you can see, here even the ACKs that were supposed to complete the 3-way handshake are getting blocked. What could possibly be the reason for this? Regards, Carlos
