Messages

[...]I do feel the decision all those years ago to keep the custom multi threaded PF over keeping up with OpenBSD PF has continued to hunt FreeBSD.[...]

Improving FreeBSD's pf is an obvious goal, but pining for OpenBSD's implementation doesn't seem realistic. Unfortunately any attempts at real improvement would run straight into the politics being discussed here.

Just to be sure, have you tried multiple cables and endpoints and/or checked the cable and sockets? Normally failure to negotiate 1000BASE-T and success at 100BASE-TX indicates missing/no connection in positions 4/5 or 7/8.

[...]Can the functions be added to Linux's kernel, and would it make sense, if someone was to convince Linus about the importance of it?

Heh. Even the reprogrammed, sensitive and politically correct Linus would have some choice words about that.

Why not get serious and add a pf (filter) and IPFW (shaper compatibility layer) plugin to VPP? No kernel mods required. Porting OPNsense (and maintaining the port) would be a bit of a nightmare. And VPP itself is a moving target - there's a reason it's not packaged for any distro (that is, available via a package manager [Edit: standard repository. I knew what I meant.]).

It's not exactly a one VLAN limit but a four zones total limit as I found out. For whatever reasons. Seems silly.[...]

IPFire (or its progenitor) actually implemented very limited VLAN support (one VLAN per interface/zone...?) before Ben Greear's VLAN code was upstreamed, and they kept that model for historical reasons. From "Zone Configuration":

Code Select Expand

Please note that:
- Due to backwards compatibility reasons, you can't assign more than one VLAN to a zone
- One NIC can't be accessed natively by more than one zone
- You can't use the same VLAN tag more than once per NIC
[...]

IPFire is definitely its own thing.

Again: why not simply use an existing Linux based firewall product like IPfire?[...]

Heh: Did they ever fix their one-VLAN limitation?

It's too bad Vyatta was sold so many times. A victim of endless management musical chairs. DANOS was kind of interesting. I imagine Ciena will dump it if AT&T and IBM stop paying for it.

Nothing's perfect but Linux gives me an uneasy feeling with all the different directions it's going in and how fast it's moving.

Time to revisit GNU Hurd? OpenBSD? OpenIndiana? NetBSD? Haiku? Resurrect open-source QNX?

I agree, though. I spend a lot of time configuring my servers, and I want to avoid having the rug pulled out from under me. As Windows and Fedora do constantly. Or Debian's SystemD intro. Or Spengler closing GRSecurity. Bleh.

[...]I saw on the openSUSE fora[...]

Rumor has it SUSE's up for sale again. Which makes me wonder what SAP is up to. Oh well.

The entirety of pf(5) does not exist on linux.[...]

I would have gone for an abstraction layer. But then, I'd still be working on it instead of having a working product for 10 years. Reality intervenes.

If the packets never touch the cores doesn't it make just a glorified switch running at wire speed?[...]

He didn't say "all". Policy evaluation and flow setup is done by pf, and flows are passed to the engine. I'd have to dig into the coordination between CPU and engine to see if, for instance, expiry is updated, age is honored and teardown is correctly reflected in pf, and if counters are maintained. I doubt the last, but you never can tell. Thinking about it, I would expect logging to be normal, as pf logs are pretty limited anyway. Coordination failures could be tough to diagnose.

I'd expect the device to fall flat on its face if its flow limit is exceeded, either through eviction to the CPU or (more likely) discard. But I haven't exceeded ~10000 active flows, so its limit is likely OK for normal use. Most users will see far fewer, and are minimally vulnerable to external flow setup attacks. (I am, as I have servers with standard ports open to the Internet. On the other hand, I don't use proxies and such, so processing required on the firewall is... reduced.)

And why suddenly use Offloading while it's always recommended to disable all of it for both OPNsense and pfSense ?!

Because it does not work reliably on generic AMD64 hardware and Intel/Broadcom/etc. network interfaces? [...]

Just to expand this a bit, there's a lot of odd, somewhat useless (in practice) capability built into PC network interfaces. If you're bored, look at DPDK's NIC overview.

Example: the Intel E810 has a tiny (8000 entry, IIRC) TCAM, and it (the chip, not the TCAM) is used in several Deciso boxes. It's really too small for a useful flow cache, but it could make a decent partial policy offload (basically everything but address - which it can handle, but something like a geoip db would overflow it a bit).

Another example: the Chelsio T5/6/7 NICs have a truly tiny (~500 entry IIRC) TCAM, and some have onboard RAM that can support exact-match filters, potentially good for flow matching. They have some header rewrite capability, too (e.g. for NAT). The T6/7 also have a crypto engine (with a FreeBSD driver).

At any rate, the problems tend to arise when you globally enable features in a mixed-NIC system. The failure mode for unsupported features should be graceful...

I didn't see this flying around, and someone had to start it, so I figured I might as well.

An NXP-based router that... should support OPNsense. I wonder about the hardware offloading, as I figure it would play hell with monitoring/logging.

It looks like the first development kit sale has closed, awaiting a second or production run. Hopefully they make it, but it's a tough market.

Maurice, do you have one?

[...]Parent interface: igc1[...]

Code Select Expand

igc1: flags=1028943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,PPROMISC,LOWER_UP> metric 0 mtu 1500
    description: vlan1_lan (lan)
[...]
    inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
[...]

I do not configure the main interface that I use for VLANs, as it doesn't fly at all when using bridges. I can't say if it's your issue, though - too many differences in our setups.

[...]The throughput has drastically changed. I tested directly on the modem with a laptop and I'm able to get around 800Mbps D / 300 Mbps U using fast.com or speedtest.net . Yes this is not the speed I use to get but the upload is really what I rely on. The throughput of opensense has taken a dive and I'm not even sure where to begin.

Ugh. That doesn't narrow it down much, unfortunately. Could even be something like a modem firmware push. Or multiple things, just to be even more irritating. I'd try to get a line test (upstream of the modem, assuming you haven't already). In addition to any other troubleshooting. Oh, and this might be barking up the wrong tree, but I've had to deal with a few silent, erroneous service downgrades in the past. You might want to verify your service (as much as possible, from an administrative standpoint). (I worked for my provider, so I had internal visibility and contacts, and it was still a pain in the ass.)

[...]I'm asking:[...]

Can't help you there, but two things to look at, if you haven't already: "ifconfig -v" (I just throw in the -v to get optics info) and "netstat -r", to verify all (and I mean all, pedantically) config data.

Hm... Their presence would suggest configured interfaces. If you had deleted them, that's an interesting data point. I haven't personally seen OPNsense fail to clean up something like that. Something to watch for.

Those are (almost certainly) basic anti-spoofing rules, if you look closely at them. Defaults. The only time I hit them was when I had the main (untagged) interface configured as well as VLANs (on the same interface), where VLAN-tagged traffic was improperly captured by the main. A possibility?