Records the networking decision behind Phase 6b's arrival notifications so it
doesn't get re-derived later.
ntfy stays LAN-only: identity -> ntfy is a container-to-container call that never
reaches OPNsense, and remote delivery rides a WireGuard split tunnel routing only
the smart-home VLAN. No DMZ, no port forward, no certificates, no inter-VLAN rule.
Both alternatives were weighed and rejected, with reasons recorded:
- DMZ + port forward buys only "notifications without the VPN connected," at the
cost of a public listener, TLS upkeep, and mandatory ntfy auth — an exposed
topic leaks "the house is empty right now".
- DMZ + NAT reflection does avoid a new inter-VLAN rule (the smart-home VLAN's
existing outbound-WAN allow already covers traffic to your own public IP), but
makes a purely internal path depend on the ISP and external DNS being up, so
two devices metres apart stop talking during a WAN outage. CGNAT breaks it
outright, and the rule it avoids was the safe direction anyway.
New §2.1 covers the split tunnel itself, including the trap that motivated it:
AllowedIPs must be the actual VLAN prefix, never 192.168.0.0/16, which collides
with typical café/hotel LANs and breaks the phone's connectivity there. Plus
always-on VPN yes / lockdown no, and no DNS= so queries aren't pulled home.
The household uses no Apple devices, which removes the only forcing function for
exposure (ntfy's iOS app needs APNs and therefore an upstream relay). Open
decision #37 closes as a household decision; the Apple case is kept as a
footnote in case that ever changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Amir Alexander Abdelbaki
15e6715469