Migrate Interface References in Config
-
We're in a situation where we need to migrate our pfSense config from one machine to another. To explain the issue, here's some background...
We have an HA setup and use VLANs for all of our internal networks. Under normal conditions, we require only three network interfaces per firewall (WAN, pfSync, and one for internal VLANs). A while back, we were transitioning from one ISP to another, so we were using four ports. That whole transition went well, but we were left with the original "WAN" interface being renamed to "WAN2" and being disabled, and the new ISP being plugged into an OPT3 port named "WAN."
This has been fine until now, as we're moving to a machine that has only three ports, so we can't assign the original WAN ("WAN2") to an unused interface on the machine. How might we modify the configuration so that all references to OPT3 ("WAN") are changed to the WAN ("WAN2") interface? This could include trading them, or just moving and forgetting about OPT3. We're open to any sort of idea that doesn't damage hardware at this point; we have the new machine ready with a fresh install of pfSense, and it's not in production, so we can play around with it as needed.
One thought that came to mind was to trade the names on our secondary HA firewall and force a config sync from the current primary (it seems like the config sync is based on interface names), delete OPT3 from the secondary (thereby removing "WAN2"), setup all the interfaces with the appropriate names on the new primary, then setup pfSync on the secondary to push the configuration to the new primary. It seems like this would work for the firewall rules at least, which would be the biggest hassle. I don't now how well this would work for Floating Rules, DHCP relay, or packages that reference specific network interfaces (basically anything that uses the multi-select list of interfaces).
I've also thought about manually editing the config file, but I feel like the changes would cascade quite a bit... I don't know that for sure, though.
Thoughts and ideas from anyone?
-
Why not migrate to something with enough interfaces?
I would get your configuration on the existing hardware working with only three interfaces, then migrate that configuration.
All you generally have to do when you edit a configuration for new hardware is change the interface names.
This are generally only in three places. The interface assignments, VLAN assignment to parent interfaces, and configuration of any laggs.
You just need to change the physical interface names (like re1 to igb2 or em3.100 to igb2.100). All of the rules, dhcp servers, etc will follow.
-
Why not migrate to something with enough interfaces?
It's a long, frustrating story.
I would get your configuration on the existing hardware working with only three interfaces, then migrate that configuration.
That's kind of along the lines of what I was thinking, hence the ideas about using the XMLRPC sync or the manual config file edit.
All you generally have to do when you edit a configuration for new hardware is change the interface names.
This is generally only in three places. The interface assignments, VLAN assignment to parent interfaces, and configuration of any laggs.
You just need to change the physical interface names (like re1 to igb2 or em3.100 to igb2.100). All of the rules, dhcp servers, etc will follow.
Sorry, I don't think I explained the issue well enough the first time. Also, for the record, it seems like you're referencing the "Network port" instead of the "Interface" in pfSense?
From my understanding, there are basically three 'classes' of Interfaces in pfSense: WAN, LAN, and OPT*. Each Interface can be given a name, which, by default, is the Interface ID (LAN, OPT2, etc.). Firewall rules, DHCP relay listening interface selections, etc. are attached to the Interface, not the Network port. I could trade network port assignments between interfaces fairly easy, but that wouldn't fix my issue. Here's a summary of the tasks to accomplish:
- Remove everything attached to the WAN interface (probably just old firewall rules at this point)
- Take everything attached to an OPT interface, and move it to the WAN interface
- Move the OPT interfaces after the one from step 2 'down the line' (if OPT3 is the one used in step 2, everything attached to OPT4 gets moved to OPT3, OPT5 to OPT4, etc.)
In my mind, it seems like I could use the XMLRPC sync method I described in my original post, since that would be based mostly, if not completely, on Interface name and not Network port or Interface ID. I'm suspicious that some settings are based on Interface ID instead of Interface name, but those are easy-to-fix things like the DHCP relay, or 3rd-party package settings.
-
@calebh Don't XMLRPC sync. Just save the config, edit it, and change the physical names (network ports if you like) to the new names, then restore on the new hardware.
That's assuming the automatic interface reassignment doesn't work.
-
@derelict The issue isn't about assigning Interfaces to Network ports, it's about moving everything from one Interface to another (in this case, OPT3 to WAN). Firewall rules, etc. are connected to the Interface, not the Network port, so changing the physical names/network ports won't do anything, because OPT3 firewall rules will still be tied to the OPT3 Interface after such a change.
Nevertheless, I still took the route of manually changing the exported config file.
For those who might need to do the same, below are the steps I took. I used Notepad++ to edit the file, but any text editor that supports find-and-replace using RegEx's will do.
PLEASE NOTE: This is NOT full-proof! We don't use every single feature of pfSense, especially when you bring packages into the mix. This should take care of the majority of settings, but use these directions at your own risk! I highly recommend doing one replacement at a time so you can make sure you're not changing anything you don't want to (e.g. some certificate data will contain the few characters used in a simple search).
-
Remove any NAT or firewall rules on the original WAN interface:
Do a RegEx search for<rule>.*?(?:\n\r?.*?){0,10}<interface>wan<\/interface>[\s\S]*?<\/rule>
and replace it with a blank value -
Remove NAT/firewall rule separators for the original WAN interface:
Find the<wan>
tag inside the<separator>
tag and delete it (including its contents) -
Remove the
wan
interface definition -
Change all references from the current WAN interface (i.e. OPT3 for us) to the original WAN interface:
Replaceopt3
withwan
-
For each succeeding OPT interface, decrement the number:
Replaceopt4
withopt3
, thenopt5
withopt4
, thenopt6
withopt5
, and so on until you've applied the changes to the remaining interfaces (NOTE: for any references that include multiple interfaces -- like floating rules -- make sure to removeopt3
ifwan
is already in the list. But ifwan
is not already in the list, do the normal replacement.)
I was able to successfully restore my manually-update config file on the new hardware, and it has been running in production for almost 24 hours now. I hope this will assist someone else searching for a solution to such an obscure problem!
EDIT: I was wrong in assuming settings were synced by Interface name! The are actually synced by Interface ID. So on the secondary firewall, the only changes you need to make in the config file are steps 3 through 5 for ONLY the interface definitions. (It won't hurt to make the changes elsewhere because the primary firewall will overwrite it anyway, but it's important to note that you need to update the interface definitions.)
-
-
This post is deleted! -
@calebh said in Migrate Interface References in Config:
How might we modify the configuration so that all references to OPT3 ("WAN") are changed to the WAN ("WAN2") interface?
I'm not sure if this works with a HA setup, never used one.
What has worked for me in the past is:- backup config.xml
- use a texteditor like notepad++ (win) or textwrangler (macOS) to find/replace all original "WAN" with "OPTx"
- find/replace all "OPT3" with "WAN"
- check again
- restore config to your machine
I've done this in the past. Works well - at least with a stand-alone unit.
-
@jahonix See my post with the steps we took. We did essentially what you did, but we also removed any references to the
wan
interface before we did the find-and-replace. Perhaps the cycling of OPT* interfaces was unnecessary, but it help us with consistent organization (since we have almost 2 dozen interfaces, organization is essential).