Messages

It would probably be a challenge. I can't find a hardware spec offhand, but 2 or 4 cores at 400, 800, or 1000MHz sounds like an embedded device, most likely ARM32. Ethernet is likely provided by a switch chip. Neither device type is well supported by FreeBSD (or any other general-application OS).

It will support VPP, and thats something that BSDs dont have.

It's not exactly turnkey, but it can be compiled with both netmap and DPDK. VPP seems to be in a perpetual alpha/beta state.

[...]redistribute bgp route-map Only_Default[...]

I'd expect that form to be available, but I'd have to have a good reason to redistribute much of anything into RIP.

Do you have another potential default route for RIP clients not through the firewall? If not, perhaps "default-information originate" into RIP would work.

Have you dug into the FreeBSD proc filesystem ("mount -t procfs proc /proc")? I haven't looked in there in a while... never can tell. Would session/rule counters give you what you want?

Offhand I'd guess that the protocol-specific counters are "terminated on device" rather than "forwarded". The statistics do not appear to be clearly defined (from a quick scan of the docs).

both modules are very hot to the touch. I was wanting to limit to 1Gb to see if it helped

It should. Most SFP+ devices can accept SFPs... but my limited experience with such is... mixed. In addition, some 1000BASE-T SFPs are quite low power, and some are similar to your existing SFP+. Caveat emptor.

SX and LX are short and long-wave optics, respectively. CX is STP, KX is PCB (base signaling, e.g. SFP). Most appropriate of those choices would probably be KX. Note the "most" - it may not be appropriate/functional. You seem to have connectivity (at default settings? 10GBASE-T?)... The module has moderate (advertised) power consumption - 1.8W. If it works, you may be stuck with it.

I don't see that behavior offhand, although I didn't check my larger aliases (e.g. bogons). So it seems unlikely to be a table optimization, as I have several aliases that contain subnets of others and are evaluated in the same ruleset.

How reliable is Firewall:Diagnostics:States for troubleshooting

[...]
HPE ProLiant DL360 Gen10
2x 8-Core 3,3GHz / 4 GHz Turbo with 16 Threads
1x 4x 1GbE LOM
1x HPE FlexFabric 536FLR-T (4x 10GbE)
32GB RAM
[...]

Just a couple clarifications...

32GB RAM? How many DIMMs? I'd forgotten how many channels the FCLGA3647 can run (6) - (potentially) giant bandwidth.

The FlexFabric 536FLR-T threw me, as apparently both Broadcom and Marvell have "57840" quad 10GbE controllers (perhaps both had QLogic IP or some such). I assume it comes up as a NetXtreme II?

[...]They are handled by the Layer3 Switch. Just routing, no firewalling, nothing...
Security is technically not existend with that setup.[...]

Is your intent to add security? I ditched my L3 switch(es) to go with a flat network where everything runs through the firewall. I even use my (current) switches as port expanders only (each end-station port with a unique VLAN). I have a small network with a relatively large firewall, so it works for me. Your Xeon Gold 6234s should give you decent throughput... One way to find out.

As said, with the OpenBSD6.8 I don't get any errors like that.[...]

Yup. I'd just like to know what the issue ends up being, when you find it. Out of curiosity.

[...]I will eliminate the switch as default gateway for the complete 192.168.x.x block and replace it with the Opnsense as default gateway.

Heh. I wouldn't do that, as you'll send traffic for the other two segments (192.168.100 and .140) to the firewall (presuming no specific routing on stations on the 192.168.10 segment, and a potential performance impact). You could create a stub VLAN with a /30 between the firewall and the switch to eliminate any asymmetry... if necessary. I assume you already have static routes in the firewall for the other segments, so another isn't an unusual addition.

[...]I am stepping here in some sort of asymetric routing, since the OPNSense Interface is on the same Network as the Server 1 it try's to send the traffic directly back to Server 1 instead over the Layer3SW. This somehow let the statetable not match the traffic and the packages are silently dropped.

In the Livelog GUI i just see the "pass" packets and nothing else, even after enabled logging of "everything". NAT, auto generated rules, default block, etc.[...]

That's not a layer 3 (IP) asymmetry. I wouldn't expect OPNsense to care about the source MAC, but I haven't had a similar routing arrangement in... a couple decades (prior to OPNsense). Packet flow should be visible in the session counters ("Firewall: Diagnostics: Sessions"). I don't think packet capture (on the firewall) would be more enlightening; you could check the switch. I can't think of a mechanism (on OPNsense) that would discard silently under this condition. To test, you could kill the L2 asymmetry with a route on Server1 for 172.32.16.0/24 (to 192.168.10.254).

Similar issue: Firewall rules and aliases.

Likely inconvenient on a running firewall, but: I'd check "Firewall: Diagnostics: Aliases" to make sure the member elements appear as you expect. Also, check the "Statistics" box in the alias definitions to look for rule matches (pass rules only). I'd also look at "Firewall: Diagnostics: Statistics" -> "rules" to make sure the rules are defined as you would expect.

Could be a bad rule expansion - the diagnostic view may be enlightening.

There is a bit of discussion over at Netgate. As far as I can tell the action appears to be correct (scrub rule); the logs could be a behavior change in pf.