On Sat, Oct 8, 2022 at 12:47 PM Eugene Crosser <crosser@xxxxxxxxxxx> wrote: > > On 08/10/2022 15:04, Kevin P. Fleming wrote: > > On my firewall machines the nft ruleset contains tables I created > > (using a systemd unit similar to Debian's nftables.service unit) and > > also tables created by Tailscale. > [...] > > I've got an ugly workaround at the moment but I'd like to avoid that. > > I think the simplest solution here would be to enhance 'nft flush > > table <table>' to not report an error if the table does not exist, > > since in the end that was almost the same goal as the command itself. > > Does this seem reasonable? > > You can define the table and then remove it in the next line. Definition will do > nothing if the table exists, and will create and empty one when it does not. That's a great tip! Thanks. > We need to deal with a similar situation, when there may be more than one entity > mucking with the ruleset. The approach that we take now is that everyone who > changes the ruleset must reflect the change in file in /etc/nftabled.d/ > directory, that is included from /etc/nftables.conf. As long as there are no > exceptions to that, it is always safe to flush and reload everything, and also > should be possible to run --check. I wish I could do that, but the Tailscale VPN won't store the rules it needs in a file; it can be told *not* to much with the firewall at all, which means I could inject the necessary rules myself, but I wouldn't be able to know when a new version needs different rules. For now, just using separate tables (with priorities set appropriately) will work fine.
