finish blogpost

content/post/2025-12-05-networking-overkill.markdown

@@ -1,6 +1,6 @@
 ---
 categories: homelab
-date: "2025-12-02T21:18:00Z"
+date: "2025-12-05T11:25:00+01:00"
 title: Stuff I've spent entirely too much time on during the last 2 weeks
 ---
 
@@ -36,15 +36,13 @@ However, I didn't want to rely on a third-party service for no otherwise good re
 What's left was OpenVPN, so I chose that
 
 ### 1.3: Selecting OS
-"Shouldn't that say 'Selecting Distro'" I might hear you say.
+"Wait a minute Jonas, why are you saying 'selecting OS' instead of 'selecting distro', aren't you gonna use Linux?"
+Well, Linux is certainly one option - but not the only one :)
 
-No, because I chose FreeBSD.
+In my mind I had two options - either Linux with a very boring distribution such as debian, or one of the BSDs.
+Of the widely used BSDs (FreeBSD, OpenBSD, NetBSD), FreeBSD is the most widely used one, [at least if you trust a graph from 2005 that is linked in Wikipedia](https://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems#/media/File:Bsd_distributions_usage.svg).
 
-Why?
-
-¯\_(ツ)_/¯
-
-TODO delete this section?
+I ended up choosing FreeBSD, as it's reported to have a great network stack, and that's really all I need from a VPN server.
 
 ### 1.4: Setting everything up
 OpenVPN didn't seem too difficult to set up (:clueless:).
@@ -65,7 +63,7 @@ topology subnet
 server 10.214.1.0 255.255.255.0
 ```
 
-Some extra security I enabled here was `tls-auth`: it adds a HMAC signature to all TLS handshakes where I thought "why not".
+Some extra security I enabled here was `tls-auth`: it adds a HMAC signature to all TLS handshakes which sounds good as it can immediately close connections that don't know that secret.
 
 `topology subnet` is the recommended config: what it means roughly is that it selects an IP for every client from the IP range given in the `server` directive.
 It's not supposed to overlap with the IP addresses given out by your ISP router, as that will lead to conflicts.
@@ -85,14 +83,14 @@ The router saw that packet, inspected it, saw that it can't be sent back to the
 The easy solution was to enable NAT on the VPN host, such that it would rewrite IPs from the `10.214.1.0/24` range to its own IP in the `192.168.1.0/24` subnet, and store port mappings such that it could correctly route traffic back.
 
 ## 1.6: Performance
-Everything so far is connected up with 1Gb/s ethernet cables.
-I was certain speed would be limited by those.
+Everything so far is connected up with 1Gb/s ethernet links.
+I was certain that the speed would be limited by those.
 
 Turns out: I was wrong.
 With the current setup (NAT enabled on the VPN host), I got a throughput of about 12 Mb/s - ouch.
 Disabling NAT again just for a speedtest, I got to about 25 Mb/s.
 
-Ideally I'd get about 400-500 Mb/s, as that is roughly the internet speed available, and since the VPN traffic uses the cables between VPN gateway and router twice.
+Ideally I'd get about 400-500 Mb/s, as that is roughly the available speed the ISP router gives me, and since the VPN traffic uses the cables between VPN gateway and router twice.
 
 ## 1.7: Split that Tunnel
 Being presented with those bad speeds, a thought crossed my mind: Ideally I don't pipe the entirety of my laptop's internet traffic through the VPN, but only the traffic to communicate with my homelab.
@@ -102,6 +100,8 @@ The idea is simple: declare a list of IP subnets that should go through the tunn
 
 ![OpenVPN setting: split tunneling](/static/split-tunneling.png)
 
+Important: select "Ignore automatically obtained routes".
+
 ## 1.8: Getting rid of the NAT by adding a NAT
 So it turns out that it's possible to not need to use NAT on the VPN server itself.
 How? By telling the router that traffic that goes to the VPN-client-subnet goes via the private IP of the VPN server.
@@ -119,7 +119,7 @@ protocols {
                 description "vpn-1 clients"
             }
         }
-	}
+    }
 }
 ```
 
@@ -144,18 +144,19 @@ It has an extensive sample config file (with lots of explanatory comments), and
 my config file ended up not too long:
 ```
 server:
-	verbosity: 0
-	num-threads: 1
-	interface: 0.0.0.0
-	so-sndbuf: 1m
-	cache-max-negative-ttl: 60
-	do-ip4: yes
-	do-udp: yes
-	do-tcp: yes
-	access-control: 0.0.0.0/0 allow
-	root-hints: "/usr/local/etc/unbound/root.hints"
-	hide-identity: yes
-	hide-version: yes
+    verbosity: 0
+    num-threads: 1
+    interface: 0.0.0.0
+    so-sndbuf: 1m
+    cache-max-negative-ttl: 60
+    do-ip4: yes
+    do-udp: yes
+    do-tcp: yes
+    access-control: 0.0.0.0/0 allow
+    root-hints: "/usr/local/etc/unbound/root.hints"
+    interface-automatic: yes
+    hide-identity: yes
+    hide-version: yes
 
     local-zone: "jnsmr.ch." static
     local-data: "jnsmr.ch. IN A 10.214.0.20"
@@ -167,7 +168,10 @@ server:
     local-data: "vpn-gate-1.jnsmr.ch. IN A 10.214.1.1"
 ```
 
-The only technical interesting thing here is the `root-hints`: it essentially tells unbound at what IP addresses the root name servers can be found.
+The most important line here for me was `interface-automatic: yes` - since the DNS server has two IPs available (the normal IP `10.214.0.11` and the gateway IP of the VPN client subnet `10.214.1.1`) it is important that it responds from the IP address a request was sent to.
+If you don't enable that, as I found out, clients never accept DNS responses which looks roughly like this:
+
+![DNS IP Confusion](/static/dns-ip-confusion.png)
 
 ### 2.3 Configuring the client
 As for using this nameserver specifically when being connected to the VPN, OpenVPN of course has an answer - you can specify additional nameservers while connected to the VPN:
@@ -184,7 +188,7 @@ Firefox nowadays defaults to DNS-over-HTTPS and completely circumvents the local
 After disabling that though, it even works there :)
 
 ## Chapter 3: Setting everything up again
-As maybe hinted on by the previous screenshot, there's another DNS server.
+As maybe hinted on by the previous screenshots, there's another DNS server.
 I've set up another device with a similar software stack for redundancy - OpenVPN, Unbound, and *Debian*.
 I figured if I'm gonna do redundancy I should also look that the two machines don't die at the same time because of broken package updates or something of the sort.
 
@@ -196,13 +200,21 @@ However, I'll probably stick to making the second VPN server the primary one, si
 
 So what does my overcomplicated set-up even look like now?
 
+The beautiful diagram version looks like this:
+
 ```
 ISP Router
   |
  rou-1
 | | | |
-| | | +- vpn-1 = dns-1
-| | +--- vpn-2 = dns-2
-| +----- the server
-+------- NAS
+| | | \- vpn-1 = dns-1
+| | \--- vpn-2 = dns-2
+| \----- the server
+\------- NAS
 ```
+
+The not-so-beautiful not-diagram version looks like this:
+
+<img src="/static/homelab-setup.jpg" alt="Homelab-Hardware" width=50%>
+
+I might write a bit about my ansible setup at some point (how I don't go crazy with having configuration on 5 devices), but this blog post already took long enough to write.

hugo.toml

@@ -1,6 +1,7 @@
 theme = 'm10c'
 baseURL = 'https://log.x77.dev'
 title = "Jonas' Ramblings"
+staticDir = ['static']
 
 
 [outputFormats.RSS]
@@ -33,3 +34,8 @@ baseName = "feed"
     name = "About"
     url = "/about/"
     weight = 4
+
+[markup]
+  [markup.goldmark]
+    [markup.goldmark.renderer]
+      unsafe = true