Files
vanlink/ap/nftables.conf
T
Andreas WredeandClaude Fable 5 c40662361f ha: move the Home Assistant VM onto the Pi as an aarch64 guest
The x86 ha_van stayed behind on wayback at the port (9bf1420 dropped
ha/ and its DNAT/lease); with the hub moved and the Pi owning
10.42.0.0/24, HA follows. New domain XML: machine=virt + AAVMF EFI,
virtio-scsi HAOS 18.1 aarch64 image, 2 GiB (data restored from an HA
full backup — the x86 qcow2 can't cross architectures). Same MAC, so
the dnsmasq pin (10.42.0.50 / "homeassistant") and the legacy
10.42.0.1:8123 DNAT + br0 hairpin port back verbatim.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-06 19:19:56 -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
}
}