isolate wifi network #20
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As the wifi network is used by various guests at the lab (and most other machines are connected by wired Ethernet), it makes sense to isolate it from the LAN and only provide internet access.
Linux requires ipv4 forwarding to be enabled for NAT to work, so it currently happily routes packets between the WiFi and LAN even though they are on different interfaces and IP ranges.
This does not work for some reason (the rule is visible in
iptables -L
but has no effect):Note that the use of
extraCommands
would require aextraStopCommands
counterpart, otherwise the rules accumulate every timenixos-rebuild switch
is run.Are there really no other rules in the FORWARD chain? Could you please provide
iptables -S
output, or eveniptables-save
with all the tables?BTW, your approach is blacklisting. I recommend
-P FORWARD DROP
and then allowing internet access to LAN and WiFi. You'll notice that you need to update rules if for example your interfaces names change.Put the rules in a user-defined chain that you can delete/recreate at once. Flush the
FORWARD
chain before appending a-j
rule to that user-defined chain. Precaution must be taken when adding extra rules in the future.Alternatively, drop the nixos-fw and use
iptables-save
/iptables-restore
, or even more modern: switch to nftables (still on my list).(Out of desperation, I had tried both
-A FORWARD
and-I FORWARD
, which is why the rule appears twice)We do use the nixos-fw and I would rather just have a quick and simple solution right now. And this says that nixos-fw isn't meant to affect packet forwarding: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/networking/firewall.nix#L329-L330
AFAIK we are not using the virbr networking and we can (should?) disable it completely.
If you really want virtd without the network, I found this:
Otherwise:
You don't need libvirtd for just qemu/kvm/vbox. In fact, they're easier use without libvirt. :)
I can reproduce your rules and they do match here.
More to look into: raw and nat tables,
-j LOG
Hmm, OK. I remembered QEMU+KVM wouldn't work unless libvirtd was enabled, but after checking again, this isn't the case.
Okay, so what is happening is that while access to the LAN 192.168.1.x with x > 1 gets indeed blocked from Wi-Fi, access to 192.168.1.1 (which is the IP address of the LAN interface on nixbld) is not.
This also happens with -P DROP.
For some reason this also does not work:
dd490121b6
took care of this.Nice that it seems to work but test thoroughly because
networking.firewall.trustedInterfaces
affects only INPUT, not FORWARD.Yes, it turns out that network A -> router -> router's address on network B goes through INPUT and not through FORWARD. This is what initially got me confused. And #20 (comment) is because the firewall rules on INPUT were matched first.