Migrating from pfSense

[Inxsible]

Hello everyone,
I have been researching alternatives to pfSense since they announced the whole pfSense+ separation from the Community Edition a couple of days ago.

The writing is on the wall that pretty soon the CE will lag behind and not be as updated as pfSense+ and although, they have a "no-charge" pfSense+ version -- it would be closed source thereby giving me pause about the whole thing. I had a feeling this day would come when they first announced the Netgate ID -- but RL was too busy at that time for me to switch things over. I should have.

Anyway the time is here now.

My first thought was to move to OPNSense because:

• It's based off of pfSense so much of my configuration would be similar as long as I can navigate the differences in the GUI
• I had considered OPNSense back when I started using pfSense -- More on this later

But since I have to re-learn a new GUI anyway, I thought I might as well go for a Linux based firewall as I am more comfortable in Linux than in *BSD. So IPFire's got that going for it.

So I am evaluating IPFire and OPNSense and check out which one will be my next firewall. I think if either can satisfy my usage then it would likely be my next firewall. But the most important question would be:

• Can OPNSense go the pfSense route? As in, can Deciso pull a Netgate and either reserve features or worse close source on certain features?

My usage is basic. I have a single WAN with multiple VLANs trunked to the switch and eventually to an AP. I use the following 4 packages on pfSense

• acme -- for Let's Encrypt Certs -- I guess certbot via CLI/cron can be used if the WebUI doesn't have any options
• nut -- for UPS integration -- ??
• openvpn-client-export -- for easy export of VPN server config -- ??
• pfBlockerNg-Devel -- Ad blocking and such -- I might be able to replace this with a pi-hole LXC container on my Proxmox server. Other Ideas are welcome...

Does OPNSense have similar option for the openvpn-client-export and nut ?

Secondly, I have a VPN server and a VPN client. All my devices access the Internet via the paid VPN service, except my work laptop & my wife's work laptop which access the Internet via the ISP. Can I have selective routing for various devices -- maybe via device aliases or network aliases etc.? My VPN server is not being used currently -- what with COVID and all -- but I do intend to keep it running when I eventually go out of the house.

Thirdly, I have a 4 port Intel i340 card with the following networks -- WAN, LAN, IOT, GUEST, WORK & CCTV apart from my VPNs. GUEST & WORK run off of LAN whereas IOT & CCTV run off of LAN2. What does it take to set up the same networks on OPNSense?

Fourthly, I use the DNS Resolver within pfSense and I don't use any other DNS server. How would I set that up in OPNSense?

Finally, some basic log information, SMART status of the disk etc & backup & restore of config files would be nice to have in the WebUI.

As you can see, my usage is extremely basic. I think from my research, OPNSense does support everything even though it may do it a bit differently. I do intend to run it in a VM soon so I can take it for a spin before I commit to it on my current router hardware.

My current pfSense runs on a J3355 SoC board 4GB RAM and an attached Intel i340-T4 card. I also use a 2.5" PATA HDD that I salvaged from my circa 2000 laptop. The new firewall -- whether IPFire or OPNSense will eventually be installed on this machine.
When I first transitioned from DD-WRT to pfSense, I had tried out OPNSense, but the installer would just not recognize the 2.5" PATA drive that was connected via a PATA->SATA adapter. pfSense installer recognized it, so pfSense is what I ended up using at that time. This time around though, if OPNSense still doesn't recognize the PATA drive, I am willing to put in a small Kingston SSD.

PS: To the mods: I was not sure if this kind of post should go into General Discussion or some other sub-forum, so if this is the wrong board, please feel free to move it.

PPS: Oh and sorry for the long-winded post!

[mimugmail]

OPNsense already has a business edition, but compared to pfsense it's more features behind, so OPNsense might be Fedora while business edition is RHEL.
I'd guess as long as Franco and Ad are aboard all the things you are concerned are not to worry about. I know Franco in person and had also long history and talks with Ad. Both are doing OPNsense for fun and want to combine this as dayjob, not to get rich.

OPNsense has nut plugin and support client export out of the box. Also Unbound can do DNS blacklisting like pfblockerng and has GeoIP alias out of the box like pfblocker. As you can see, no need to install plugins. acme is also available as a plugin, maybe menu structure might be different, but that's life, never stop learning

In the beginning I also searched for a linux alternative, but for my needs IPfire was not enough. Best to install opnsense and ipfire in a VM and play around

[franco]

Hi there

> Can OPNSense go the pfSense route? As in, can Deciso pull a Netgate and either reserve features or worse close source on certain features?

To be fair, you never know, can you? The thing that matters most to me personally is that OPNsense in the way it is distributed to the community is (easily) reproducible from a third party build system with all the sources off GitHub:

https://github.com/opnsense/tools#setting-up-a-build-system

I know that is a weak point in pfSense dating back to the infamous pfSense-tools repository that went offline and then came back later in a new form just because the approach was not feasible and/or OPNsense was not about to die and pfSense needed to readjust to that reality.

So we intend to keep it this way and the community can always fork and continue if we don't. Sort of checks and balances in my opinion where either side can break a promise i.e. community can fork OPNsense and leave us here alone, too.

> acme -- for Let's Encrypt Certs -- I guess certbot via CLI/cron can be used if the WebUI doesn't have any options

Plugin available, yes. Very good maintainer.

> nut -- for UPS integration -- ??

Plugin available, yes. Also very good maintainer.

> openvpn-client-export -- for easy export of VPN server config -- ??

Included in core since almost forever. Let me look.... it was March 25, 2015[1]. An API for it was added as well in 2019.

> pfBlockerNg-Devel -- Ad blocking and such -- I might be able to replace this with a pi-hole LXC container on my Proxmox server. Other Ideas are welcome...

Michael has done a lot of work to provide feasible plugin alternatives. And, TBH, pfBlockerNg is a great piece of software and it is hard to replace in a singular way on substitute projects.

VPNs and exceptions for clients are no issue.

Interface setup emulation is surely no issue the way you had it in pfSense. This is much harder to do in a new environment like IPFire though.

> Fourthly, I use the DNS Resolver within pfSense and I don't use any other DNS server. How would I set that up in OPNSense?

Unbound has been standard in OPNsense for a while... we renamed it from "DNS Resolver" to improve visibility/clarity.

> Finally, some basic log information, SMART status of the disk etc & backup & restore of config files would be nice to have in the WebUI.

Logs in core, SMART in plugins, backup and restore as you would remember it mostly.

Let me know if the drive is not detected, but I think a lot happened in between the last try for it to work fine now.

In closing, whether you want to use OPNsense or IPFire is completely up to you. OPNsense will give you familiarity where IPFire cannot and this includes issues for transferring your current setup, i.e. IPFire will be harder to make it work or will require adjustments to your setup / approach. On the other hand, IPFire has Linux so there are less hardware issues to worry about and it's a nice distribution aimed a bit lower in scope that pfSense/OPNsense is.

But if it works, it works.


Cheers,
Franco

[1] https://github.com/opnsense/changelog/blob/master/doc/15.1/15.1.8.2#L49

[Inxsible]

@mimugmail, Thanks for confirming that most of the things will work albeit a bit differently.

In the beginning I also searched for a linux alternative, but for my needs IPfire was not enough.

Would you be able to elaborate as to which specific needs were not supported by IPFire -- I just want to see what the limitations are even if I don't use those particular features.

Best to install opnsense and ipfire in a VM and play around

I intend to

[Inxsible]

Thanks for the reply and confirming @franco. I won't re-iterate everything that you said, so forgive me, but I have snipped off some of your quote in order to focus on the ones that I still have questions/clarifications about.

> Can OPNSense go the pfSense route? As in, can Deciso pull a Netgate and either reserve features or worse close source on certain features?

To be fair, you never know, can you? The thing that matters most to me personally is that OPNsense in the way it is distributed to the community is (easily) reproducible from a third party build system with all the sources off GitHub:

https://github.com/opnsense/tools#setting-up-a-build-system
......

So we intend to keep it this way and the community can always fork and continue if we don't. Sort of checks and balances in my opinion where either side can break a promise i.e. community can fork OPNsense and leave us here alone, too.

I will have to read up on this a bit more, but from what you are saying, does it mean that even if Deciso or anyone else does make OPNSense closed source in the future, the current code can be easily replicated using a build system and then forked? But it does mean that in the even that OPNSense is made closed source -- the newly developed features (whatever those may be) -- will not be available unless a new developer/team/company then takes over and starts implementing and maintaining the forked codebase?

> openvpn-client-export -- for easy export of VPN server config -- ??

Included in core since almost forever. Let me look.... it was March 25, 2015[1]. An API for it was added as well in 2019.

It's good that the base install does this and there's no need for a separate package.

> pfBlockerNg-Devel -- Ad blocking and such -- I might be able to replace this with a pi-hole LXC container on my Proxmox server. Other Ideas are welcome...

Michael has done a lot of work to provide feasible plugin alternatives. And, TBH, pfBlockerNg is a great piece of software and it is hard to replace in a singular way on substitute projects.

I understand that pfBlockerNg is good -- but as I mentioned in my first post, I am not married to having 1 package deliver everything just like pfBlockerNg. I am open to having some of it done by OPNSense and then offload some of it to a separate pi-hole container on my Proxmox server. I know that I am the one changing my router software, so I am definitely willing to do things differently if required.

Interface setup emulation is surely no issue the way you had it in pfSense. This is much harder to do in a new environment like IPFire though.

Would you be able to elaborate why it would be difficult in IPFire -- Is it only because of Linux vs *BSD or are you alluding to some other issues.

Let me know if the drive is not detected, but I think a lot happened in between the last try for it to work fine now.

Yes this was a long time ago --- i think in early to mid 2016 -- OPNSense was in it's infancy at the time, so I would imagine that many things would have been improved. Again, I was using an ancient HDD on it, so I wouldn't blame OPNSense completely either.

i.e. IPFire will be harder to make it work or will require adjustments to your setup / approach.

At the risk of repeating my earlier question, is this only because of paradigm differences in Linux vs *BSD or some other ?

On the other hand, IPFire has Linux so there are less hardware issues to worry about and it's a nice distribution aimed a bit lower in scope that pfSense/OPNsense is.

Since I use a separate AP for wireless -- the hardware issues is not something that I am too concerned about. Yes Linux does support more hardware in general -- but as long as anyone sticks to the basic x86_64 architecture, I think either one would work equally well. Now if you wanted to have Wifi built in to your router  -- then maybe Linux would be a better choice
What do you specifically mean by "aimed a bit lower in scope" ?

But if it works, it works.

Yes, that would be the primary concern.

[iBROX]

Since the pfsense announcement the other day I thought that was as good as a excuse as ever to revisit opnsense. First I had a play in a VM and by day two I had migrated all my config over to my physical router, I must say I prefer opnsense to pfsense so I’m happy in my decision, the UI is a lot cleaner for a start!

As for features, I’ve pretty much moved everything over so far, just need to do the alternative to pfblocker but other than there everything is working fine, looking forward to installing Sensei and having a play.

Keep up the good work!

[franco]

I will have to read up on this a bit more, but from what you are saying, does it mean that even if Deciso or anyone else does make OPNSense closed source in the future, the current code can be easily replicated using a build system and then forked?

Yes.

But it does mean that in the even that OPNSense is made closed source -- the newly developed features (whatever those may be) -- will not be available unless a new developer/team/company then takes over and starts implementing and maintaining the forked codebase?

Work is work and progress is progress. But that is not the issue. You want the possibility to do something better or something else, not chase the commercial closed source alley with an open source product because in general all closed source companies in the security scope have a lot of employees and it's very hard to keep up with that.

Would you be able to elaborate why it would be difficult in IPFire -- Is it only because of Linux vs *BSD or are you alluding to some other issues.

Going back to "work is work" -- IPFire development is separate from e.g. pfSense and OPNsense so that means different people with different backgrounds write a product for a different target audience on a different operating system that has different settings and code. It's impossible to end up with the same menu, help texts, work flow in the GUI like one would be used to having used something else.

At the risk of repeating my earlier question, is this only because of paradigm differences in Linux vs *BSD or some other ?

I don't use IPFire so my knowledge is limited. The main theme that keeps repeating is that the interface concept goes something like this:

https://wiki.ipfire.org/configuration/network/zoneconf

It's not as loose as the configuration options for interfaces in *sense, but I am not saying its worse or better or doesn't work just as well. It's simply different.


Cheers,
Franco

[Inxsible]

When I go to the opnsense.org/download page, what am I downloading 20.7 or 20.7.8 (which seems to be the latest release as per the forum -- even though the latest release on the blog is 20.7.7)

Sorry I am a little uninitiated still with how the versions work. Also if 21.1 is going to be released in the next 4 days, I might just wait for that and start clean.

[franco]

This document should help https://pkg.opnsense.org/releases/mirror/README


Cheers,
Franco

[vollans]

Likewise, I'm looking at whether to move from pfSense.  I do like the interface, it is a lot easier to navigate than pfSense.

My "problems" are few, but showstoppers for me at the moment.

1. Migrating settings from pfSense - if major chunks like DHCP allocations & Suricata config could be imported, it would make life a lot easier

2. File system... Early last year when I was choosing between Opnsense and pfSense it came down to one thing, UFS. I had crashes/lockups on both systems (my fault working out what things did) that required a hard reset. pfSense's ZFS option made that painless, I did on more than one occasion have crashes big enough to totally stuff up parts of the system, especially making Sensei's database crash beyond repair. Looking at the forums it seems there still isn't an easy way to use ZFS on Opnsense, the best suggestion being installing BSD 12.x first to set it up, then run a set up script to convert it. Is that still the case?

3. PCEngine APU4. I did recently purchase one of these and set it up with pfSense after earlier running it on a spare Mac mini. Setting up the APU4 on pfSense was painless. Doing a test run of Opnsense was fiddly and time consuming involving having to make a boot disc, mount it, fiddle with settings in boot.config and loader.conf, install, then make sure to make the same changes to the new install before you dare to reboot, etc... Has that improved in the 21.1?

[franco]

1. DHCP shouldn't be an issue to import per section. Suricata is a full rewrite. Can't use old XML in this latter case.

2. See https://github.com/opnsense/update#opnsense-bootstrap -- installing FreeBSD 12.1 ZFS and installing OPNsense afterwards. You can even drop the preconfigured config to /conf/config.xml so it'll bootstrap right into the final config. It's not a super-tedious procedure.

3. Need more infos on APU4 "fiddly and time consuming", also which OPNsense version (up to 20.1 maybe?) misbehaved. Maybe someone else can share their experience with the box.


Cheers,
Franco

[vollans]

2. See https://github.com/opnsense/update#opnsense-bootstrap -- installing FreeBSD 12.1 ZFS and installing OPNsense afterwards. You can even drop the preconfigured config to /conf/config.xml so it'll bootstrap right into the final config. It's not a super-tedious procedure.

3. Need more infos on APU4 "fiddly and time consuming", also which OPNsense version (up to 20.1 maybe?) misbehaved. Maybe someone else can share their experience with the box.

Hey! Thanks for the quick reply. 2 is what I did in my test run, but as the APU4 is headless you need to do it via the serial console, and the bog standard 12.1 doesn't seem to want to do that! So I had to go through these steps to get the initial install of FreeBSD 12.1 to install. Once I'd gone through that several times due to missing a step I used the script you linked to and it installed 21.1r1.

Compared to the pfSense way of getting ZFS with serial, pop in USB stick and install, it is fiddly.

[securityconscious]

I'm new to networking and firewalls but I have some experience with IP Fire and I would advice you to stay away from it, they can hack your IP Fire installation and compromise it, if they don't like you.

That is what happened to me and I changed from IP Fire. They didn't like hearing hard truths about firewall distros, so they developed a grudge and hacked my IP Fire installation and made all rules ineffective. I could block access entirely to allow entirely.

You say, you have experience with pfSense, then you would be comfortable with OPNSense, although interface is different, but making rules is similar, they use different symbols for allow, block, incoming, outgoing. Remember, in OPNSense, incoming means traffic coming into the firewall from any interface, and outgoing means traffic leaving the firewall.

You can always take the firewall distros for a test drive in virtual machine. Other firewalls based on Linux are Smoothwall, ipcop, ClearOS, etc.

[mimugmail]

I'm new to networking and firewalls but I have some experience with IP Fire and I would advice you to stay away from it, they can hack your IP Fire installation and compromise it, if they don't like you.

That is what happened to me and I changed from IP Fire. They didn't like hearing hard truths about firewall distros, so they developed a grudge and hacked my IP Fire installation and made all rules ineffective. I could block access entirely to allow entirely.

I'd be very careful to post such things. It's quite unfair for the distro and may distribute untruths.
Why should a community (mostly 2 core devs) putting hours of coding into it do this to someone like you and not everyone?

[securityconscious]

I'd be very careful to post such things. It's quite unfair for the distro and may distribute untruths.

Why should a community (mostly 2 core devs) putting hours of coding into it do this to someone like you and not everyone?

Vendetta for asking hard questions. Anyway that is my experience with it, apparently they block traffic between interfaces by default, so I disabled all rules, and I tried pinging green network from blue and I was getting response, vice versa, same. Then I created explicit rules blocking traffic from green to blue and blue to green, still getting responses.

2 developers are easy to corrupt than a team of them, they'll settle for less money. And I don't know how much they contribute, IP Fire really looks like reskinned version of IP Cop, most of the core is from Linux From Scratch, I guess they use the firewall portion from IP Cop and they have only used their HTML and JavaScript to create a different interface.