Files
vanlink/ap/nftables.conf
T
Andreas WredeandClaude Fable 5 a7819edbc2 ha: bridge the Home Assistant VM onto br0 as a first-class LAN device
The VM lived on libvirt's default NAT net (192.168.122.50) behind a
/etc/libvirt/hooks/network hook that inserted FORWARD accepts above
libvirt's REJECT. libvirtd restarts re-inserted its chains on top
without firing the hook, silently cutting clients off from HA.

Now the VM's NIC (virtio, was e1000) bridges into br0: pinned lease
10.42.0.50 / name 'homeassistant' via van-ap dnsmasq, mDNS discovery
works, and no firewall hook can rot. Legacy http://10.42.0.1:8123
kept working via DNAT + same-subnet hairpin masquerade. Hook, libvirt
DHCP reservation, and iptables rules removed; domain XML in ha/.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-06 09:38:53 -04:00

24 lines
1.2 KiB
Plaintext
Executable File

#!/usr/sbin/nft -f
# van-router NAT — masquerade LAN out whatever the WAN of the moment is
# (anything that is NOT the LAN bridge br0: ethernet/Starlink, wifi, future 4G)
table ip van_router_nat
delete table ip van_router_nat
table ip van_router_nat {
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
# Home Assistant VM (ha_van) is bridged onto br0 at 10.42.0.50 — clients reach
# it directly. Keep the legacy http://10.42.0.1:8123 URL working for anything
# that bookmarked it (phones, ZT clients).
ip daddr 10.42.0.1 tcp dport 8123 dnat to 10.42.0.50:8123
}
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
ip saddr 10.42.0.0/24 oifname != "br0" masquerade
# Hairpin for the legacy 10.42.0.1:8123 DNAT when the client sits on the same
# subnet as the HA VM: without masquerade the VM would reply directly on br0
# from 10.42.0.50 and the client (expecting 10.42.0.1) would drop it. ZT-sourced
# traffic doesn't match and doesn't need it — VM replies route back through us.
ip saddr 10.42.0.0/24 ip daddr 10.42.0.50 tcp dport 8123 oifname "br0" masquerade
}
}