Im in the process of building a new pfSense box and looking for a little guidance on how best to approach building (manually) a production-like instance, including with the same interface naming and configuration.
As Im doing the build/config by hand (rather than just doing a config import) I need the new box to coexist with production. I’ve scanned the Netgate guides and the forum and no issues with putting the WAN behind a production LAN port, but the first few attempts failed when I started building out the interfaces and quickly lost the ability to connect to the WebUI when I started enabling the interfaces (assume I created some sort of conflict).
Anyone seen a good guide or got any experience with this sort of situation?
Using the production LAN as the WAN for the new setup on its own is fine, but you can never have overlapping subnets on the router. So if the production LAN you plugged it into is 192.168.1.0/24, you can’t use 192.168.1.0/24 on any LAN interface on the new router.
I recommend adding a new network to the production router solely for the purpose of being the new router’s WAN connection. That way all the production LAN networks can be created on it without overlap.
Thanks @brwainer that makes sense to me. I take it that the networks dont actually have to be assigned to an active interface to cause the conflict (my experience was that not long after I created duplicate networks on unassigned interfaces, things began to crash).
Is it your experience/view that doing a ‘by hand’ build for a replacement (as opposed to doing a config import) is going to be problematic? I ask because it seems to me that maybe by doing it the way I am, Im going to run into a problem when I get to cutover, because Ill need duplicate networks (and particularly static IP assignments) to coexist for the moments where I cut from old server to new server?
I’m not intimately familiar with the internals of PFSense, what really matters is whether the subnets are added to the routing table while unassigned or not. I assume since you had issues that the subnets were being added to the routing table.
There are pros and cons to both rebuilding the firewall and restoring a backup of the existing. Either way, once you believe the new firewall is fully configured and ready, do not attempt to “one by one” move things over. Declare a maintenance window and move it all within an hour, and don’t worry about things being up until it is all moved. Reserve time in the maintenance window for troubleshooting/fixes on the new firewall, and a decision time and criteria for whether to stay on the new firewall or move everything back.