New user - Migrating from "pfSense - CE 2.7.0" to OPNsense

[franco]

To my knowledge VLANs could work fine from the GUI configuration backup import. Feel free to send your import bit via mail so I can take a look if it doesn't work out.


Cheers,
Franco

[Mega32]

Ahh ... I never tried GUI

It's not happy
I fed it a pfS (Vlan-export only section)
Is that ok , or should it be a full config ??

Import Vlan - Success
Success if i feed it a Full pfS config file, and just restore the "Vlan Devices" section

Edit:
Seems like i have used a wrong screen-copy image, that shows error in the top.
Please ignore the error shown .. It works

[Mega32]

Import Interfaces - Success  .... Almost (I lost WAN)

You have to think/plan when restoring the interfaces, it would be quite easy to break your existing IP connection
You are loading new interface definitions ...
Ie. you might want to make sure your pfS (Config file) connect IF has the same IP addr. as current OPNsense firewall connect IF.   Else you'll looe yor IP connection after import.
And make sure you have imported Vlans first, if you use them.
Same goes for VPN Client/Servers, and their Certs

On my Prod Box , I have an unused interface. the last interface (em3) on my 4-port fwall.
So i have assigned that as an untagged "Emergency Connect IF"
And HTTP access to the fwall (Mgmt) is permitted on that IF.
So i know i can connect to my em3 IF, and use that if i lose access.

But - I run these migrations on a "Virtual OPNsense",and always have access to the CLI console.
Even if i loose all network interfaces..
That will enable me to copy a previous "good config" to /conf/config.xml , in order to make a "fallback".

On my physical boxes i have a serial port enabling me to do the same access, even if i loose all network interfaces.


On my virtual VBOX OPNsense i connect (IP) to FWall mgmt (HTTPS) via the WAN IF (Only one with physical access).

Importing the pfS interfaces to OPNsense
I just did a restore Interfaces section on the OPNsense, and fed it "a slightly modified" full pfS config file.
It was an "Almost" success , as i "Lost the WAN IF" , but still had IP connection ... ?? ..
All other interfaces seems to have been imported.

I tried fallback & run the import two times, but kept on loosing WAN.
In the end i ended up doing the import, and manually adding (vi editor) the wan interface to config.xml

I had a backup pf the OPNsense config , when wan was present & working.
I "snipped" the <wan> ... </wan> section out of the working backup config.
And pasted that into config.xml , just above the <lan> section.
I then ran :

Code: [Select]

/usr/local/opnsense/mvc/script/run_migrations.php
And now wan was present in the config, along with all the other IF's from the pfS

If/When i find a solution to the disappearing wan during import, I'll update the post.

Tick prevent interface removal isn't needed anymore, after doing the pre-adaptation  of the vlan/vlan-interface names, before importing into pfSense

Tick prevent interface removal

After importing IF's go into EVERY IF - Also VPN interfaces's (and maybe others .. LAGG etc ) if present in config.
And tick "Prevent Interface removal"
Else you risk they're removed on next reboot.

When rebooting , some kind of importer is running.
And it (at console) decides "No default interfaces found - Running interface assignments".
This means i would have to assign all interfaces (20).
And if not doing that, after some time  it starts some auto detection. That assigns Lan to em0 (first physical) , and wan to em1 (2'nd physical) , and drops the rest of the assignments.


Next - Make sure all interfaces on OPNsense has the same name as on the pfS
By this i mean even if you name your IF DMZ .. It still uses an internal name, usually : optxx

If we should stand a chance of important the pfS firewall rules, then the "internal names" MUST be the same.

I have compared the interface names. And it seems like OPNsense uses the optxx names given from the pfS import.

So i'm a "happy camper" ....
Well after doing the above "Prevent interface removal" .... Lost a few remaining hairs on that one 

[Seimus]

Once you are done with your migration you will be the migration expert 

I would actually advice as well if you are willing to create a full fledged guide on the Tutorials and FAQs section once you are done with the migration.
https://forum.opnsense.org/index.php?board=24.0

Summarizing all what can be migrated and which way. Would be helpful for others as well.

Regards,
S.

[Mega32]

Once you are done with your migration you will be the migration expert 

I would actually advice as well if you are willing to create a full fledged guide on the Tutorials and FAQs section once you are done with the migration.
https://forum.opnsense.org/index.php?board=24.0

Summarizing all what can be migrated and which way. Would be helpful for others as well.

Regards,
S.

Hi Seimus

I doubt i'll be making a document of the conversion.
I'll be describing it in this thread , and make Bold entries in the first post, to relevant posts in this thread.

I'll do the bold entries as a kind of index, so you don't have to scan the full thread.

[Monviech (Cedrik)]

https://www.netgate.com/blog/netgate-pfsense-plus-tac-lite-available-for-129-per-year

What's your opinion on this as former Mother Sense user? It seems like they noticed their actions had adverse effects.

[Mega32]

I haven't had much faith in CE since they made PLUS
The only reason i didn't switch to OPN back then, was that they made PLUS free for Home+Lab (HL) use.
But now i have "downgraded" my PLUS boxes to CE, as they write HL registered systems won't get any upgrades without a $129/yr subscription.

So i will still convert my home boxes to OPNsense.
Who knows when they do another "CE surprise", or if CE will slowly "obsolete to death" ...

I think the reviving of the TAC-Lite $129/yr subscription, was to keep SMB's on PLUS.
And at least cash in the smaller fee, instead of nothing.

But i think a lot of users have lost trust in them, no matter what broken promises they are reviving.


I feel sorry for the people that might not be capable of migrate to OPN ...
They might be trapped over there.
Maybe OPNsense Tech-Support could offer a "Basic config" conversion to OPN if the customer ie. pays for a 2..3/yr subscription up front.  Or maybe if the customer buys a DEC Box ...


 

[Mega32]

Import Certificates
My Certs imports wo problems.

Import OpenVPN
My OVPN imports , but when trying to change settings it was giving a: Interface has no ip addr - Error.
Turned out to be : The WAN needs to be up & running (have ip).

Also if using TLS Key ... Check that TLS Key Usage matches the other end ... mine didn't.
I use TLS Enc + Auth on the pfS, and had to change to that on opnSense VPN's

And make sure Compression matches other end. I used "No Preference" (should match Disable compression on pfS)

[thebull]

Apparently there was an issue in the migration that prevented nested aliases from validating during migration:

https://github.com/opnsense/core/commit/e4c857f0

So here is the full sequence on top of 23.7.7:

The patch will be included in 23.7.8 onwards so no need to run the patching there!

# opnsense-patch e4c857f0

(only apply the patch once otherwise it's going to be removed again)

# pluginctl -f OPNsense.Firewall.Alias
# pluginctl -f aliases

(confirm delete of garbage entries to allow for a migration)

edit /conf/config.xml to add your pFsense <aliases/> section cleanly again -- it should go right above the last line of the file saying </opnsense>

# /usr/local/opnsense/mvc/script/run_migrations.php
Migrated OPNsense\Firewall\Alias from 0.0.0 to 1.0.1

In case there are errors please post them here. They can be seen via the following command when the migration would fail.

# opnsense-log


Cheers,
Franco

Wanted tot let you know this worked fine ;-) thanks.

[smccloud]

I wish I had seen this before I started my project to convert a pfSense config file to an OPNSense config file by writing a program.

https://github.com/smccloud/pfSense-to-OPNSense-Config-File-Converter

[Mega32]

Importing firewall rules

I urgently suggest you to NOT do this with your wan connected to the Internet.
I have my wan configured for dhcp, and connected to an "inside" vlan on my existing setup.

After being 100% sure your Aliases and Interface assignments are imported correctly

See here for Interface import
https://forum.opnsense.org/index.php?topic=36683.msg179463#msg179463

And make sure every interface has same assignment as on the pfS
ALL Interface assignments must match excactly across OPN and pfS configs.
Especially pay attention to the optXX assignments, as they reflect the way (time) they were created on the pfS.

When you are sure the IF's are assigned/numbered the same way.
You could import the - Restore Firewall rules section from the pfS config.

Pay attention to "NOT locking your self out" of the target OPNsense box.
Or make sure you have a console attached, and after restore run temporarily disable the OPNsense firewalling by running a : pfctl -d
And now make a firewall rule allowing you access again.
Then enable the firewall by running a : pfctl -e   - Or just reboot.

I have not had time to walk through my rules yet, but at first glance tth result seems "Not bad at all ..." 

As a minimum do review the rules on your WAN interface, before connecting it to the internet.
And preferably review rules on all interfaces, before setting the "Box in prod".

ICMP Rules - Reports error
I noticed a red dot here -Statusbar - Top Right


And when clicking on it it showed a firewall rule that had a syntax error.


It turned out that ALL my imported ICMP rules had syntax error.
Solution was easy : Edit the rule , and press "Save"

But i had to do it for every ICMP rule i had made ... Well an easy fix.

It is probably a good idea to edit every rule, and just press save.
Based on a few diffs , it seems like the rules are "rewritten" to fit the OPNsense syntax, when editing, and just presing save.
Ie. All my "Disabled rules" har a strange state , where they were "Geyed out, the the text", but still had color on the icon all the way to the left ... "That should be black" - Editing the rule fixed that, and so did a select & disable.

[franco]

As far as I can tell Mega's issue in interface mismatch and reset is the newer VLAN layout in pfSense which is e.g. em1.444 vs. the compatible one em1_vlan444.

There's no way short of doing a search and replace to fix this properly, because the system will miss that this is a VLAN interface and behave oddly afterwards as well (even with lock being set).


Cheers,
Franco

[Mega32]

As far as I can tell Mega's issue in interface mismatch and reset is the newer VLAN layout in pfSense which is e.g. em1.444 vs. the compatible one em1_vlan444.

There's no way short of doing a search and replace to fix this properly, because the system will miss that this is a VLAN interface and behave oddly afterwards as well (even with lock being set).


Cheers,
Franco

I have addressed the "Incompatibility here", according to Franco's description ... Thnx again 
https://forum.opnsense.org/index.php?topic=36683.msg179265#msg179265

Hopefully the adaptation of the pfS config file , will produce valid vlan names for OPNsense
 

[Mega32]

Import Nat/Portforwarding
Importing NAT/Portforwarding seems straight forward.

Just select Restore -> Restore Area : NAT


Ps
I did set OPNsense Outboud NAT mode to match the mode i use in pfS , before the import.
But the mode seems to be included in the pfS config.

PPs:
My NAT is super simple... Two portforward rules , and Outound Nat
So this import might not be tested very well.

[shremi]

I have convertes succesfully 2 out of my 3 boxes to opnsense.


However there is still one that is located in a completely different country , anyone knows a good way to set up wireguard site 2 site with PFsense and Opnsense?