Re: [PATCH nf v2] netfilter: synproxy: fix rst sequence number mismatch

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

 



Hi Florian,

On 7/14/19 1:25 AM, Fernando Fernandez Mancera wrote:
> El 14 de julio de 2019 0:26:24 CEST, Florian Westphal <fw@xxxxxxxxx> escribió:
>> Fernando Fernandez Mancera <ffmancera@xxxxxxxxxx> wrote:
>>> 14:51:00.024418 IP 192.168.122.1.41462 > netfilter.90: Flags [S], seq
>>> 4023580551, win 64240, options [mss 1460,sackOK,TS val 2149563785 ecr
>>> 0,nop,wscale 7], length 0
>>
>> Could you please trim this down to the relevant parts
>> and add a more human-readable description as to where the problem is,
>> under which circumstances this happens and why the
>> !SEEN_REPLY_BIT test is bogus?
>>
>> Keep in mind that you know more about synproxy than I do, so its
>> harder for me to follow what you're doing when the commit message
>> consists
>> of tcpdump output.
>>
>>> 14:51:00.024454 IP netfilter.90 > 192.168.122.1.41462: Flags [S.],
>> seq
>>> 727560212, ack 4023580552, win 0, options [mss 1460,sackOK,TS val
>> 355031 ecr
>>> 2149563785,nop,wscale 7], length 0
>>> 14:51:00.024524 IP 192.168.122.1.41462 > netfilter.90: Flags [.], ack
>> 1, win
>>> 502, options [nop,nop,TS val 2149563785 ecr 355031], length 0
>>> 14:51:00.024550 IP netfilter.90 > 192.168.122.1.41462: Flags [R.],
>> seq
>>> 3567407084, ack 1, win 0, length 0
>>
>> ... its not obvious to me why a reset is generated here in first place,
>> and why changing code in TCP_CLOSE case helps?
>> (I could guess the hook was called in postrouting and close transition
>> came from rst that was sent, but that still doesn't explain why it
>> was sent to begin with).
>>
>> I assume the hostname "netfilter" is the synproxy machine, and
>> 192.168.122.1 is a client we're proxying for, right?
> 
> Sure, I will prepare a detailed description of the problem. Sorry about that and thanks!
> 

When there is no service listening in the specified port in the backend,
we get a reset packet from the backend that is sent to the client but
the sequence number mismatches the tcp stream one so there is a loop in
which the client is requesting it until the timeout.

To solve this we need to adjust the sequence number, we cannot use the
!SEEN_REPLY_BIT test because it is always false at this point and then
we never get into the if statement. Instead of check the !SEEN_REPLY_BIT
we need to check if the CT IP address is different to the original CT IP.

I hope that answers your questions, here is the tcpdump output with only
the important information. Please note that "netfilter" is the synproxy
machine and 192.168.122.1 is the client. If that is fine to you, I will
include this description into the commit message and send a v3 patch.
Thanks Florian! :-)

TCPDUMP output:

14:51:00.024418 IP 192.168.122.1.41462 > netfilter.90: Flags [S], seq
4023580551,
14:51:00.024454 IP netfilter.90 > 192.168.122.1.41462: Flags [S.], seq
727560212, ack 4023580552,
14:51:00.024524 IP 192.168.122.1.41462 > netfilter.90: Flags [.], ack 1,
14:51:00.024550 IP netfilter.90 > 192.168.122.1.41462: Flags [R.], seq
3567407084,
14:51:00.231196 IP 192.168.122.1.41462 > netfilter.90: Flags [.], ack 1,
14:51:00.647911 IP 192.168.122.1.41462 > netfilter.90: Flags [.], ack 1,
14:51:01.474395 IP 192.168.122.1.41462 > netfilter.90: Flags [.], ack 1,



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux