[LARTC] netfilter resets TCP conversation that was DNATed from
the local machine to another
Patrick McHardy
kaber@trash.net
Thu, 03 Jul 2003 00:15:36 +0200
Hi Michael,
you should enter this as a bugreport in the netfilter bugtracking system
(bugzilla.netfilter.org). I noticed none of your mails contains the
complete ruleset you use, you should also include this.
Bye,
Patrick
Michael wrote:
> The netfilter list had no answer for this.
>
> I have a configuration:
>
> /------------\ .0.{8,9} .{0,1}.1 /----------\ 1.2.3.{4,5,6}
> ( )
> | Web server |---------+-------------| firewall |---------------(
> Internet )
> \------------/ | eth0 | Squid | eth1
> ( )
> | \----------/
> /---------\ .1.2 |
> | browser |------------/
> \---------/
>
> 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.8:80, .0.8 sends a SYN
> ACK,... but then netfilter spontaneously issues a RST to .0.8:80 from
> another port (i.e., not the one that Squid was using)! I have no
> reject-with-tcp-reset lines in my tables.
>
> Let's watch: I stop and start Squid. I access my domain, xxx.org, from
> my browser. On eth0, I see
>
> 10:52:42.684703 192.168.1.2.4358 > 192.168.1.1.squid: S
> 3347635646:3347635646(0) win 16060 <mss 1460,sackOK,timestamp 54041369
> 0,nop,wscale 0> (DF)
> 10:52:42.685601 192.168.1.1.squid > 192.168.1.2.4358: S
> 3951034191:3951034191(0) ack 3347635647 win 5792 <mss
> 1460,sackOK,timestamp 77755654 54041369,nop,wscale 0> (DF)
> 10:52:42.685952 192.168.1.2.4358 > 192.168.1.1.squid: . ack 1 win
> 16060 <nop,nop,timestamp 54041369 77755654> (DF)
> 10:52:42.686482 192.168.1.2.4358 > 192.168.1.1.squid: P 1:432(431) ack
> 1 win 16060 <nop,nop,timestamp 54041369 77755654> (DF)
> 10:52:42.686801 192.168.1.1.squid > 192.168.1.2.4358: . ack 432 win
> 6432 <nop,nop,timestamp 77755655 54041369> (DF)
>
> That's my browser querying Squid. On eth1, I see
>
> 10:52:42.690711 1.2.3.4.32804 > myisp.domain: 2+ A? xxx.org. [|domain]
> (DF)
> 10:52:42.691228 1.2.3.4.32804 > myisp.domain: 3+ A? xxx.org. [|domain]
> (DF)
> 10:52:42.710447 myisp.domain > 1.2.3.4.32804: 2* 1/2/2 xxx.org. A
> 1.2.3.5 (119) (DF)
> 10:52:42.715838 myisp.domain > 1.2.3.4.32804: 3* 1/2/2 xxx.org. A
> 1.2.3.5 (119) (DF)
>
> That's Squid looking up my domain. (Why twice? I don't know.) The
> OUTPUT chain in the nat table is
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt in out source destination
> DNAT tcp -- * * 0.0.0.0/0 1.2.3.5 multiport dports 80,443
> to:192.168.0.8
> DNAT tcp -- * * 0.0.0.0/0 1.2.3.6 multiport dports 80,443
> to:192.168.0.9
>
> (The PREROUTING chain is identical, to handle requests coming from the
> Internet.) Then on eth0, I see
>
> 10:52:42.719385 192.168.0.1.36065 > 192.168.0.8.www: S
> 3950921369:3950921369(0) win 32767 <mss 16396,sackOK,timestamp
> 77755658 0,nop,wscale 0> (DF)
> 10:52:42.719797 192.168.0.8.www > 192.168.0.1.36065: S
> 3348203817:3348203817(0) ack 3950921370 win 5792 <mss
> 1460,sackOK,timestamp 30595894 77755658,nop,wscale 0> (DF)
> 10:52:42.720206 192.168.0.1.1028 > 192.168.0.8.www: R
> 3950921370:3950921370(0) win 0 (DF)
> 10:52:45.716310 192.168.0.1.36065 > 192.168.0.8.www: S
> 3950921369:3950921369(0) win 32767 <mss 16396,sackOK,timestamp
> 77755958 0,nop,wscale 0> (DF)
> 10:52:45.716595 192.168.0.8.www > 192.168.0.1.36065: S
> 3348203817:3348203817(0) ack 3950921370 win 5792 <mss
> 1460,sackOK,timestamp 30596194 77755658,nop,wscale 0> (DF)
> 10:52:45.716974 192.168.0.1.1028 > 192.168.0.8.www: R
> 3950921370:3950921370(0) win 0 (DF)
> 10:52:46.910244 192.168.0.8.www > 192.168.0.1.36065: S
> 3348203817:3348203817(0) ack 3950921370 win 5792 <mss
> 1460,sackOK,timestamp 30596314 77755658,nop,wscale 0> (DF)
> 10:52:46.910653 192.168.0.1.1028 > 192.168.0.8.www: R
> 3950921370:3950921370(0) win 0 (DF)
>
> and this pattern repeats, with Squid resending its SYN on port 36065,
> and the server asynchronously resending its SYN-ACK, and netfilter (or
> something) sending a RST for every SYN-ACK and thinking it's handled
> the incoming packet.
>
> Eventually Squid changes to port 36066, with the same effect, then
> sends its error page back to the browser. That's all the traffic that
> I see, excepting arp, igmp, my own ssh, and an external www request
> that happened during the long wait.
>
> Ideas as to why netfilter thinks it's handling the SYN-ACK with the RST?
>
> The netfilter thread starts at
> http://lists.netfilter.org/pipermail/netfilter/2003-June/045141.html
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/