Am 08.07.19 um 20:43 schrieb Florian Westphal: > Will Storey <will@xxxxxxxxxxxxx> wrote: >> On Mon 2019-07-08 17:51:21 +0200, Florian Westphal wrote: >>> Anton Danilov <littlesmilingcloud@xxxxxxxxx> wrote: >>>> To avoid this issue you can tune the conntrack behaviour with sysctl: >>>> sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1 >>>> sysctl -w net.netfilter.nf_conntrack_tcp_loose=1 >>> >>> Yes, a better alternative in this case though would be to >>> NOTRACK packets from/to lo interface. >>> >>> Its kind of silly that conntrack tracks them be default IMO. >> >> Yeah, these options seem to fix it as well. It is weird that only some of >> the half open connections seem to need it though, while others I see a RST >> and they work either way. >> >> Another thing I'm wondering is whether this rule could be impacting >> connections beyond lo, but I just don't know about it. > > NORACK? If you restrict it via -i lo / -o lo, then no, it won't affect > anything else. > > NAT for such connections won't work but thats normally not an issue > in the loopback case. i think the question was if "iptables -t mangle -A PREROUTING -p all -m conntrack --ctstate INVALID -j DROP" also breaks things beyond the "lo" interface which it shouldn't and don't appear to, but who knows it shouldn't break anything at all, also not on "lo" if you wan't to reproduce this setup SSH-forwarding to a VNC server, let the VNC window in the background and after a realtive short amount of time the tunneled connection with tigervnc-1.9.0-3.fc29.x86_64 just freezes with the last picture
