From: Mark Wooding <mdw@distorted.org.uk>
Date: Tue, 15 Jul 2014 09:50:17 +0000 (+0100)
Subject: local.m4: Boundary network addresses can legitimately transit the VPN.
X-Git-Url: https://git.distorted.org.uk/~mdw/firewall/commitdiff_plain/a28edce0d98fdb75c76edadbd9509d682b7992b0

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
--- 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