Changing Or Migrating Your Network Backend

There will come a time when you may need to move your networking stack to a different machine due to a variety of reasons. By networking stack, I mean applications core to the functionality of your homelab, such as your DNS server, reverse proxy, Wireguard instance, etc.

I personally had to move thrice

• When I had to change the IP addresses of all my machines due to a weird edge case involving Wireguard
• When my Raspberry Pi was not powerful enough for all my micro-services, and shifted to a physical machine
• When I switched from a physical machine to a Proxmox VM

Every time I switched, there was always something or the other which I missed which affected my operational stability. But like they say, you learn as you make mistakes.

So I have put-up a checklist of things to do before and after the migration

Before migration

1. Timing: Dedicate a time to do your migration. You don’t want to end up in a scenario where you need to get the network up before a deadline or an activity. Urgency causes haste -> haste causes mistakes Determine how much time it will take to do the migration and finish all other chores.
2. Announce: Inform everyone who uses your infrastructure that there will be a downtime.
3. Resources: Acquire an offline version of the required knowledge sources. I know it’s not possible always, but having a few open tab of some tutorials and blogs goes a long way. Simply having your phone with you can be good enough.
4. Backup: Ideally, your network stack should be containerized. So you should have a backup of all your network services and it should be accessible offline.
5. Plan: List out all your services and think how an IP change can affect them. If you are using local DNS entries, the effect should be minimal.

Now we are more prepared to take on this task.

Let us now look at how I migrated. The collection of steps is mainly applicable to my network stack but it may work for you as well.

During migration

1. Reverse proxy: If you are using a reverse proxy, change the mappings in your proxy configuration file. If you are a good sys-admin, you should be using hostnames instead of IP addresses. If you are a great sys-admin, you should be using container hostname and internal ports, you don’t need to change this file at all (More on this in another blog).
2. MAC bindings: If you are changing IP addresses for all your hosts, make this change on your router/DHCP server
3. DNS server IP: This is the biggest hurdle, as a lot of the services depend on it
   • Update the DNS IP in the router, preferable both on the LAN and WAN interfaces
   • Some routers advertise the DNS IP via DHCP, so you should place the DNS IP there as well
   • If you have Wireguard, you may need to update the IP there. For certain settings, you need to manually set the DNS server IP
4. Upstream DNS server: In case you have your own upstream DNS application (cloudflared or adguard/dnsproxy) running as a container, you need to update it in your DNS server application
5. Port forwards: If your IPs have changed, the forwarded ports in your router needs to be updated towards the new IP address.
6. Gateway or router IP: The IP of your gateway needs to be updated last. Once this is saved, you should reboot your gateway server.

Post migration

1. Check if all your services are working; both external and internal DNS resolution. dig comes very handy here. Having a automated test-suite to check if everything is okay would be great (Uptime-kuma would be great)
2. Reboot the devices if the IP/DNS server IP does not change. You can also reboot the router itself.

Once everything is working, you can inform others that the network is up.