| 18 Mar 2024 |
 mkg20001 | if i have, say, a vpn or something else on that server | 13:58:21 |
 adamcstephens | yeah | 13:58:36 |
| adamcstephens | this is the problem with defaulting firewall rules :) | 13:58:44 |
| mkg20001 | what do you think of the named set? should i go implement that? | 13:59:08 |
| adamcstephens | so what does that look like? a table that allows a named set of interfaces for trusting, and what updates that set/ | 13:59:47 |
| adamcstephens | * so what does that look like? a table that allows a named set of interfaces for trusting, and what updates that set? | 13:59:49 |
| adamcstephens | how would you hook into incus/lxd? | 14:01:06 |
| mkg20001 | nft add element inet nixos-fw trustedintfs { incusbr0 } is the command to add to the set | 14:02:23 |
| mkg20001 | incus could support an INTERFACE_UP_HOOK / INTERFACE_DOWN_HOOK where the host os could supply the command to open the firewall for the interface, there we could use something like nft add element inet nixos-fw trustedintfs { $INTERFACE } | 14:03:15 |
| adamcstephens | i wonder if this should really be handled by incus directly. they're spinning up dnsmasq on interfaces, why aren't they creating rules to allow access to it? | 14:03:51 |
| mkg20001 | the problem is that in nftables an accept in one table doesn't mean the package is accepted, only that it will go to the next chain with lower priority, i think | 14:04:43 |
| mkg20001 | that's why all the incus rules have policy accept set | 14:05:21 |
| adamcstephens | yeah i think that's right | 14:05:26 |
| adamcstephens | In reply to @mkg20001:mkg20001.io
incus could support an INTERFACE_UP_HOOK / INTERFACE_DOWN_HOOK where the host os could supply the command to open the firewall for the interface, there we could use something like nft add element inet nixos-fw trustedintfs { $INTERFACE } does this hook already exist? | 14:06:36 |
| mkg20001 | no. it would need to be added to incus. | 14:06:54 |
| adamcstephens | maybe that's the first step then. without a hook there's not a great dynamic way for us to handle networks coming and going | 14:08:16 |
| adamcstephens | also it should be flexible enough to know when dhcp is enabled on a network, because if not then we likely don't need this firewall rule | 14:11:43 |
| mkg20001 | we still need to allow forward traffic and in such a way that only incus interfaces are allowed. which trustedInterface also handles. | 14:17:46 |
| mkg20001 | so we'll need it always | 14:17:52 |
| adamcstephens | trusted interface isn't setting a forwarding rule on my laptop | 14:22:50 |
| adamcstephens | it's only creating an input rule
chain input {
type filter hook input priority filter; policy drop;
iifname { "lo", "incusbr0" } accept comment "trusted interfaces"
| 14:23:23 |
| adamcstephens | forwarding is handled separately, in the other table i included aboe | 14:23:57 |
| mkg20001 | you need networking.firewall.filterForward = true; | 14:27:21 |
| adamcstephens | https://github.com/NixOS/nixpkgs/blob/3551c607f454ee855e54db5686464c8dcf83ceae/nixos/modules/services/networking/firewall-nftables.nix#L92 | 14:27:50 |
| mkg20001 | ah wait, yes, i had it added manually. thought filterForward would do that. | 14:28:55 |
| mkg20001 | we could add something that packets with iifname or oifname contained in trustedInterfaces be allowed | 14:29:27 |
| mkg20001 | * we could add something that packets with iifname and/or oifname contained in trustedInterfaces be allowed | 14:29:33 |
| adamcstephens | i've not used filterForward myself | 14:29:36 |
| adamcstephens | i'd honestly rather not get too tricky with this. i think the goals should be a working out of box experience for those who are taking a simple/default setup, without making assumptions that will affect those who have more complex/advanced needs. | 14:32:30 |
| adamcstephens | or we just solve this with documentation | 14:34:10 |
