Long term I'm thinking I'll move things over to ARM/MIPS based routers running OpenWRT, and where needed I'll use x86_64 boxes with OpenWRT (eg: Tor Relay at home) as when things break on OpenWRT, its a lot less bad than on BSD.
In particular, I've had issues with BSD taking forever to boot (waited 4hrs at 3am once), deciding it needed an Intel NIC firmware when it had no Intel NICs, thus causing an outage while I drove down there with a WNR2000v3 running OpenWRT, and LTE backup interface handling being poor, whereby the cellular connection will go out (and we'll send a command to the SOAP API on the modem to reconnect), but PFSense needs to cycle the interface for some reason when it already has an internal IP from the modem. Combine that with having to walk customers through any one of these scenarios every few months over the phone, and its a joyous situation.
Sounds like you're using a USB based modem that runs its own software stack. We tried that, and it went terribly. Issues similar to the one you mentioned.
Life is much, much better if you buy a mini-PCIe module and use Linux utilities to manage it. We've had zero problems since dumping our USB modems (Huawei junk) and buying proper cards (also Huawei, but surprisingly not junk).
OpenWrt is nice, but the packages are limited. Also their release cycle is glacial, so we frequently end up building from trunk because we need some fixes which aren't in the current stable release (15.05.1 is almost a year old!).
Wrt OpenWRT being aged, not too worried there, I'm still running Debian Jessie over here :P
Yeah but it's a problem. Debian Jessie still gets security updates regularly. OpenWrt doesn't. The only way to upgrade the kernel and core packages is to reflash with a newer image. An annual release cycle is an issue for embedded devices you want to keep secure.
I've heard about them for years, but just started using them in the last 12-18 months. So far, I've been very happy with the performance and features for the cost.
However, Android doesn't work at all. I suspect it's a configuration issue, but the lack of meaningful logs makes it damn near impossible to troubleshoot.
If you happen to run an all Mikrotik routing environment, the SSTP tunneling works well. I have a customer with hundreds of Mikrotiks out in the field, each with an SSTP connection back to a cloud-based Mikrotik installation for remote management/monitoring.
SSTP supposedly works with Windows clients too, though I've never tried it.
In terms of being a firewall, there's no difference. Both will open and block ports as needed.
Where BSD excels over Linux is in the traffic shaping/manipulation capabilities. pf lets you simulate just about any kind of link you want (e.g. want to simulate a satellite connection with accurate latency? or want to simulate a 2G connection with high latency and high packet loss?)
So, as a static firewall, Linux/iptables is fine.
If you want to do any kind of link simulation or complex traffic shaping, BSD is far better.
I was using pf to simulate links with specific attributes (e.g. latency, packet loss).
Reading the documentation of tc, it seems like it would accomplish what I was doing. However the documentation I found for tc was quite old (mentioning kernels 2.2 and 2.4).
Is there something wrong with that?
I'm not trying to be an ass, just curious.