Am 08.07.19 um 23:27 schrieb Reindl Harald: > Am 08.07.19 um 22:05 schrieb Will Storey: >> On Mon 2019-07-08 21:07:16 +0200, Reindl Harald wrote: >>> Am 08.07.19 um 20:43 schrieb Florian Westphal: >>>>> 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" >> >> Right, sorry, I was wondering about the INVALID rule given it would still >> be applied to non-lo traffic. >> >>> 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 >> >> That is concerning if it's the same issue! > > it is, th eversion with "! -i lo" has no problem > > iptables -t mangle -A PREROUTING -p all -m conntrack --ctstate INVALID > -j DROP > > iptables -t mangle -A PREROUTING -p all -m conntrack --ctstate INVALID ! > -i lo -j DROP > > -t mangle for DROP rules because you don't need to write the same rules > in INPUT and FORWARD and it skips NAT / routing decision while you still > can have your EST/RELATED quick path on top in fact that breaks even more i have a complexer setup with a nested ESXi within VMware Workstation * vmnet8: 192.168.196.2 * ESXi: 192.168.196.3 * Guest on ESXi: 192.168.196.4 * Firewall on ESXi: 192.168.196.5 * NETMAP NAT: 172.17.0.0/24 <-> 172.16.0.0/24 * Destination: 172.17.0.3 * Static Route: 172.17.00/24 -> 192.168.196.5 with the above rule on the *host* SSH from 192.168.196.4 to 172.17.0.3 is not possible at all and it's for sure the "--ctstate INVALID" rule because when i put the INVALID-Rule in "-tmangle" in the INBOND-Chain limited to the interface "wan" everything is just fine 192.168.196.4 -> 192.168.196.2 -> 192.168.196.5 -> 172.17.0.3 -> 172.16.0.3 the intermediate nat/firewall on 192.168.196.5 between the host network and the nat client has the same rule in -t mangle with no problem looks like it has some issues with wrapped / tunneled connections as well as "lo" - that pretty sure started around kernel 5.0 introduced in Fedora because the day i forst noticed the freeze was when i staretd to deploy 5.0 in the hope some random crashes may go away on my office machine as well as on my home environment, move it to the custom INBOUND-Chain was the solution months ago too
