On 9/20/23 07:10, Genes Lists wrote:
You brought this up in Feb [1] and then as now, I don't understand what actual problem you're facing. Inbound 'blocked ranges' (SYN packets) should have no effect. Nothing is 'inbound' to your machines other than replies initiated from your machine - i.e. ESTABLISHED,RELATED. So if you're not able to get replies from arch web servers back to your own machines, then likely your firewall rules are incorrect.
As per the earlier thread, WKD is simply a "web key directory" service - so all the application is doing is pulling from a web server. Unless you're blocking outbound packets to such web servers everything should just work provided you allow arch to reply when you go their web servers.
You should not need any nftables (or legacy iptables) rules provided you allow client machine to have access to the web servers.
One caveat would be if using nftables instead of iptables. nftables supports 2 kinds of blocks - 'netdev' and 'inet'. 'inet' are the normal blocks. 'netdev' blocks very early - and any IPs blocked at that level would not allow inbound or even replies. For anything you want to get replies for you should use 'inet' blocks not netdev. iptables didn't have netdev blocks available last I used it several years ago.
What problem do you actually have?
Genes, You helped greatly with your model nftables.conf! Thank you! Things worked great. I used that to find out how to do the same thing in iptables. The problem is Archlinux now uses Hetzner as the cloud provider with most of the Arch IPs falling in the 95.216.xx.xx range. Unfortunately, there is a lot of miscreants that attempt intrusions from that range so it is dropped in my iptables setup. I had tried to whitelist (ACCEPT) specific Arch IPs, but the archlinux-keyring-wkd-sync was illusive to get a stable IP for. This causes the journal fill with hundreds of thousands of lines of cruft. It makes 'audit' look like a nice journal user. This is compounded by the service file including: Restart=on-failure RestartSec=5minutes Your solution of enabling related, established connections worked, but for those who are not steeped in iptables lore, it wasn't immediately apparent that provided the solution. archlinux-keyring-wkd-sync flies under the RADAR on install as a dependent package whose service file is automatically. Rather than the user having to do something more to ensure archlinux-keyring-wkd-sync can run, I would propose: (1) having archlinux-keyring-wkd-sync check connectivity and for a firewall and add a temporary rule whitelisting the IP it will use so the burden isn't on the user; or (2) on connectivity failure, not restart in perpetuity only to fail again, and again, and again until it can establish a connection successfully. Surely we can at least break the sync loop and disable restart when a connectivity failure occurs and not continue to loop over every signature? It's fine to let is try and run again on schedule a week later and see if the connectivity has gone away. I would also propose adding the model ntfables and iptables rules to the wiki, so anyone else faced with the problem of having archlinux-keyring-wkd-sync fail filling the logs due to a firewall issue have that information at their disposal. This was the circumstance and thoughts I had on the issue so I thought I would pass them along. And thank you again Genes for originally having provided me with the solution. -- David C. Rankin, J.D.,P.E.