Mayuresh wrote in <20210331170102.GA1969@localhost>: |On Wed, Mar 31, 2021 at 09:42:45AM -0700, Greg A. Woods wrote: ... |> That becomes more complicated if it's the remote (client) side that has |> the changing address and you don't already have a pre-determined way to |> do these updates and actions based on a remote trigger or some other |> kind of locally initiated monitoring. | |I can arrange for a client side device to 'inform' the server when the IP |changes. When this happens, the server may whitelist it at npf level. But |if later, blocklistd tries to block it, what exactly happens. Is it |something like I have to put the whitelisting at the end of the filter |list or something so that it will have higher precedence than blocklistd?
Btw i now use WireGuard VPN and use the same strict rules as for OpenSSH on the port. This works nice since once handshakes are done those ListenPort's are no longer beaten at. Despite having a port-knocker at hand to whitelist my IP for another try (i sometimes have _very_ bad internet connection and then a SSH handshakes did not complete, causing me (the dynamic IP that is "me" for the server) to become blacklisted, so i searched for a way out while keeping the strict rules), i have implemented a WireGuard specific watchdog which runs via cron every quarter of an hour i think. It looks at the "Endpoint", and whitelists it in an "i_good" chain that is inspected before after RELATED, ESTABLISHED but before i_alien, i_tcp_new aka i_udp and i_rejector. Like this the worst that can happen is that i am blacklisted for i think 15 minutes, after that we get through again. One bad effect is that i have multiple VPNs for different purposes, and so IP addresses may be whitelisted to beat at WireGuard ports (only!) which are long used by someone else. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)