OpenWrt to replace pfSense?

Hi

If this post is out of place, please tell me. I am currently studying some of the documentation
for OpenWRT, but I thought that a little advice from this forum would be nice.
I'm a Linux-oriented sysadmin for a highschool in Denmark. We have about 350 users in different locations. Currently I run some x86-based pfSense-routers. I'm strongly considering to switch from pfSense to OpenWRT and this mainly because of all the drama around Wireguard we have seen lately in that arena. The atmosphere around the company behind pfSense, Netgate, can be somewhat toxic
at times. And pfSense is not really considered truely open source be me.
So I am starting to look at replacing pfSense with OpenWRT, which seems like a truely grassroot
open source project to me.
So I hope that I might get some advice on, whether this is doable for my requirements. I'm aware
that the forum-users here will be thinking very positively about OpenWRT, but you might still
be able to supply me with some objective advice.
I'm aware that OpenWRT was developed to replace firmware on wireless routers like Linksys, but
I will not be using that at all. I hope to able to run it as a general router/firewall on quite powerful hardware with 4-6 gigabit ethernet ports.
My requirements are not very complicated:

  1. I have a pool of public ip-addresses that need forwarding to internal private ip's on a DMZ-like network segment from where we run web-servers etc. So my WAN-address acts like the gateway to that segment seen from the outside, and also from the inside of course. This is done with "virtual" ip's in pfSense. What would be the correct way to do this with OpenWRT?

  2. General firewalling between the 4-5 network-zones. About 100 rules all in all.

  3. Dns host overrides on some network-segments.

  4. Static nat-ports for clients on one network-segment. Meaning no source-port randomization.

  5. Static dhcp-leases on some network-segments.

  6. Wireguard - both Site-to-Site connections and also connections to "road-warrior-clients".

Shouldn't it be moderately simple to implement this with OpenWRT?

Greetings from Denmark
Hans Otto Lunde

2 Likes

All of that seems straightforward. There is a x86 build available. I think it's mostly giving it a try...

1 Like

Welcome Hans!

To play devil's advocate: you'd like to move away from pfSense after the WireGuard fallout (which I completely understand, and it seems they set up a smear campaign against opnSense as well at some point), but what makes you look towards OpenWrt rather than to opnSense first?

I know it's not an answer to your question, but I'm curious. Unless the main reason is the mature WireGuard kernel implementation in Linux. Then it's an easy answer.

3 Likes

Thanks for welcoming me, Borromi.
Before the Wireguard controversy between Netgate and Jason Donenfeld we started to use their Wireguard implementation. And my users absolutely love it and so do I. There has not been any issues with it, but now they have pulled it out of the distro and I don't really feel comfortable with Netgate anymore, so therefore I'm looking for alternatives. And Wireguard was first targeted at Linux, so I feel comfortable that the implementation in OpenWRT is solid. I am a Linux person, so therefore I decided to look at OpenWRT, which seems like a free and mature product, absolutely. The documentation could be a lot better, I think. But then again, once you learn your way around it, this will not be a big problem. I hope the community is welcoming, at least you are, thank you!
In some place, Reddit I think, I read this:
"First, OpenWRT as a project is anti-social. They actually don't want end-users. That's why there is no end-user mailing list and no notifications for new releases (no twitter, no facebook, no email announcement list, nothing). All announcements are done unofficially and by 3rd parties. Their documentation sucks because the devs don't document anything and don't comment anything in their code. It's a very insular group of people."
Is there any truth to this kind of remark?
Anyway, I will have a thorough look at OpenWRT and see if I will decide to switch over. There is also some considerations around maintainability, updates etc. I would not like to spend too much time fixing things, that break after an update and so on. After all, my job is too demanding for me to spend a lot of time fixing routers. They should just work.

Those comments on Reddit are either someone with an axe to grind or very old. The documentation for Openwrt has come a very long way and https://openwrt.org/docs/start has a lot of very detailed information on the setup and use of the various subsystems.

Announcements of new releases are made on this very forum under the Release and Security Announcement sections. Sure, the project doesn't use Facebook or Twitter as far as I'm aware, but I'd hardly consider that a failing.

The git repos are full of comments and well-documented issues and each commit is accompanied by a proper commit message as to what it does and the reason for the commit, so I can only surmise someone who is levelling the "commenting" accusation hasn't actually gone to browse the code.

Like most projects, the core developers are part of a mailing list and most of the development work for the base openwrt goes on there. Anyone can browse the archives and join the list. The packages repository is hosted on github and anyone can contribute. There are many contributors, lots of whom are regular posters on this forum as well.

There's no end-user mailing list because this forum takes the place of that and it's a super active forum with lots of very helpful users. And a good number of the core developers contribute regularly to the forum as well.

If you were to use Openwrt you should use a stable release version and not a snapshot version. It's in the trunk development versions that things will have a tendency to break, but those of us who use the trunk version know this and accept it

5 Likes

If that's the case, consider OPNsense instead as it's a much more similar replacement. OpenWrt's upgrade path is very rough in comparison. Be prepared to manage your own repo, firmware and it's not going to be an "apply firmware --> done" deal. Monitoring etc is due to nature of OpenWrt much more limited which may cause issues further down the line.

Due to the nature of what kind of hardware OpenWrt targets it's also much more of a hassle to update induvidual packages than your "average" distro for lets say security reasons.

If you don't like to tinker then this is far from a replacement.

As far as documentation goes it's poor at best, there's no policy in place to document anything that's get committed so while that statement is a bit rough does hold some truth to it.

If you're using a supported device and don't have customizations, then the update is as simple as a sysupgrade. No need to manage your own repo or firmware.

Monitoring is simple via luci or if you have multiple devices, send their syslog output to a central server.

Until there's a change that breaks configs (usually is well hidden in a commit message) which sadly been true for many releases and you still manually need to re-install packages or pre-package it with your own firmware image.

I like OpenWrt a lot, and I think the community here in the forum is one of the most helpful communities around.

But if I were going to run multiple X86 boxes as routers, I'd personally run Debian, configure the NICs / Wireguard using systemd network files, and centralize the configuration using cfengine.

OpenWrt really excels for its primary use-case which is a single resource constrained device in a home or small business network, where an occasional / part-time system administrator needs to have a web-accessed GUI for routing configs.

It's perfectly workable for your project though.

3 Likes

In my small experience here, this is completely wrong... you can get an idea yourself by browsing the forum about how questions of any level are asked/answered by users, who are very kind and helpful to each other.

@holunde Also there are: https://lists.openwrt.org/mailman/listinfo

Maybe i shouldn't say it, but... god bless :grinning:

1 Like

"Workable" is honestly a stretch if you look at the whole picture. Let me put it this way, compare how much time you spend (and how frequent) you upgrade your Debian box compared to your OpenWrt setup with services not in base image/firmware. I'm going to guess that it's several times more than doing your apt magic. Again, it's not that OpenWrt is to blame but rather consequences of decisions made to make it viable on very resource limited device (read no storage just flash memory available). Debian is no different compared to any other OS/Distro in terms of "usability", you will need to reimplement an infrastructure etc.

Another thing worth noting (it's been a topic several times) is that you'll cripple your hardware quite a bit if you use the releases on x86 on fairly recent hardware as it targets as much hardware as possible leaving any "recent" features (hardware instructions) etc disabled.

Can you point me to some of these discussions?

I've made a couple of optimizations to my x86_64 kernel, such as enabling CONFIG_SPARSEMEM_VMEMMAP and choosing the relevant processor family while disabling the others, but I didn't notice a whole bunch of lowest-common-denominator choices in the default config.

It used to be this way, but more recent x86_64 kernel configs are much better optimized. What hardware instructions are disabled?

My debian boxes are desktop machines mostly so their upgrade situation isn't relevant to dedicated routers. I think for less than 10 machines OpenWrt would be fine though nothing like as nice as something with cfengine all centrally controlled. But cfengine requires a huge amount of learning time as does any other config mgmt system.

Anyone whose been using pfSense in this way probably will do fine with OpenWrt.

Can it be done successfully? Yes! Is it optimal? Depends on what are the most important factors for the deployment.

You're really avoiding thing the main question here :wink:
On your desktops, it's most likely apt ... and it's done. It's usually far from just updating package X and/or flashing a new firmware on OpenWrt no matter how much you want to sugarcoat it.

It can be performed automatically as well:
Saving/restoring user-installed packages

I second this.

Simply set up a VM and test it.

1 Like

It must be overwhelming for the OP. :wink:

Never used pf/opnSense, but I've been reading up on the whole wireguard implementation drama and badmouthing of opnSense project as well and totally understand the desire to move away from Netgate product/ecosystem.

Evern modern desktop Linuxes (haven't used *BSD-based systems for a while now) manage OS upgrades differently. Some you can just run an upgrade command and reboot to a new version preserving most if not all of your settings/packages (Ubuntu), but I believe with some there's no easy upgrade from one version to another at all (RHEL/Oracle Linux).

Sure, OpenWrt's update/upgrade system is different, however, what I love about OpenWrt is that I can create a uci-defaults script which configres everything and with the Image Builder I can very quickly create my own custom image which results in a working/configured system right after flashing.

I would recommend OP does the same to reduce the downtime on upgrades. And since it's for an x86 system, if you FUBAR it, just boot from a live USB and write the last known good image back.

1 Like

Wow, that was a lot of responses!
I thank you all for your thoughts on this small matter. Now I have a better understanding of OpenWRT and the community around it.
Greetings from Denmark

1 Like

my 2c...

  • the above statement while in general makes sense... given your complex requirements... your bordering hiring a proffessional to manage your router/s... so I think 'just work' is perhaps an oversimplification/underestimate in your environment
  • given your complex requirements... yes... openwrt can do it... and once you are familiar with it's in and outs it can do the core parts extremely well... and in the open ethic you desire... but there is going to be no plug and play here... so slowly build your skills and look at opnSens as another member suggested... ( or definately look at hiring someone for the 3 hours initial setup and they can ease the learning curve and get you much closer to your 'just work' )
2 Likes

Ok, thanks for the advice.
I'm looking into OPNSense as well.

1 Like

The single most missed feature for me in comparison with pfsense, is the feature "aliases". I really miss the option to give aliases to ip addresses or ports - or event group of addresses or ports. It reduces the numbers of rules in the firewall and also makes it more readable. Furthermore, OpenWRT has no concept of "linked firewall rules" (linked to nat) - but for me it is not a big issue.
In some cases, it could be a big downside, that you cannot use CARP and have and active-passive ha setup of firewalls with OpenWRT (as far as I know)