On Fri, Jan 28, 2005 at 11:44:08AM -0600, eric wrote: > Jan 28 11:23:38.565478 rule 40/0(match): block in on fxp0: > 10.116.131.15.11723 > 10.116.131.1.7357: SWE 4179382606:4179382606(0) win > 16384 <mss 1460,nop,nop,sackOK,[|tcp]> [tos 0x10] (ttl 64, id 44969) > > Jan 28 11:23:44.557060 rule 40/0(match): block in on fxp0: > 10.116.131.15.11723 > 10.116.131.1.7357: S 4179382606:4179382606(0) win 16384 > <mss 1460,nop,nop,sackOK,[|tcp]> [tos 0x10] (ttl 64, id 45638)
Look closely at the TCP flags part of those two packets, they are not identical. The first one has SWE set, that means it's SYN with the ECN bits ECE and CWR set. You must have enabled ECN on the client, check # sysctl net.inet.tcp.ecn When ECN is enabled, a host will try to negotiate ECN for outgoing TCP connections. That is, it sets the flags SWE in the initial SYN. If the reply is a RST, it doesn't know for sure whether the peer is not accepting connections on the port at all or whether it just doesn't understand ECN and sent the RST because of the WE flags. Hence, the host will automatically try again without the ECN bits. Because of this automatic retry you get a delayed 'connection refused' error only after the second RST is received. This is a normal effect of ECN support. > But when I connect to the host from the outside world to de0 (ext_if), the > reset happens immediately. > > Jan 28 11:24:35.447744 rule 0/0(match): block in on de0: 207.227.243.193.3435 > > 67.175.80.217.7357: S 1276381594:1276381594(0) win 16384 <mss > 1460,nop,nop,sackOK,[|tcp]> (ttl 54, id 22646) The external client seems to have ECN support not enabled in the first place, so it begins with a plain SYN and aborts on the first RST. That should explain it entirely, unless sysctl doesn't agree with the theory :) Daniel
