Is there a guide on how to migrate from pfsense to opnsense?

[inorx]

Hi all

i'm just about to migrate an old pfsense installation with a rather complex and huge configuration which would be days of work to manually migrate.

I did a quick test with pfsense/export - opnsense/import but it failed (it corrupted the opnsense configuration, leaving the software crashing, so i had to reset it).
Also i found that i.e. for Aliases there seems to be no import option under those "parts of configuration restore" dropdown.

I read it might not be expected that the opnsense conf is compatible with the pfsense conf (correct?) and therefore it's adviced to import part after part. I'm wondering if there is something like a best practise guide on how to do this, i.e. order of parts, how do the conf files have to look lioke (pure xml? no header section? ...)? The latter would be helpful in case the import fails, so so reformating could be done manually in a text editor.

Any hint is very welcome.
Thanks for your support guys.

[inorx]

When trying to import parts of the configuration exported from pfsense, this is the error message i get:

[Greelan]

Back a few versions ago the underlying code was similar enough that a direct import was possible. That's not the case now

[inorx]

So what procedure is considered to be the most efficient today?
Is there any information on how to covert the pfsense conf xml to the opnsense json conf?

[Greelan]

Not sure what json you are referring to. OPNsense's primary configuration file is /conf/config.xml

[inorx]

You're right, it's an XML file.
And as you wrote, it's not compatible with the pfsense format.

For someone not involved in the dev process and without a specification of the output format, it does not seem to be possible to write a converter script to automate i.e. rule conversion to opnsense.

So for anyone else having the same challenge as i do, after a couple of days i got two conclusions:

1) Think again if you want to move to opnsense. There sure are a couple of advantages opnsense offers, but it also comes with a couple of shortcomings in various aspects, not only regarding migration but i.e. also regarding management of DHCP clients and aliases (not automatically created), absence of automatically generated reportes or a missing content filter (no, a web proxy with URL filtering isn't a proper content filter) to mention some.

2) Read your pfsense configuration xml files into Excel or similar, get rid of all records and columns you don't need and migrate manually by copy/paste to the opnsense Web Gui. Reserve some time as the GUI doesn't really offer support for mass manipulation of records/configuration items.

[skittlebrau]

The method I used was to spin up a VM with the same number of interfaces (virtual) and went page by page to replicate my configuration. I then exported the configuration and imported it and re-mapped the previously virtual interfaces to physical ones.

[Seimus]

You can read this thread, one new user already digged into it.

https://forum.opnsense.org/index.php?topic=36683.0

Also somebody on github did a script to covert the PF config into OPN, there are however some caveats

https://github.com/CitraIT/migrate_pfsense

Regards,
S.

[ludarkstar99]

Actually, it was moved to
https://github.com/sysadminbr/migrate_pfsense

Was made in a raw attempt to read config.xml from pfsense and submitting it to opnsense forms.
i'm working into a recent version leveraging the proper api methods.

[ludarkstar99]

Updated to work with OPNsense 24.7+

https://github.com/sysadminbr/migrate_pfsense

[robi]

Thanks for this script.
Question related to the "In all firewall rules or RDR (nat) must be a comment." requirement: comment means a the "Description" field in pfSense UI?
Why is this requirement imposed?

[tdalej]

I have tried to convert a pfsense setup over the years to opnsense and if you have much beyond a WAN/LAN setup and very limited static DHCP and unbound entries ...
It's an absolute chore.

I have a rather (probably unnecessarily) complicated pfsense setup - two buildings with each with WAN/LAN/Wifi and a LAN connecting the two for backup and management traffic so they don't go over the internet.   At one point each building had it's own ISP.

I recently consolidated to a single ISP, removing one of the pfsense boxes from the equation.

I'm in the process of converting to opnsense.

I managed to convert the heaviest of the lift using a couple of basic korn shell scripts -- unbound DNS entries and dhcp static leases.
I dump the pfsense data to csv files and use the script to convert the csv to xml that can be pasted into the appropriate sections of an opnsense backup file.

Firewall rules are still kicking my butt.

Just duplicating the default LAN rules to additional LANs isn't reliable. 
The "default" lan (created during install), and two others work as expected -- two others with identical rules will not.

I am currently connected on opt3, and this seems to be working, one of the post-install but opt4 has never functioned and opt1 worked long enough for initial access tests, but then clients can get an IP, but can't connect to the internet.


It's been over a year since the last update to pfsense-ce stable, and I _really_ want to move to opnsense but this is _rough_.

Word of caution -- trailing spaces in almost any value causes absolute insane havoc in opnsense.
If your data isn't sanitized ... 

DNS over rides:

typeset -i INDEXCNT=1
OUTFILE=DNSOverrides.txt
while read line
do
#    print $line
     HOSTNAME=`echo $line | cut -f1 -d,`
     DOMAIN=`echo $line | cut -f2 -d,`
     IPADDR=`echo $line | cut -f3 -d,`
     COMMENT=`echo $line | cut -f4 -d,`
     print "         <host uuid=\"${INDEXCNT}\">" >>${OUTFILE}
     print "           <enabled>1</enabled>" >>${OUTFILE}
     print "           <hostname>${HOSTNAME}</hostname>" >>${OUTFILE}
     print "           <domain>${DOMAIN}</domain>" >>${OUTFILE}
     print "           <rr>A</rr>" >>${OUTFILE}
     print "           <mxprio/>" >>${OUTFILE}
     print "           <mx/>" >>${OUTFILE}
     print "           <server>${IPADDR}</server>" >>${OUTFILE}
     print "           <description>${COMMENT}</description>" >>${OUTFILE}
     print "         </host>" >>${OUTFILE}
     INDEXCNT=$(( INDEXCNT +  1))
done  < $1
 
DHCP static leases ( as I said I have several LANs so each was split into a separate file with the NET* line in the input to designate the split):

while read line
do
     print $line
     MACADDR=`echo $line | cut -f1 -d,`
     IPADDR=`echo $line | cut -f2 -d,`
     HOSTNAME=`echo $line | cut -f3 -d,`
     COMMENT=`echo $line | cut -f4 -d,`

     if [[ "$MACADDR" = "NET"* ]]
     then
             echo "NET Change"
             OUTFILE=${MACADDR}.txt
     fi
     
     print "      <staticmap>"  >>${OUTFILE}
     print "        <mac>${MACADDR}</mac>" >>${OUTFILE}
     print "        <ipaddr>${IPADDR}</ipaddr>" >>${OUTFILE}
     print "        <hostname>${HOSTNAME}</hostname>" >>${OUTFILE}
     print "        <descr>${COMMENT}</descr>" >>${OUTFILE}
     print "        <winsserver/>" >>${OUTFILE}
     print "        <dnsserver/>" >>${OUTFILE}
     print "        <ntpserver/>" >>${OUTFILE}
     print "      </staticmap>" >>${OUTFILE}

done  < $1

[ludarkstar99]

Thanks for this script.
Question related to the "In all firewall rules or RDR (nat) must be a comment." requirement: comment means a the "Description" field in pfSense UI?
Why is this requirement imposed?

Hi Robi,
Yes, you need to set a description for each pfSense firewall/NAT rule.
This is a limitation I introduced to help identify already imported rules and avoid duplicates.

If an error occurs during the import process, you have the opportunity to correct it and re-import, skipping the rules that were already successfully imported.