Re: netfilter resets TCP conversation that was DNATed from the local machine to another

[Ray Leach <raymondl@knowledgefactory.co.za>]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

This is an IE browser problem.
Normal browsers don't send RST after the connection has ended.

On Mon, 2003-06-30 at 16:29, Ramin Dousti wrote:
> On Sun, Jun 29, 2003 at 07:22:13PM -0700, Michael wrote:
> 
> > What would you like me to confirm? That it's broken? It is broken. That 
> > the RST sending port is not the same as the initiating SYN port? It is 
> > not; it's low, just above 1024, so I assumed it to be 
> > netfilter-generated, whereas the Squid port was in the 30000 range. That 
> > my rule set isn't sending it? "I have no reject-with-tcp-reset lines in 
> > my tables." Don't know what else you could mean.
> 
> What I mean is this:
> 
> squid:		ip1:port1
> webserver:	ip2:80
> 
> Then what you say is:
> 
> packet1:	ip1:port1 -> ip2:80    (SYN)
> packet2:	ip2:80    -> ip1:port1 (SYN ACK)
> packet3:	ip1:port2 -> ip2:80    (RST)
> 
> What I'm saying is that the third packet should not be able to tear down
> the connection between ip1:port1 <-> ip2:80  just because the ports are
> different. The TCP stack on ip2 should discard this RST packet...
> 
> Again, my question:
> do you see any other packets between ip1:port1 <-> ip2:port2 after the RST
> packet?
> 
> Ramin
> 
> 
> 
-- 
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]