diff options
| author |  sommerfeld <sommerfeld@sommerfeld.dev> | 2026-05-13 13:43:41 +0100 |
|---|---|---|
| committer | sommerfeld <sommerfeld@sommerfeld.dev> | 2026-05-13 13:43:41 +0100 |
| commit | fa081c7a7dbe0ab3660f6f6d7860b5a815370c5d (patch) | |
| tree | bb5c26fec71586618fdbaac58cd3e09a99b3db8b /run_onchange_after_deploy-flatpak-overrides.sh.tmpl | |
| parent | 8567dd49e9e688f26dc0b266f211655974539299 (diff) | |
| download | dotfiles-fa081c7a7dbe0ab3660f6f6d7860b5a815370c5d.tar.gz dotfiles-fa081c7a7dbe0ab3660f6f6d7860b5a815370c5d.tar.bz2 dotfiles-fa081c7a7dbe0ab3660f6f6d7860b5a815370c5d.zip | |
fix(nftables): allow DHCP/DNS and forwarding for libvirt virbr0
The host firewall has policy=drop on both input and forward chains.
libvirt creates its own nftables table for virbr0 NAT, but:
1. It does not touch the input chain at all, so DHCP packets from
guests (UDP/67) are dropped before reaching dnsmasq. Result:
Windows guest stuck on 169.254.x APIPA forever.
2. Its forward-chain accepts have the same hook+priority as ours.
In nftables, all chains at a hook+priority must accept (any drop
wins), so our policy=drop would block guest egress and return
traffic even though libvirt's chain explicitly accepts.
Add minimal carve-outs for virbr0: DHCP+DNS in input, guest egress
and return traffic in forward.
Diffstat (limited to 'run_onchange_after_deploy-flatpak-overrides.sh.tmpl')
0 files changed, 0 insertions, 0 deletions