My New Home - Network

So, we have finally moved into our new home. The buying process took far too long, I am sick to death of dealing with solicitors, but we are now in. I hope this will become a series of blog posts in which I detail the setup process. This particular post will be the network.

My initial intention had been to buy some land and build a house. However, the process of doing so in the UK was … annoying, so instead we went for a new build. We found the property early enough in the build process that we were able to make various requests. One of which was for the electrician to run Cat-6 ethernet cable throughout the house before the walls were plastered. The cables all run into our under-stairs cupboard which I managed to convince my wife to give me as a server room.

The majority of our rooms have 2 ethernet sockets in opposite corners. Our lounge has 4, one in each corner. Our hall and landing both have celling mounted ports for access points. I think this is probably more than we need, but at the time we didn’t know how we’d lay the rooms out, so we put in more than we thought we’d need. I think this was a good choice. Running ethernet is much easier when you don’t have plaster to contend with. And they are just sockets on the walls – they are no uglier than mains, telephone or coax sockets.

Network Gear

In terms of the network gear, I decided to take the plunge and try TP-Links Omada line. I think it is fair to say that in the pro-sumer arena, Ubiquity are the most popular. However, they are also expensive. I watched a lot of YouTube and decided that TP Link’s product catered for my needs.

I bought:

• A Router / firewall (Non-Associates Link)
• A Switch (Non-Associates Link)
• An Access Point (Non-Associates Link)

I won’t go into too much detail on the individual devices I got as copying me is a pretty bad idea. You want to make the decision based on the size of your network, the speeds you need and the sorts of devices you want to attach.

Network Configuration

I run the TP Link Omada Controller in a Docker container on my home server. I have had no issues with it at all so far.

In terms of the software itself, I would say that it’s not quite on a par with Ubiquity’s product, however, it is more than sufficient for my needs and I would think more than sufficient for most home users and small / medium businesses.

The only area I found it to be a little lacking was the firewall configuration. However, before I explain that, it would be helpful for me to explain the VLANs I have on my network. In case you don’t know, a VLAN is a virtual network. It is useful for categorising and segregating devices. I have seen many examples across the internet of people who setup tens of VLANs for their home network. However, I think any security gains you may get from that are outweighed by the added complexity maintaining it. I have opted for two VLANs.

My first VLAN is for trusted devices. Trusted devices are my computers, my wife’s computers, our phones and my server. These are able to communicate with each other and the internet.

My second VLAN is for smart devices. These are devices that have no business talking to each other or the internet. The only device they can communicate with is my server running Home Assistant, an NTP server and a DNS server.

This can all be achieved easily with the Omada software. Where it is lacking is in its inability to set up stateful firewall rules. I would like to configure the firewall so that devices on my trusted network can communicate with devices on the smart VLAN, and the smart devices should be able to reply. Meaning, from my laptop, I cannot SSH into my vacuum because that requires 2 way communication. There is talk on Reddit that future firmware may support this, but at the moment it doesn’t. I have got around this by using my server as a jump box to SSH from as smart devices are able to connect to this, although I’d prefer a stateful firewall solution.

I am also not able to force all DNS requests to my DNS server. On some router / firewall solutions, you can force all outbound traffic on port 53 (DNS) to a particular device. I have to rely on devices honouring the server specified via DHCP. However, they seem to be doing this. They are unable to communicate with any other servers so even if they are only honouring my choices because they have no choice, I don’t really care.

NTP

One of the issues I overlooked when planning my network setup was that of the Network Time Protocol (NTP). I have Chrony running on my server, but many devices don’t allow you to specify an NTP server. Instead, they just silently fail, and leave you scratching your head whilst trying to correlate times in log files. A particularly annoying case of this had a device default to a date in January 2022. Whilst debugging an issue, it was January 2023 and I completely missed the fact that it was a year out for far too long.

It should be possible to configure an NTP server via DHCP. However, the Omada software doesn’t appear to support it. Eventually, I might allow my Pi Hole to manage IP assignment which would allow me to configure the appropriate DHCP options, although that would still be reliant on devices obeying it.

For now, I have pointed the domains I saw being used at my server, which appears to have worked.

Network Connection

Another issue I came across is that some mobile apps for self hosted programs don’t work without an internet connection. I raised an issue for Audiobookshelf. The owner responded quickly and after a few screenshots acknowledged the bug. This is not supposed to be a knock on the app – I have been hugely impressed by the speed of responses I’ve had from the team who work on it. It is instead supposed to highlight the fact that many tools are not tested against the sort of non-standard setup I have here. As a result, I am going to run into issues that I wasn’t expecting.

In the case of Audiobookshelf, it looks like one of its libraries checks for internet connectivity rather than network connectivity. After checking my pihole’s logs, it turns out that Android devices make regular (unencrypted) requests to http://connectivitycheck.gstatic.com. This is used to identify captive portals as well as verify internet connectivity. Fortunately for me, being unencrypted, I can host a simple webserver and point that domain at it on my network. So that’s what I did. The relevant NGINX config is below:

server {
    listen       80;
    listen  [::]:80;

    server_name          connectivitycheck.gstatic.com;

    location / {
            return 204;
    }
}

After this, the app started working as expected.

WPS

WPS is a method of connecting to a network without having to enter a password. It generally involves pushing a button on your access point and a button on your phone / device then “magically” the device is on your network. This method of connection has been shown to have several security weaknesses. Many modern solutions, including Omada and Ubiquiti have stopped providing this as an option.

I approve of this decision, it is something I would have disabled if it had been present. However, my printer has no other way of connecting to the network. No ethernet and no way to enter a password. I think I’ll probably have to dig out an old router that does support WPS and hope that after connecting, the printer will have a web interface that allows me to change the network configuration. If not, I may have to just plug a small SBC into it and run a cups server on that.