On Wednesday 28 April 2004 13:45, u9067580@xxxxxxxxxxxxxxx wrote: > I use a test tool to verify my iptables firewall, but unfortunately it > doesn't pass. The test tool doesn't follow the normal TCP 3-handshake > Syn->SynAck->Ack, it goes as below. > 1. A:25205 ---SYN---> B:80 > 2. A:25205 <---SYN--- B:80 > (ie. 25205 and 80 are port numbers) > My test report tells me that it can successfully send a reply (2nd) > packet, which only has SYN flag, through my firewall. I found the tcp > tracking state is SYN_RECV from the /proc/net/ip_conntrack after the > 2nd packet is pass. As my understood, the SYN_RECV only happens when > the "Syn+Ack" packet is pass, doesn't it? No. If a packet with the SYN and ACK packets is received in response to a packet with only SYN sent, you send an ACK (the third part of the three way handshake) and enter the ESTABLISHED state. The "normal" three way handshake does not enter the SYN_RECEIVED state on the client side. What you are seeing is perfectly valid, receiving a packet with only SYN set in response to the first step of the three way handshake enters SYN_RECEIVED and is called a "simultaneous open". Using Google Image Search for "tcp state diagram" will bring up a multitude of diagrams which show this. > Besides, can I only allow those normal TCP 3-handshake packets through > my firewall? Just using conntrack as normal and denying any NEW packets to ports that shouldn't have daemons listening on them probably will not stop these packets. Denying these packets using the --syn flag, for ports that should not have daemons on, should work. I have not tested it but I believe this would stop the situation you describe. If you do test this, please post your results so I and others know whether it works or not. Note that what you are seeing is an acceptable situation however, you may not wish to block it. Hope that helps, David
