On Wed, 25 May 2022, Hippo Man wrote:
iptables (linux) & pf firewall (freebsd) do drop the packets immediately as the tables are updated.
In my case, that is not occurring. After issuing the iptables DROP command, the client can continue to send more and more login attempts. Only when the client disconnects does the block of the socket seem to work for that IP address. I continue to see numerous instances of this behavior.
I'm running debian 8. Perhaps the iptables on this nearly obsolete version of linux do not behave in the way that you have experienced.
Many firewall keep a side cache of estalished connection. Either implicitly or explicitly, an established TCP session will do an end-run around your rules.
conntrack seems to be the iptables utility you need to flush a connection cache:
https://www.systutorials.com/docs/linux/man/8-conntrack/
e.g. conntrack -D -s x.x.x.xHowever, even this may not be enough as dovecot may send an outgoing packet (being oblivious to firewall rules), which could re-establish a connection as firewall rules typically allow free egress, and can automatically create missing state entries. I'm not sure how this is typically handled -- maybe an outbound block rule is required to handle this niche case to finally drive a stake through a BFD connection's heart.
(more stuff: https://unix.stackexchange.com/questions/646663/iptables-how-kill-establishe...).
Joseph Tam jtam.home@gmail.com