Messages

You should see the IN on the GRE interface, so maatch rule allowing or denying ICMP on GRE interface.

Show your rules.

Regards,
S.

You have 2 FWs.
FW A and FW B

If the connection is established from FW A, the Ingress Rule on Site B is matched and should visible as IN.
While on FW A it will be seen as OUT because its Egress.

When the packet comes back from FW B to FW A, you will not match the rule as IN on FW A. You dont do a lookup anymore.
Because there is already a state/session created by FW A when it established connection towards FW B

A Session/State on FW, is matched only once per Interface and accounts for both directions based on 5-tuple (Protocol, Source IP & Port, Destination IP & Port).

Regards,
S.

Inbound is on Ingress, meaning packet coming IN to an Interface.

When you use overlay technologies such as GRE, the Ingress is triggered on two stages;
1. The Underlay Interface to allow the GRE > sees only the outer IPv4 header so tunnel source and destination
2. The GRE interface itself > sees the inner IPV4 header so source and destination after de-capsulation

If a session is opened for such connection it will not appear again in the live log as long the session/state in FW is active and not either expired or closed.

Show your Ingress rules, and check State table in the FW.

Regards,
S.

But the first thing that came to my mind after reading the title : Why ask this on the OPNsense Forum ?!

This + Upgrade your BIOS.

ASsrock is know to have random problems due to MOBO firmware.

Regards,
S.

Worth keeping in mind: with quick-match rule evaluation (the pf default), the first blocklist rule that matches gets the hit, and the packet never reaches the rules below it

You are right on that. I use qfeeds on the TOP of my Block policy and community one right bellow.

Comparing one to another, so qfeeds to the community projects is a bit as comparing apples to oranges. Because the quality is different between them.
Qfeeds targets and aims to provide more granular filtering, so meaning even if qfeed block-list doesn't block something yet the community one does it doesn't mean something leaked/malicious.

I had more false positives with Firehol block-lists compared to qfeeds.

Regards,
S.

Hello mb,

Personally I do understand, why you would not want to implement Multi-core support into the HOME subs. As you mentioned yourself, companies are already abusing it. But on the other hand for us, the Home LABers and community Home sub, is ours to use.

We often over-exceed the deployments of SOHO/Medium sized Companies, just for the pleasure of fun/learning or personal need. While trying to be power efficient.
And exactly here is where a lot of us already are beyond 1-2.5G LAN speeds and need 10G InterVLAN throughput.

We mostly do not need any of the SASE features, but we need the raw performance.
The base features in Home sub are perfect for Home use, but the performance is a hurtle.



I do not want to go bad at you but,

Maybe it would be a good idea to have more awareness about the "SASE Starter" program here on the forum for people in the community.
As this would sooth the peoples worries.

The whole point why people were outraged in first place, was the uncertainty and lack of communication around the Multi-core support.
1. It was not properly communicated
2. People had to literary data-mine information about the Multi-core
3. When directly asked about this, nobody from ZA provided a direct answer


Similar to cookie & dinguz,
I myself allocated a lot of time Tshooting ZA, problems, BUGs and even finding few attack vectors. Sharing all of this with support, having bridge calls & con-joined Tshooting. Working with your engineers & developers is a pleasure, because they know what they are doing if they get all the pieces of the info.

So you can imagine now, how back-stabbed it felt to see that Home subs will not receive the MC support and communication around it was very bad.

Regards,
S.

o my speeds should go up a little, and still running 16gb of ram to cache the rules (when possible).

And this is the problem, up a little yes but if you need 10G IntraVLAN you are basically out of options with ZA.

Regards,
S.

That purely depends for what are you aiming,

ZA & Suricata are IPSes, ZA is more of a L7 FW.
Q-feeds & Crowdsec are block rulesets so L3 packet filter.

In brief:

ZA & Suricata Benefits
Higher layer inspection.
In case of ZA top notch Reporting capaple of drilling and troubleshooting.
If you want to inspect and block traffic based on vectors than Suricata & ZA are for you

ZA & Suricata Negatives
Huge performance hit.
I am not sure how Suricata performs now, but in case of ZA you will be capped at single core performance.

Q-feeds & Crowdsec Benefits
NO performance hit.
Simple deployment, Q-feeds for example provide just set of malicious IPs and Domains that can be used on any rule in any way you want.

Q-feeds & Crowdsec Negatives
Simple L3 packet filter, do not expect anything fancy.
Manual implementation.

If I would choose one, I would go with Q-feeds + extra community based blocklists such as Spamhause etc. (I have this now as well + ZA). No performance hit a good pool of malicious IPs that can be blocked out by a Rule or a Policy.

One note to point out, Q-feeds maybe doesn't have in device build reporting, expect the one that pools from logs. But their web TIP is extremely good and detailed. I pay for the Plus sub, and the features it gives are worth it.

Regards,
S.

The Pause frames received are just 3 if this is pasted from the latest visible issue

dev.igb.1.mac_stats.xoff_recvd: 3

In case the peer cant keep up it would be a constant flood of Pauses.

Regards,
S.

RX Pause frames is part of the flow control suite,
are an indication that the other side (device connected on this port) is not capable to keep up.
If this happens device that receives the Pause Frames, if supported and enable will throttle down effectively decreasing pps.
Flow control is a suite that throttles the connection in order to not overwhelm the receiver or sender and prevent possible packet drops.

It is advised to disable Flow control between network devices, such as FW, router, Switches etc.

Link Flaps
So if you see flapping during high load, be it throughput or pps this is not good, could be caused by ASPM.

Try to disable it.

Regards,
S.

Triggers:  Multiple, the one I found for testing was playing the video game Overwatch while doing an Ookla speed test in a web browser

What is your PPS (packet per second) when you see the degradation?
Cause this potentially indicates that your HW can not cope with amount of packets sent thru the system.

Regards,
S.

Some tunables are specific those per NIC. So you need to know what nic you use for example if you have ax than tunables with igc will not do anything.

If a tunable is not anymore available in FBSD, than in the UI it will be flagged and you will see a message next to the tunable that is unknown or something like that.

Regards,
S.
 

But I didnt say anything about a switch/L2 loop :)

I am not saying that there is not a potential BUG.
I am just saying you should have protection against BUM traffic no matter if its or is not a BUG.

Regards,
S.

In the production DC we have MLAG to catch the complete loss of a single switch. I *think* we use 30s - which is good enough for hosted web applications, IMHO. STP convergence is in the same time range. Flapping of course is a different beast altogether and somehow even worse than a complete loss of connectivity.

Yea MEC, MLAG or VPC are the ultimate form deployments you want in Production.
Flapping on a LAGG is always a story on it self. And you are right on that, this is causing even worse problems than if it would just die.

So essentially strict mode clears some of the information received by the partner because these fields are (supposedly) not part of the 802.3ad standard. Looks like more or less a no-op to me. See the "XXX" comment above.

I'll re-enable it and whatch what happens.

I always thought that the Strict mode enforces the usage of LACP within the LAGG. Meaning if both sides are not actively talking proper LACP the LAGG will not establish....

Regards,
S.

I am not surprised you configured Fast timeout.
The 1s re-convergence vs 30s is a BIG deal.

But if its not working as should, it causes more troubles, cause in worst case scenario it can cause insane micro-flaps.
I have seen outage windows for 5-15min with Fast timeout...

Regards,
S.