Re: synack packet invalid when client reconnecting with same src port because out of window?

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

 



On Thu, 31 Jan 2019, Dominique Martinet wrote:

> Jozsef Kadlecsik wrote on Thu, Jan 31, 2019:
> > Unfortunately a full packet dump is required. I mean, it should contain 
> > the full previous successful connection and the next failing one. Only the 
> > IP/TCP headers are required, without the payload and the IP addresses can 
> > be munged.
> 
> Ok, pretty much what I expected and the reason I've been trying to 
> reproduce all this time. Not much I can do until I get this right; I'll 
> repost once I have something.
> 
> Any idea why nf_conntrack_log_invalid doesn't say anything in dmesg? 
> looking at the code, the only place where tcp_be_liberal makes a 
> difference is followed by a nf_ct_l4proto_log_invalid() call so it feels 
> like I'm missing something... (ugh, I really should look at the correct 
> version of the code - in that version it's LOG_INVALID(net, IPPROTO_TCP) 
> + nf_log_packet())

You should enable nf_conntrack_log_invalid and disable tcp_be_liberal. 
Then the nf_ct_l4proto_log_invalid() is called and we can see in the log 
why the system thinks the packet is out of window.
 
> > Where does the firewall run? On the clients? So the kernel version
> > 3.10.0-693.11.6.el7.x86_64 for the firewall itself, doesn't it?
> 
> Both server and client run the same 3.10.0-693.11.6.el7.x86_64 kernel
> with the default firewalld rules, i.e. iptables -S INPUT is:
> -P INPUT ACCEPT
> -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -i lo -j ACCEPT
> -A INPUT -j INPUT_direct
> -A INPUT -j INPUT_ZONES_SOURCE
> -A INPUT -j INPUT_ZONES
> -A INPUT -m conntrack --ctstate INVALID -j DROP
> -A INPUT -j REJECT --reject-with icmp-host-prohibited
> 
> with some ports accepted in the INPUT_* chains etc
> 
> Flushing iptables on the server doesn't change anything, flushing it on
> the client does allow reconnecting - so it's obviously the client's
> conntrack that is busted.

Best regards,
Jozsef
-
E-mail  : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          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