December 28, 2017

Over-engineering 101: Pimping your home network

Doesn’t it seem bizarre that in a world where home-offices are commonplace, and the concept of remote working is considered quite normal, that we don’t pay more attention to the infrastructure of our home network?

No? That’s fine, maybe I just wanted an excuse to do something cool over Christmas.


I had a few days spare, and I wanted to iron out a few frustrations that I’ve been having lately. Specifically, I wanted to be able to:

  1. Run containerised services internal to my home network via my Raspberry Pi cluster;
  2. Provide access to my home network, and devices, externally via a VPN;
  3. Provide consistent connection capabilities to external locations (i.e offices, or data centers) via VPN;
  4. Provide a centralised logging repository, allowing me to troubleshoot issues from one place;
  5. Introduce a layer of privacy at the network level via DNS blackholing of tracking domains.

Nothing too special, and - apart from the inbound VPN capabilities (perfect for those afternoons spent on untrustworthy WiFi networks, courtesy of your favourite coffee shop!) - things that are all pretty easy to solve via software configurations.

Although, does your clever software configuration lead to a cool network diagram like this?


With that (rather rough and simplistic) diagram jotted down in my diary over lunch one afternoon, I set about making it happen.

Putting it together

If there’s one thing that frustrates me, it’s messy cables. With this in mind, I decided to house everything - the RPi Cluster, the RPi Gateway, and the NAS - in one central location. This meant I’d need a new network switch, as I’d outgrow the 5 port one used by the RPi Cluster.

I initially considered purchasing a pair of Powerline adapters, and housing everything in my desk drawer; nice and neat and tidy.

Alas, I ultimately opted against this as I’d like to experiment a little bit with an old RTL-SDR adapter I have laying around, and Powerline is known to cause some radio interference issues.

After 30 minutes of moving stuff around, plugging in a few cables, and liberally applying cable-ties, I was ready to start with the configuration.

The Router

I have a bog-standard ISP-provided consumer router; nothing sexy or special. The only configuration required was:

  1. Setting up static IP addresses for the NAS, RPi Cluster Nodes, and RPi Gateway;
  2. Allowing port forwarding for inbound VPN access, directed towards the NAS (See the next section);
  3. Logs to be sent to the NAS via Syslog.



I regularly switch Linux distros, and in 2017 alone I think I tried various iterations of Arch, Ubuntu and Fedora. Needless to say, I’ve been considering moving as much of my data as possible to the NAS (in combination with a LUKS encrypted USB drive) and even thought about making better use of containerised desktop applications. (The security implications of this done properly are pretty brilliant too.)

Synology builds some brilliant NAS devices, ones that are capable of all kinds of cool things via their operating system. The thriving ecosystem of packages allows you to run everything you could possibly want; but all I wanted my NAS to do was:

  1. Provide network shares for my data, and my home media;
  2. Provide a network share via NFS for my RPi Cluster containers;
  3. Provide a centralised logging repository via syslog;
  4. Provide inbound VPN capabilities.

This was easy enough to do, with the last two aims being completed via two Synology packages; Log Center and VPNCenter.

RPi Cluster

I’ve already documented my 4x Node Raspberry Pi Cluster, which runs Docker in Swarm mode and can be managed via Portainer. At the moment there isn’t a huge deal going on there, other than acting as a personal QA environment.

Rather satisfyingly, this part of the puzzle required zero changes.

The RPi Gateway

This was arguably the biggest task, and is (a) undoubtedly still a work in progress, and (b) the inspiration behind beginning work on Commander. The main objectives are:

  1. To maintain a consistent VPN connection with an external host;
  2. To provide a Wireless Access Point (complete with dhcp capabilities);
  3. To route all traffic (including client traffic) via the VPN connection;
  4. To maintain a DNS blacklist for blocking advertisers and trackers.

The VPN gateway aspect is quite well documented already, and there are a few guides about developing a “Router On a Stick” with the Raspberry Pi. This primarily comes down to opening a VPN connection, and using iptables rules to enforce outbound traffic to leave via this connection.,

Similarly, there’s numerous guides on how to run a WiFi Access Point (AP) via hostapd and dnsmasq. This really isn’t hard to do.

For the privacy and adblocking capabilities, I’m currently looking at installing something like privoxy, and utilising something like pihole for the DNS blocking.

When this is done, I can also set the primary router to direct clients to the RPi Gateway for DNS look-ups; so even devices that don’t require the VPN tunnel will benefit from the enhanced privacy. (Although, this will likely have the side effect of pushing all DNS requests through the VPN still.)

Ultimately, as this part of the stack matures - and as I find more time to work on Commander, I hope to have a primitive gateway package - complete with nice web UI - and a bunch of installation scripts (via Ansible).


This was quite a fun couple of hours, and although the introduction was firmly tongue-in-cheek, it has provided a decent amount of resiliance to working remotely; making secure connections easier, enforcing back-up hygiene and discipline, providing access to those backups from other locations and more.

The next steps will be hard drive redundancy - in the form of RAID on the NAS - and some further tweaking of off-site back-ups (i.e Dropbox, Google Cloud) for personal files.

© Fergus In London 2019

Powered by Hugo & Kiss. Source available on Github.