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()) > 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. Thanks, -- Dominique
