well, its not without issues. the actual motivation was not that dhcp is the suxxors, but to promote a model where the assigned prefix was free and highly dynamic.
the goal being to support a model where one could support multiple prefixes to handle the common case of multiple internet connections. more importantly to allow providers to shuffle the address space around without having to coordinate with the end organization. this was perceived to be necessary to prevent the v6 address space from accruing segmentation.
It's funny the "handle the common case of multiple internet connections" just doesn't work at all with ipv6 yet works much better under IPv4 NAT. With IPv6 each machine gets it's own routing table due to having two addresses which means I can't failover on the router when an ISP goes down. Machine will keep trying to use the ISP that is having 100% packet loss. I can't prioritize sending traffic out of one ISP because I'd need to configure it on each machine due to them having their own routing table. With IPv4 the router can handle those rules since its doing NAT for all machines in the network so it gets to choose.
The controller is annoying and changes completely every 6 months, and for home I use basically none of its features beyond configuring the AP. Virtualy all the issues I’ve had with Unifi APs were controller bugs, telling the AP firmware to do stupid things when it could have done literally nothing.
That said, I have some concerns that the OpenWRT AP firmware is not as optimized as the Unifi firmware is for that specific hardware. Mostly for wireless performance, but I also don’t want to hit some weird CPU bottleneck.
One thing I like about using OpenBSD for my home router is almost all the necessary daemons being developed and included with the OS. DHCPv4 server/client, DHCPv6 client, IPv6 RA server, NTP, and of course SSH are all impeccably documented, use consistent config file formats/command-line arg styles, and are privilege-separated with pledge.
Also it's a really well trodden path. You aren't likely to run into an OpenBSD firewall problem that hasn't been seen before.
Regarding any BSD used for any purpose, BSD has a more consistent logic to how everything works. That said, if you're used to Linux then you're going to be annoyed that everything is very slightly different. I am always glad that multiple BSD projects have survived and still have some real users, I think that's good for computing in general.
The recent addition of dhcp6leased is a great example: Built into the base system, simpler to configure than either dhcp6c or dhcpcd, and presumably also more secure than either.
Compared to working with iptables, PF is like this haiku:
A breath of fresh air,
floating on white rose petals,
eating strawberries.
Now I'm getting carried away:
Hartmeier codes now,
Henning knows not why it fails,
fails only for n00b.
Tables load my lists,
tarpit for the asshole spammer,
death to his mail store.
CARP due to Cisco,
redundant blessed packets,
licensed free for me.
pf has been ported to Debian/kFreeBSD, but afaik no effort has been made to port it to the Linux kernel. A lot of networking gear already runs a BSD kernel, so my guess is the really high-level network devs don't bother because they already know BSD so well.
I assume in this case they already had a bunch of firewall rules for PF and switching from OpenBSD -> FreeBSD is a much easier lift then going to linux because both the BSDs are using PF, although IIRC there are some differences between both implementations.
PF is really nice. (Source: me. Cissp and a couple decades of professional experience with open source and proprietary firewalls).
And if they are already using it on openbsd, it’s almost certainly an easier lift to move from one BSD PF implementation to another versus migrating everything to Linux and iptables.
I've gotta me-too this. I've written any number of firewall rulesets on various OSes and appliances over the years, and pf is delightful. It was the first and only time I've seen a configuration file that was clearly The Way It Should Be.
I'm pretty die-hard Linux, but I had a client who needed to do traffic shaping on hundreds or thousands of this ISPs users. I've tried multiple times to get anything more than the most simple traffic shaping working under Linux, with pretty bad luck at it. I set them up with a FreeBSD box and the shaping config, IIRC, was a one-liner and just worked, I never heard any complaints about it.
I've run a lot of Linux firewalls over the decades, but FreeBSDs shaping is <chefs kiss>
What features have you used for shaping with pf/FreeBSD? I remember (around 8ish years ago) using dummynet with pf, but it wasn't supported out of the box and I used some patches from the mailing lists for this purpose. It wasn't perfect, at times buggy. Back then ipfw had better support for such features, but I didn't like the syntax just as much as iptables. I eventually settled on Linux as I have grown to understand iptables (I hate that nftables is the brand new thing with entirely different syntax to learn again... and even requires more work upfront because basic chains are not preconfigured...) but traffic shaping sucked big time on linux, I never understood the tc tool to be effective, it's just too arcane. I always admired pf, especially on OpenBSD since it had more features but the single threaded nature killed it for any serious usage for me.
The user interface is literally 1000x better. That's all
Linux is enormously higher performance but it is a huge pain in the ass to squeeze the performance out AND retain any level of readability
which is why there are like a dozen vendors selling various solutions that quietly compile their proprietary filter definitions to bpf for use natively in the kernel netfilter code...
Too many random changes, too fiddly to maintain, too much general flakiness. Especially for simple single-purpose devices that you want to set up once and leave alone for years, BSD is generally much nicer than Linux. I'd actually flip your question: why would you ever use Linux rather than FreeBSD?
Do you have any specific examples where a Linux-based firewall was too "random" or "fiddly" or "flaky"? Or provide examples of ways that BSD "much nicer"?
It sounds to me like you picked a bad Linux distro for your use case.
I've seen plenty of single-purpose Linux-based network appliances, and none of them have come across as flaky or unreliable because of the OS. In fact they can be easier to use for people who have more operational experience using Linux already.
> Do you have any specific examples where a Linux-based firewall was too "random" or "fiddly" or "flaky"?
They switched out ifconfig for some other thing. There's been about 3 different firewall systems that you've have to migrate between. Some of the newer systems (docker and I think maybe flatpak/the other one) bypass your firewall rules by default, which is a nasty surprise. A couple of times I did a system upgrade and my system wouldn't boot because drivers or boot systems or what have you had changed. That stuff doesn't happen on FreeBSD.
I'm sure to someone who lives and breathes Linux, or who works on this stuff, it's all trivial. But if it's not something you work on day-to-day, it's something you want to set and forget as an appliance, Linux adds pain.
> It sounds to me like you picked a bad Linux distro for your use case.
Were there any grounds at all in what I said for thinking that, or did you just make it up out of blind tribalism?
> In fact they can be easier to use for people who have more operational experience using Linux already.
Of course, but that's purely circular logic. Whatever OS you use for most of your systems, systems using that OS will be easier for you to use.
tcp_pass = "{ 22 25 80 110 123 }"
udp_pass = "{ 110 631 }"
block all
pass out on fxp0 proto tcp to any port $tcp_pass keep state
pass out on fxp0 proto udp to any port $udp_pass keep state
Note last rule matching wins, so you put your catch-all at the top, "block all". Then in this case fxp0 is the network interface. So they're defining where traffic can go to from the machine in question, in this case any source as long as it's to port 22, 25, 80, 110, or 123 for TCP, and either 110 or 631, for UDP.
<action> <direction> on <interface> proto <protocol> to <destination> port <port> <state instructions>
The BSDs still tend to use device-specific names versus the generic ethX or location-specific ensNN, so if you have multiple interfaces knowing about internal and external may help the next person who sees your code to grok it.
One thing unexpected I found when setting up an OpenBSD based router recently: the web isn’t riddled with low-quality and often wrong SEO and AI slop about OpenBSD like it is for Linux. I guess there just isn’t enough money to be made producing it for it for such a niche audience.
If you search up a problem, you get real documentation, real technical blog posts, and real forum posts with actual useful conversations happening.
I've been using OpenBSD and PF for nearly 25 years (PF debuted December 2001). Over those years there have been syntax changes to pf.conf, but the most disruptive were early on, and I can't remember the last syntax change that effected my configs (mostly NAT, spamd, and connection rate limiting).
During that time the firewall tool du jour on Linux was ipchains, then iptables, and now nftables, and there have been at least some incompatible changes within the lifespan of each tool.
PF is also from 2001. But its roots go further back, I once used a very PF-like syntax on a Unix firewall from 1997. I forget which type of Unix it was, maybe Solaris.
Either way, I don't think there is any defense for the strange syntax of IPtables, the chains, the tables. And that's coming from a person who transitioned fully from BSD to Linux 15 years ago, and has designed commercial solutions using IPtables and ipset.
El Al 1862 was another flight [1] that had an engine fall off, taking another engine out with it. The pilots managed to fly around for a few minutes and attempt a landing, but there was too much structural damage.
It doesn't seem aircraft are designed to survive these types of catastrophic failures.
This blog post isn't human speech, it's typical AI slop. (heh, sorry.)
Way too verbose to get the point across, excessive usage of un/ordered bullets, em dashes, "what i reported / what coinbase got wrong", it all reeks of slop.
Once you notice these micro-patterns, you can't unsee them.
Would you like me to create a cheat sheet for you with these tell tale signs so you have it for future reference?
Overuse of bold markup, particularly to begin each bullet point.
Overuse of "Here's..." to introduce or further every concept or idea.
A few parts of this article particularly jump out, such as the 2 lists following the "The SMS Flooding Attack" section (which incidentally begins "Here's where..."). A human wouldn't write them as lists (the first list in particular), they'd be normal paragraphs. Short bulleted lists are a good way to get across simple bite-sized pieces of information quickly, but that's in cases where people aren't going to read a large block of text, e.g. in ads. Overusing them in the wrong medium, breaking up a piece of prose like this, just hurts its flow and readability.
Tailscale now has the awesome feature of peer relays and now there's no more excuses why you can't traverse that NAT and you can forget about all those DERP servers.
Interesting idea, but their PR piece mentions a "failure at a primary data center" which at face value does not sound like a cert issue, and CT logs for *.alaskaair.com show lots of certs issued every single day, but nothing that seems mission critical around October 23 or 24.
reply