Update on Overleaf.

3_Implementation/Samples/shell/linux_remote_routing.sh

@@ -0,0 +1,12 @@
+# Add a new rule to the local table at a lower priority
+ip rule add from all table local priority 20
+# Delete the existing lowest priority rule (always to the local table)
+ip rule del priority 0
+# Forward SSH traffic to the host
+ip rule add to "$REMOTE_PORTAL_ADDRESS" dport 22 table local priority 1
+# Forward proxy traffic to the host
+ip rule add to "$REMOTE_PORTAL_ADDRESS" dport 4725 table local priority 1
+# Create a new routing table and route for crossing the TUN
+ip route add table 19 to "$REMOTE_PORTAL_ADDRESS" via 172.19.152.3 dev nc0
+# Route all packets not already caught via the TUN
+ip rule add to "$REMOTE_PORTAL_ADDRESS" table 19 priority 19

3_Implementation/implementation.tex

@@ -355,20 +355,7 @@ These instruct the kernel in each case to forward packets. However, more instruc
 \vspace{3mm} \noindent
 Linux:
 
-\begin{minted}{shell-session}
-# Add a new rule to the local table at a lower priority
-ip rule add from all table local priority 20
-# Delete the existing lowest priority rule (always to the local table)
-ip rule del priority 0
-# Forward SSH traffic to the host
-ip rule add to "$REMOTE_PORTAL_ADDRESS" dport 22 table local priority 1
-# Forward proxy traffic to the host
-ip rule add to "$REMOTE_PORTAL_ADDRESS" dport 4725 table local priority 1
-# Create a new routing table and route for crossing the TUN
-ip route add table 19 to "$REMOTE_PORTAL_ADDRESS" via 172.19.152.3 dev nc0
-# Route all packets not already caught via the TUN
-ip rule add to "$REMOTE_PORTAL_ADDRESS" table 19 priority 19
-\end{minted}
+\inputminted{shell-session}{3_Implementation/Samples/shell/linux_remote_routing.sh}
 
 \noindent
 FreeBSD:
@@ -394,21 +381,26 @@ Routing within the local portal expects $1+N$ interfaces: one connected to the c
 Routing the packets from/for the local portal is pleasantly easy. Firstly, enable IP forwarding for Linux or gateway mode for FreeBSD, as seen previously. Secondly, routes must be setup. Fortunately, these routes are far simpler than those for the remote portal. The routing for the local portal client interface is as follows on Linux:
 
 \begin{minted}{shell-session}
+
 ip addr add 192.168.1.1 dev "$CLIENT_INTERFACE"
 ip route add "$REMOTE_PORTAL_ADDR" dev "$CLIENT_INTERFACE"
+
 \end{minted}
 
 \noindent
 Or on FreeBSD:
 
 \begin{minted}{shell-session}
+
 ifconfig "$CLIENT_INTERFACE" 192.168.1.1 netmask 255.255.255.255
 route add "$REMOTE_PORTAL_ADDR" -interface "$CLIENT_INTERFACE"
+
 \end{minted}
 
 Then, on the client device, simply set the IP address statically to the remote portal address, and the gateway to \verb'192.168.1.1'. Now the local portal can send and receive packets to the remote portal, but some further routing rules are needed to ensure that the packets from the proxy reach the remote portal, and that forwarding works correctly. This falls to routing tables and \verb'pf(4)', so for Linux:
 
 \begin{minted}{shell-session}
+
 # The local table has priority, so packets for the proxy will be routed correctly
 # Add a default route via the other node via the tunnel
 ip route add table 20 default via 172.19.152.2 dev nc0
@@ -419,12 +411,14 @@ ip route add table 21 to "$REMOTE_PORTAL_ADDRESS" dev "$CLIENT_INTERFACE"
 # Use this route for packets to the remote portal from the tunnel
 # Note: there must be a higher priority table for proxy packets
 ip rule add to "$REMOTE_PORTAL_ADDRESS" table 21 priority 21
+
 \end{minted}
 
 \noindent
 FreeBSD:
 
 \begin{minted}{shell-session}
+
 # Route packets due to the other node via the WAN interface
 pass out quick on $ext_if to $rp_ip port { 4725 }
 # Else route these packets to the client
@@ -433,6 +427,7 @@ pass out quick on $cl_if to $rp_ip
 pass in quick on $ext_if from $rp_ip port { 4725 }
 # Else route these packets via the tunnel
 pass out quick on $nc_if from $rp_ip
+
 \end{minted}
 
 These rules achieve both the listed criteria, of communicating with the remote portal while also forwarding the packets necessary to the client. The local portal can be extended with more functionality, such as NAT and DHCP. This allows plug and play for the client, while also allowing multiple clients to take advantage of the connection without another router present. 
@@ -449,8 +444,10 @@ Although this may seem like a contrived use case, consider this: a dual WAN rout
 The second issue follows a similar theme of IP addresses being owned by the host and not the interface which has that IP set, as Linux hosts respond to ARP requests for any of their IP addresses on all interfaces by default. This problem is known as ARP flux. Going back to our prior example of \verb'eth0' and \verb'eth1' on the same subnet, ARP flux means that if another host sends packets to \verb'10.10.0.2', they may arrive at either \verb'eth0' or \verb'eth1', and this changes with time. Once again, this is rather contrived, but also means that, for example, a private VPN IP will be responded to from the LAN a computer is on. Although this is desirable in some cases, it continues to seem like surprising default behaviour. The solution to this is also simple, a pair of kernel parameters, set by the following, resolve the issue.
 
 \begin{minted}{shell-session}
+
 sysctl -w net.ipv4.conf.all.arp_announce=1
 sysctl -w net.ipv4.conf.all.arp_ignore=1
+
 \end{minted}
 
 The final discovery I made is that many of these problems can be solved by changing the question. In my real world testing, explained in section \ref{section:real-world-testing}, the local portal lies behind a dual WAN router. This router allows the same port to be accessible via two WAN IPs, and avoids any routing complication as the router itself handles the NAT perfectly. Prior to this I was attempting to route outbound, similar to the situation described above, with some difficulty. Hence it is worth considering whether an architecture modification can make the routing simpler for the task you are trying to achieve.