First, a bit of history -- two years ago when I commented on this thread the stability of master wasn't what it was today, by a long shot, and the packages tended to lag far behind even "conservative" distros like Ubuntu, Debian, and FreeBSD. That has significantly improved, to the point where it is rare that any day's build off master has any issues of significance.
On security, FreeBSD provides two features that I consider critical for a security appliance as important as the border firewall.
- True immutability of the file system
- Ability to prevent any changes to the firewall rules
At least as far as I know, Linux, while it has an immutable flag, it can be cleared by anyone with root access. For me, this is far less secure than running FreeBSD with the kernel set to secure level 2 (secure level can only be increased in a running system). Linux, as far as I know, also can't lock down the firewall rules the way that secure level 3 does.
1 Secure mode - the system immutable and system append-only flags may
not be turned off; disks for mounted file systems, /dev/mem and
/dev/kmem may not be opened for writing; /dev/io (if your platform
has it) may not be opened at all; kernel modules (see kld(4)) may
not be loaded or unloaded. The kernel debugger may not be entered
using the debug.kdb.enter sysctl. A panic or trap cannot be forced
using the debug.kdb.panic and other sysctl's.
2 Highly secure mode - same as secure mode, plus disks may not be
opened for writing (except by mount(2)) whether mounted or not.
This level precludes tampering with file systems by unmounting
them, but also inhibits running newfs(8) while the system is multi-
user.
In addition, kernel time changes are restricted to less than or
equal to one second. Attempts to change the time by more than this
will log the message ``Time adjustment clamped to +1 second''.
3 Network secure mode - same as highly secure mode, plus IP packet
filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be
changed and dummynet(4) or pf(4) configuration cannot be adjusted.
On pf vs. ipfw, I've been writing ipfw rules for over a decade now, close to two probably (since FreeBSD 4) and know how it behaves, know how it handles "dropped" packet buffers, and know many of the ways one can make "mistakes" in crafting a rule set. Since I don't use the "convenience" of GUI-driven firewalls, they are about the same to me otherwise.
For me, if I can't read and understand exactly what all of the rules are doing, it's blind faith. I don't find iptables to be readable in any reasonable way. I find nftables, even with its current set of faults (which are mainly around error reporting), to be much more readable and understandable to me.
An additional value of FreeBSD and now, to some extent, Debian (or other distros that support ZFS on Linux), is being able to run on mirrored ZFS. Between the reliability of storage and the ability to take, compare, and even send snapshots to another host, this is something that I find invaluable. The boot integration of Linux-based OSes with ZFS is primitive by comparison to FreeBSD, but functional. As I run dedicated, OpenWrt-based APs and I generally don't configure using LuCI, once the hardware is powerful enough to run a server distro, the amazingly light footprint of OpenWrt and outstanding wireless support doesn't have the same advantages on an x86_64 with 4 GB of memory and dual SSDs that it does on an SoC-based device with even 128 MB of flash and 256 MB of memory.
