Messages

[...]I may need to buy a few more 2.5g transceivers[...]

I'd dig into the reviews/fora for experiences with individual products. Good luck.

Is a downstream shaper (particularly a single queue) likely to have the effect you want? I used downstream shapers in the past, but my purpose was to control offered load by adding latency, using multiple queues on a CBQ shaper. I didn't bother after my link passed 10Mb; it did help at 6-10Mb.

I'd think a simple fair queue with no shaper would be the best option for you. I don't know the best way to accomplish that - perhaps open the pipe beyond 520Mb/s (toward single-station LAN speed). I haven't looked at the fq-codel implementation in... a while. The one I recall used a flow hash, and you could set the number of bits (up to 16, I believe). It looks like the ipfw implementation has that limit (65536). I'd think more can't hurt - fewer (potential) collisions. I wouldn't expect any negatives, but you never can tell. PIE just sounds like a RED implementation - I can't see that it'd have much if any effect, as I wouldn't expect your queue depths/times to reach discard levels.

Of course, you could have upstream issues, at any point in the path.

My guess would be a piece of small office networking equipment, such as a web-managed switch, with DCHP off (so it autoassigns an IP). 94.16.122.152 is likely from pool.ntp.org (I didn't bother to confirm), but how the client would look it up without an appropriate IP is a bit of a mystery (perhaps a cached lookup).

I have a few switches of that type. At times I've just let them chat away, but I usually go in and hard-configure them to communicate (management traffic) on port 1 only (generally by setting the other ports to a VLAN other than 1).

Hostnames are two different new columns when you check it.

You know, I didn't even note that. Similar principle, though.

templates are just for the filters I think. [...]

Yeah, I was just thinking about a possible way to save/restore multiple column layouts.

Time is truncated and Source and Destination have a lot of wasted space. That's at least how I see it.

Source and Destination have extra whitespace for "Lookup hostnames".

Heh: Perhaps a good application for a template?

[...]And since there are copper versions of the X710 (X710-TM4 & X710-AT2) which do support 2.5 and 5Gbit[...]

Versions... some of the early ones do not, so if you're planning on getting one for that purpose, get a newer one. I forget where that detail is documented, and you can't determine chip version readily without running the card in any case.

[...]But some cards/chips seem not to be able to work with 1/2.5/5G/10G tranceivers in 2.5 or 5G mode.[...]

Yeah, lots of (well, only several, really) different transceivers, too. Some will autonegotiate, some will not; some will use the 10Gb clock, some will not. And of course most run like burning weenie roasters, which would be even more unpleasant in a quad-port HHHL card.

Interesting design. I wonder if there's a way to expose the Nuvoton chip (NCT6683D-T monitor/fan controller). FreeBSD support would likely be pretty limited - perhaps the superio driver has some support. Should be irrelevant to normal operation; the card apparently has an overheat LED and external signal (JP2). For the heck of it, check the DIP switch settings.

Definitely check the NVM version. That should be about it. I wouldn't expect firmware locks (for SFP optics) on a Supermicro card.

IDK how you got the <WAN_GATEWAY_IP> into that rule at all, since I do not see where you could select that from the UI.[...]

Perhaps "reply-to" under "Advanced features"? (I didn't test it.)

penguingl might want to pass it with no destination. But that route-to is unusual.

I missed that. Confirmed, columns seem fixed. I didn't think "firewall: live log: make this grid static and slightly adjust info column width" meant that. Static columns seems an odd choice, if it was deliberate.

Nitpick: It'd be nice if the line shade was consistent - not by position (as it is now), but by element (so the text shade remains the same as it scrolls). I find the changing light/dark shading makes it harder to follow a particular entry.

I went with minisforum but, the one I have does draw 100TDP (I have metered it) whilst far from max load.[...]

Interesting. I don't know what BIOS settings are available for the Minisforum, but the AMD processors are highly configurable. 100W from a 16 core device isn't surprising, even with the 55W/75W "TDP". With a bit of tuning you could get maximum single-core clock with a reasonable power limit. I don't see high CPU utilization from my firewall (7700X, X710-DA4, X550-T1; it normally runs idle, at around 40W), but my Internet link is much slower than yours (500Mb) and I do not use an IPS. At any rate, to paraphrase Brandywine, buy once, cry once, and you won't regret getting a solution that's too small for the job. In most areas of the U.S. the price of your Internet link would make the firewall seem like small change.

Not at all easy to integrate (lots of moving parts)[...]

In context I wouldn't consider it particularly difficult, but it's not basic. Identifying all of the affected elements would be a pain, especially if they're not well encapsulated (as nobody does that).

I also think that VRFs are not that useful in firewalls[...]

I'd disagree there. But I will grant that it's a bit of a niche feature, and not popular with the OPNsense base. Part of the reason for that is that for most scenarios rule-based forwarding would work about as well; another part is the chicken/egg problem, but that merely partially contextualizes the lack of demand. From a cost-benefit value standpoint it looks pretty dead.

[...]It would need multiple FIBs (aka virtual routing instances)

Speak of the devil... (Link included for future reference, not that anyone wants to look at it.)

[...]I have 5 PPPoE lines from the same ISP.[...]

I have to say, when I said (paraphrasing) multiple FIB support would be useful, this isn't what I was thinking of. Ouch.

Forgot to mention: frr. Should support fibs; I haven't used it.

There have been a few discussions of this in the fora; I didn't see any relevant github requests.

Would anyone be up for FIB/VRF support?

It could be implemented pretty simply. As with many OPNsense features, you could use VRFs/FIBs to really screw yourself up. But I think the feature would be quite usable. The beauty is that default behavior would not change in any meaningful sense, and it could be tested to a considerable extent without (GUI) implementation.

Details:

Possible kernel compile option: "options ROUTETABLES=n". Apparently the standard kernel can be configured (using "net.fibs", as below) for at least n=2. Appropriate setting? I imagine it would depend on impact, if any.

System:

• Settings:
• "net.fibs" in loader.conf. Not sure where to put this setting (General -> Networking, as "FIBs" or "VRFs"?). It would be used as an interlock for most of the settings below. Interlock behavior options: vanish/gray/do nothing/error on setting; zero/ignore fib settings when "net.fibs" is unconfigured.
• "net.add_addr_allfibs" - I would make this a tuneable, default 0. I'm not sure if this setting is still available, or if it will be in future versions.
• Gateways:
• Configuration:
• "fib" setting for the gateway.
• "fib" column (not selected by default) for the display. I would display data from all fibs, using "setfib n [command]", as n=0 should always be valid.
• Routes:
• Configuration:
• "fib" setting for the route.
• "fib" column for the display, as above.
• Status:
• "fib" column for the display, as above.

Interfaces:

• [Interface]:
• "fib": integer

Firewall:

• Automation:
• Filter:
• "fib" column for the display, as above. I would include this as the current display has lots of options.
• Rules:
• [Interface]:
• Interlock: for "Action" = Pass, "Direction" = In: "fib" (pf "rtable") setting: integer.

I've likely missed (quite) a few... e.g. "fib" for ping, trace.

Possible caveat: "route" may be fussy with fib > 0 - it might require an "up" interface in the fib in order to add routes. I'm not sure if this is a non-default behavior, as I haven't tested it.

Forgive me if I fail to understand the setup but aren't these two ends only access ports in reality? What is marking the packets with a VLAN tag if there is no managed switch there to do it?

The endpoints/access ports. It's segregation with extra steps. Without virtual system or VRF support it's (almost*) entirely rule-based, but what the heck, it's a choice. The bridge adds a bit of a twist, but I can't think of anything really unique about it as described. Setting up VLANs might make insertion of a switch at some point easier.

In this case, it's a troubleshooting opportunity, so to speak.

And of course there may be aspects I'm missing.

* You could get into different Ethernet attributes, but again, I can't think of any real difference between VLAN segregation and none.