RE: Weird nat/conntrack Problem with PASV FTP upload

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 9 Jun 2008, Thomas Bätzler wrote:

> Jozsef Kadlecsik wrote:
> > On Mon, 9 Jun 2008, Thomas Bätzler wrote:
> >> In any case I'm wondering why netfilter doesn't consider
> >> these packets  to be part of a connection. Is there a
> >> known problem with netfilter and TCP SACK?
> > 
> > In these cases usually there is a device sitting between the 
> > firewall running netfilter and the server/client machine, 
> > which randomizes the TCP sequence numbers but fails to 
> > propagate the changes to the SACK fields. 
> > Thus the SACK values are totally bogus and therefore 
> > netfilter marks them as INVALID.
> 
> I thought of that, too, but it doesn't seem to be the case.
> Let's have a look at an excerpt (tcpdump -S):
> 
> 22:37:44.830784 IP gateway.41803 > server.37890: SWE 1599996997:1599996997(0) win 5840 <mss 1460,sackOK,timestamp 495055487 0,nop,wscale 7>
> 22:37:44.846411 IP server.37890 > gateway.41803: SE 23582050:23582050(0) ack 1599996998 win 5792 <mss 1460,sackOK,timestamp 49338617 495055487,nop,wscale 7>
> 22:37:44.846533 IP gateway.41803 > server.37890: . ack 23582051 win 46 <nop,nop,timestamp 495055488 49338617>
> 
> [...]
> 
> 22:37:44.974253 IP gateway.41803 > server.37890: . 1600282667:1600284115(1448) ack 23582051 win 46 <nop,nop,timestamp 495055501 49338649>
> 
> [...]
> 
> 22:37:44.989794 IP server.37890 > gateway.41803: . ack 1600281219 win 892 <nop,nop,timestamp 49338653 495055501>
> 22:37:44.990228 IP gateway.41803 > server.37890: . 1600358775:1600360223(1448) ack 23582051 win 46 <nop,nop,timestamp 495055502 49338653>
> 
> [...]
> 
> 22:37:44.990397 IP server.37890 > gateway.41803: . ack 1600281219 win 892 <nop,nop,timestamp 49338653 495055501,nop,nop,sack 1 {1600282667:1600284115}>
> 22:37:44.990417 IP gateway.41803 > server.37890: R 1600281219:1600281219(0) win 0
> 
> As you can see, the SACK data matches a previously sent segment,
> so it's not scrambled.

Then the best were if you could capture a full TCP session by tcpdump and 
send it so that we could replay and analyze the traffic.

Best regards,
Jozsef
-
E-mail  : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux