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

[Michael <freeware@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

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.

Ramin Dousti wrote:
> > I have a configuration, so:
> >
> > /------------\ .0.2     .{0,1}.1 /----------\ 1.2.3.4  (          )
> > | Web server |-----+-------------| firewall |---------(  Internet  )
> > \------------/     |        eth0 |  Squid   | eth1     (          )
> >                    |             \----------/
> > /---------\ .1.2   |
> > | browser |--------/
> > \---------/
> >
> > - The 192.168.{0,1}. subnets run on the same wire.
> > - Port 80 on the public i/f is DNATed to the internal Web server.
> >
> > The firewall is running Squid to proxy for 192.168.1. clients, and it 
> > works fine *except* when the target server resolves to a public IP on 
> > eth1.  When that happens, I see the client-to-Squid communication go OK, 
> > then Squid send a SYN (from .0.1) to .0.2:80, .0.2 sends a SYN ACK,... 
> > but then netfilter spontaneously issues a RST to .0.2:80 from another 
> > port (i.e., not the one that Squid was using)!
> >   
>
> No idea why this RST is being sent (might have to do with your rule set or
> more possibly the internals of squid) but the fact that you say the RST
> sending port is not the same as the initiating SYN port should not break
> anything. Can you confirm this?
>
> Ramin
>
> > I have no reject-with-tcp-reset lines in my tables.
> >