Hi Harald, On Fri, Oct 09, 2020 at 12:07:57PM +0200, Reindl Harald wrote: > Am 09.10.20 um 11:37 schrieb Phil Sutter: > > I guess fundamentally this is due to legacy design which keeps builtin > > chains in place at all times. We could copy that in iptables-nft, but I > > like the current design where we just delete the whole table and start > > from scratch. > > > > Florian made a related remark a while ago about flushing chains with > > DROP policy: He claims it is almost always a mistake and we should reset > > the policy to ACCEPT in order to avoid people from locking themselves > > out. I second that idea, but am not sure if such a change is tolerable > > at all. > bad idea! Why? > nothing is locking you out just because of a short drop phase, at least > not over the past 12 years, that's what tcp retransmits are for What I had in mind was 'ssh somehost iptables -F INPUT'. > when you once accept i have someone which should never have been > accepted in the conntracking - sorry - but when i say drop i literally > mean drop at any point in time My English language parser failed this part, sorry. :) Cheers, Phil
