local.m4: Boundary network addresses can legitimately transit the VPN.

This is IPv6-specific.  Suppose an internal host on one end of a VPN
connection sends a packet to a host on the boundary network at the
other end.  This packet will go via the public Internet -- fine.  But
the other end will reply, and route the packet through the VPN because
it's an internal address.  So we should allow it or we break
connectivity.

The right answer is probably to arrange for the routing to be
symmetrical, either by forcing the original packet to go through the
VPN or the reply to go around it, but both of these would seem to
involve messing with policy routing in a complicated way.  The current
situation seems weird but not especially harmful.

diff --git a/local.m4 b/local.m4
index ab8249f..da26a37 100644 (file)
--- a/local.m4
+++ b/local.m4
@@ -143,7 +143,6 @@ defnet househub virtual
        via housebdry dmz unsafe safe untrusted
 defnet housebdry virtual
        via househub hub
-       noxit dmz
 
 ## House hosts.
 defhost radius
@@ -199,7 +198,6 @@ defnet colohub virtual
        via colobdry jump colo
 defnet colobdry virtual
        via colohub hub
-       noxit jump
 defnet iodine untrusted
        addr 172.29.198.128/28
        via colohub
@@ -246,6 +244,7 @@ defnet vpn safe
        host crybaby 1 ::1:1
        host terror 2 ::2:1
        host orange 3 ::3:1
+       host haze 4 ::4:1
 defnet anycast trusted
        addr 172.29.199.224/27 2001:ba8:1d9:0::/64
        via dmz unsafe safe untrusted jump colo vpn