Alex's blog

Reconfiguring our home network, part 1

Published on

We embarked on a project to rebuild our home network today; here's what's happened so far.

The person responsible has resisted a rebuild for a while, though it's been necessary, because they wanted to see if fast satellite (the new kind, like OneWeb and Starlink) would become viable; they've now decided it's not going to happen soon. So, we bought three new pieces of hardware: A generic 5-port switch, a generic 2-port gigabit DOCSIS 3.1 cable modem (the second port is unnecessary, but it's what they had), and a fancy Wi-Fi access point I had good experiences with at work. It's designed for commercial deployments, with SNMP, RADIUS/WPA-Enterprise, the ability to configure a whole bunch of SSIDs, and all the rest; it's not a router, just an access point. We don't need all of this, but we decided to go with it because I already know it can cover the area and get good performance.

I set everything up without touching the existing network at first, leaving the existing leased modem-router-AP in place and just moving my machines over so I could make sure they would be stable on the new network. I also turned off the radios on the new AP before I configured the SSID so it wouldn't disrupt the existing network. After a bit of troubleshooting, I was reasonably confident the new setup should work, so I unplugged the ISP box and moved the cable line to the new modem.

Unfortunately, it didn't work; I couldn't get a DHCP address and I couldn't talk to the Internet. My main suspicion is that the ISP will only talk to a machine with a fixed MAC address, so we'll need to call them and set that up. So, I left the new AP's radios turned off and turned the ISP box back on.

Additionally to that, I made a rather interesting discovery: The new modem appears to only act as a DHCP server while the WAN link is disconnected; once the WAN comes up, it drops out. I suspect this is for troubleshooting; if your WAN link goes down and you rely on the ISP to provide your single machine with its IP address via DHCP, you wouldn't be able to talk to the modem to troubleshoot, so it gives you an address in the same block as its Web server. Annoyingly, there is no way to disable this behavior, so it will become a rogue DHCP server automatically in the event that the WAN link dies and you do have a proper DHCP server on the network. Or maybe that's why it waits so long to send offers...

So we'll need a DHCP server, and probably a router; the modem doesn't seem to have any NAT settings, so the packets need to go through somebody else first to do NAT if we don't want to give every machine on the network a public IPv4 address (which I doubt the ISP would be up for)... I think hestia (the server that also runs my Web site, my LDAP directory, my Git hosting, my personal file sharing, and hopefully someday my mail and certain other things) can take up that role.

My hope is that it can be set up like this:

ISP <-> Modem <-> Ethernet switch <-> hestia

Where hestia gets either a DHCP lease or static assignment of a public address from the ISP as well as being 192.168.0.1, and NATs IPv4 for everyone else.

I don't actually know much about how a DOCSIS CPE is supposed to work, but I know that at work, where we have a similar modem and the same ISP, the firewall, and not the modem, has the public IP address the rest of the world sees; it's connected to the modem by an Ethernet cable. I presume this means either that the ISP can see the Ethernet traffic on the other end of the modem (a little (a lot) spooky and probably inefficient) and can answer DHCP requests or that anybody with the globally-routable address assigned statically will just be able to send IP packets over Ethernet to a static gateway address. Hopefully, a switch in the middle won't cause any trouble.

I'm also hoping IPv6 (once enabled on the ISP side, they say they support it but the modem reported IPv4-only address provisioning) won't need anything special?

Read the conclusion in .

Tagged: