Pete's Log: Home networking update
Entry #1887, (Coding, Hacking, & CS stuff)(posted when I was 42 years old.)
I'm not really sure what I'm doing, but I'm having fun doing it. Here's what's changed since last time.
- I bought a dedicated domain for the home network (using the .house TLD) instead of using an esgeroth.org subdomain. I'm quite pleased with this decision.
- Got dynamic DNS working properly for my new house domain
- Got LetsEncrypt working for my new house domain (more on that below)
- Consolidated the datacenter and IoT VLANs into a single VLAN that I'm calling HA - I don't let any of my IoT devices talk to the internet, so that VLAN was misnamed anyway — it's more like LoT (LAN of Things). And I figured there was a lot of traffic between those two VLANs that didn't need to be bothering the router. There are now a number of device-specific firewall rules to allow the raspberry pis some internet access, but I'm OK with that.
- Set up NTP on the firewall and created redirect rules for any device on the HA network trying to access an NTP server to send that traffic to the NTP server on the firewall instead. I was actually able to configure NTP on most of my devices, but the Philips Hue as far as I can tell is hardcoded to use Google time servers. Well, now my firewall just pretends to be those time servers. Stay off the internet, IoT devices!
- Added another outdoor camera to the garage network, this one covering the driveway and back of the house.
- The NAS has two network interfaces. Previously I had set them up in a link aggregation configuration in the datacenter VLAN. I've since changed it such that one interface is in the HA VLAN and one interface is in the clients VLAN. This way my cameras can save video directly to the NAS without bothering the firewall and clients can also access the NAS without bothering the firewall. It seems to make sense to me and it's working so far.
I'm still pleased that my firewall, NAS and Home Assistant all support LetsEncrypt certificates. The configuration of having incoming port 80/443 traffic get forwarded to my reverse proxy raspberry pi seems to be working well. So far, port 80 traffic gets proxy-passed to the three LetsEncrypt clients, provided the request matches one of their hostnames and the request path matches a LetsEncrypt verification. Any other requests currently get served up with a dummy page.
I am thinking of potentially exposing a few more web services to the internet. But I only want to do so via HTTPS. The reason I opted for my reverse proxy configuration for LetsEncrypt was that I didn't want to deal with any hassle of shuffling private keys around. I wanted those clients to keep their private keys to themselves.
But if I'm going to properly use the reverse proxy for HTTPS, then it's going to need to have certificates for the relevant hostnames. But I didn't want to be shuffling private keys around. So my current approach is to have the reverse proxy use RFC2136 to create a wildcard certificate for my house domain. So it has its own private key and can handle traffic for all hostnames. There's probably better solutions out there, but this seems to make sense. The reverse proxy has a dedicated TSIG key that is only allowed to make TXT updates to the _acme-challenge DNS entry, so that's at least somewhat locked down.
Still lots more I want to do, one nap at a time.