I have made this in case I forget or Leena needs someone to help in configuring it. It is expected that once we move to Koh Samui, this network will change pretty dramatically (see the page on Villa Makalena network). Once we move to Villa Makalena we will release the condo and decommission the condo network using its parts to build the Villa Makalena network. This page focuses on the parts of the network that will not change when that move happens.
In any such environment, things will be changing over time. I will do my best to keep this page updated so that it describes the current state, but may occasionally make references to older configurations in case someone who is configuring this network finds older artifacts. In such a case, I would not want someone to go down useless rabbit holes.
The household is between homes, so this wiki describes two networks:
| Network | Status | Pages |
|---|---|---|
| All Seasons Mansion condo | The network we live on today. When we move, it will be decommissioned and its equipment reused at the villa. | Condo Network Overview for how it is set up and maintained, and Condo Network Design for its components, VLANs, IPv6 and known weaknesses |
| Villa Makalena, Koh Samui | Being built now. It becomes the household network after the move. | Villa Makalena Network |
This page covers what the two networks have in common, which will stay true after the move. Each network's own pages cover what is specific to it.
This section lists the key devices used in the home.
This is a placeholder as the fiber modem in effect will change depending upon the network.
This is a placeholder as the Wifi solution will also change dramatically as we move from one location to the other. The condo has a mesh network powered by a Asus ZenWIFI AX mesh. The Villa Makalena network will be powered by TP-Link access points.
The router is also performing DHCP chores, but local DNS is delegated to an instance of Technitium at 192.168.200.53:53. This Technitium instance also provides DNS name resolution for the internal rachelski.internal network that all internally named services now use.
There is a NAS hosted at 192.168.200.155 that used to be pretty much the brains of the house (although losing responsibility for key services over time). It is a Synology DS918+ running DSM operating system. This is a Linux OS with substantial web application support to interface with the NAS. The NAS also exposes an SSH port only inside the house that can be used to gain relatively low-level access to the NAS. Commonly, this is used to deploy Docker applications to the NAS. The name of the NAS is diskstation.rachelski.internal
The following is an overview of the key services provided within this network. This is critical for understanding when doing network troubleshooting.
DNS services are a long story. It all begins with the registrar (namesilo in my case) where I have 3 domains homed: rachelski.net, madbearlabs.com and villathallo.com. Seperately I have a private DNS at rachelski.internal which does not need a registrar (I am he).
Namesilo will then either provide DNS resolution directly (in the case of madbearlabs.com and villathallo.com) or rachelski.net is delegated to a public zone being managed at desec.io. This allows me to configure automation to manage the zone records (such as external-dns running in the cluster) or let's encrypt used by the hetzner cloud server.
Within the home network, at this time, I am running 2 DNS servers: one on a VM on net-1 at 192.168.200.153 and one on a VM on ranch-2 at 192.168.200.53. These addresses are very well known and stable (at least until I start moving things to VLANs). These 2 devices are running Technitium which is a pretty powerful DNS server. These technitium servers are also hosting an internal zone at rachelski.internal that name most homelab services.
At this time, the Technitium servers are also doing the public IP name resolution. I am not using a 3rd party public resolver (such as Quad9, Cloudflare or Google). I used to use Quad9 and would love to do so again as it is privacy focused. The reason I moved away was Technitium by default will use DNSSEC to validate IP addresses from resolvers. Quad9 is already doing its own DNSSEC for zones it is caching, and then resolves DNSSEC validation somewhat poorly for clients. This was causing me issues where DNS would fail intermittantly within the home network. So, long story short: disable DNSSEC validation on Technitium and you can use Quad9 peacefully. But I was still getting enough intermittent failures that I started caching directly in Technitium. I may wish to turn on DNSSEC again. It could be a real PITA since it seems some key services (time.nist.org) do a bad job with DNSSEC and each domain of this type would need separate configuration.
One other important lesson learned is if you use DHCP to point all of the clients directly to the local DNS servers, you can avoid one hop at the router. But this really slows down recovery time when something goes wrong with the DNS resolver chain. I am finding it is a lot more robust to keep all of the devices going back to the router to resolve addresses and let IT get key data from the Technitium duo. In this way, I can bypass the DNS servers if they are causing issues (at the expense of no longer being able to resolved rachelski.internal). One bit of pain is that each OS has its own strange behavior when being offered a list of ip addresses for resolving DNS names. Some will simply use the first, some will round-robin, some will randomly pick one at startup and never switch after that. A real mess. So my lesson is: try to offer DNS to clients on a single IP (1 ipv4 and 1 ipv6).
Lesson Learned: There used to be a DSM application (DNS Server) running on the NAS that is no longer used. It turned out to be a bad idea to host DNS on the NAS since, when the NAS went down the entire network failed to work. This made recovery very difficult. At this point, responsibility for configuring a DNS server that is authoritative on the network belongs to the Asus ZenWIFI. This keeps the blast radius of failure tied to core networking equipment.
This will change depending upon location.
This will change depending upon location
Because I don't want to have my entire network depend upon my NAS, the Caddy server running on the net-1 host also has a DDNS client running on it and is automatically rotating the hostname pub-asm.rachelski.net which is then used as a CNAME target for a lot of my public names.
The synology NAS is also running a DDNS service, dependent upon Synology to resolve to the DNS name mrachelski.synology.me . As AIS changes the household IP address, this service should update the DNS name automatically. I used to run this on the router, but I think there was an issue with the NAS managing Let’sEncrypt certificates that drove me to run this service on the NAS.
Only the NAS's internal proxy depends upon this service.
All of Mark’s personal information he would rather not share with Google is held this way. This includes things like: medical records, tax filings, business documents and similar items.
I run a Caddy reverse proxy within a VM on the net-1 host. See the mention above in the DDNS Services section. This Caddy service is my ONLY device that deals with incomming traffic. My intended design goal is that this Caddy server is the ONLY port forwarded destination in the Asus ZenWifi router and we only port-forward ports 80 (primarily for Let's Encrypt) and 443.
This significantly reduces the complexity and security attack surface for my home network. I have also removed any UPnP services on this router.
See the net-1 gitea repo for configuration of this service.
This section holds information about significant 3rd party or outside hosted services used to run the network.
Mark currently uses namesilo.com as the DNS registrar. At the time of this writing, this service registers the following names:
Mark currently uses the DNS services provided for free at desec.io (credentials in BitWarden). This is actually quite a good service and it holds authority for the rachelski.net DNS zone (desigated by namesilo)
Please see the DNS Server section above for a detailed (and hopefully updated) explanation of the use of any public DNS resolvers.
Prior to this, the household used adguard, and before that, the default DNS servers from AIS.
This service is provided by a pair of Technitium instances running in VMs on the net-1 server and ranch-2 server.
Email services are provided by a combination of Google, Microsoft and Zoho.
Google is used to host 2 accounts: mrachelski@gmail.com, mrvendors@gmail.com. Credentials can be found in BitWarden
Microsoft is used to host: mrachelski@outlook.com
Zoho is used to host mark@rachelski.net along with mark@villathallo.com
For purposes of delivering email from automation, I maintain an account at mailjet.com. The credentials are in my bitwarden vault.
Mark used to run a VPN server in Digital Ocean in the U.S. so that he can mask locations or appear to be browsing from the U.S. This service is configured to be accessed via WireGuard protocols. See BitWarden for credentials to the Digital Ocean console (held under madbearlabs.com)
TODO: this service is scheduled to be decommissioned as I will move these services to the homelab cloud server in Hetzner. The homelab server currently does not offer any VPN relay services as I simply did not use them very often. But that could change in the future.
While Leena has experimented with home automation for as long as I have known her, Mark has typically been resistant to this. The reasons are mostly related to privacy concerns along with a recognition that this could be a very time consuming area of concern. The quote I have heard is: “hundreds of hours of work to save a few seconds in the future”. But you have to admit it is pretty cool.
This section will outline how the home automation works in the Rachelski household.