Messages

https://github.com/opnsense/core/issues/10615

Hi @SonicJoe,


that was my first assumption. I disabled the divert to of the rules that allow the flows. But in my case it did not help. I also checked the corresponding logs for suricata and could not find any blocks. For example "dest_port:123" should trigger a hit in the suricata logs, as this was blocked.

@franco: Help please

Welcome to the wonderful world of BSD, Karla!

As much as we all love the colorful, fast CLI magic of pacman(well I prefer apt/dpkg), expecting an enterprise-grade firewall GUI to behave like an Arch Linux terminal is a bit like walking into a modern car cockpit and asking for the gear shift of an 80s truck.

OPNsense keeps things a bit more structured under the hood for a reason. Hang in there... you'll get used to the Web-GUI life soon enough!

But if you want you can use my monit update howto and send yourself some nice ASCII Art via Mail ;D

I have now found another example which does not involve hairpin access to an internal server.

Code Select Expand

vlan0.695,state-insert,block,in,4,0x0,,255,41990,0,none,17,udp,76,10.1.1.14,10.1.1.1,49753,123,56

10.1.1.1 is the firewall address on this VLAN.

There is a destination NAT rule which redirects outbound UDP port 123 traffic to the firewall itself, so clients are forced to use the local NTP service. The interface firewall rule allows the subnet to access the firewall address on UDP ports 53 and 123.

This means the issue is not limited to hairpin NAT towards an internal server. It also occurs with UDP traffic destination-NATed to a service running locally on the firewall.

[26.1.x]

Hi,

after upgrading from 26.1.x to 26.7.1, I noticed something odd that I haven't seen before.

Immediately after the upgrade, my firewall started logging a large number of state-insert,block events.

The reason I'm posting this is the timing. I've been collecting all OPNsense firewall logs in Graylog for quite some time, so I searched the last 30 days.

Result:

• Before the upgrade: 0 occurrences of state-insert
• Immediately after upgrading to 26.7.1: thousands of state-insert,block events

At first I assumed this was a WebServer issue because that was the first service that stopped working. However, nginx and PHP-FPM were both running normally and TLS handshakes completed successfully, so I started investigating the firewall instead.

The firewall log shows entries like these:

Code Select Expand

match,pass,in,...
192.168.1.2 -> 192.168.243.10:12345

state-insert,block,in,...
192.168.1.2 -> 192.168.243.10:12345

The corresponding PF rule is:

Code Select Expand

@218 pass in log quick on igc0_vlan4096 inet
flags S/SA keep state
label "88f5cbb7-6e4c-47da-9811-ca92e09741a7"
divert-to 8000

Evaluations:      92502
Packets:          23425
States:               7
State Creations:   1093

For reference, this is the current output of pfctl -si:

Code Select Expand

State Table
  current entries: 5717

Counters
  state-insert: 7184
  state-limit: 0
  memory: 0

The state table is clearly not full, so this doesn't appear to be a state table limit issue.

My setup:

• OPNsense 26.7.1 (upgraded from 26.1.x)
• Suricata Inline IPS
• Hairpin NAT / NAT Reflection for exposed https service which failed after the upgrade
• Graylog for centralized firewall logging

I'm not claiming that Suricata or NAT Reflection are the cause. They are simply part of my environment.

The only thing I can say with confidence is :

• 30 days of Graylog history before the upgrade: 0 state-insert events.
• Immediately after upgrading to 26.7.1: thousands of state-insert,block events.

I'll also attach a screenshot from Graylog showing exactly that.

Has anyone else seen this after upgrading to 26.7.x?

Could this be related to the FreeBSD 15.1 / PF changes?

I did a rollback to a created snapshot, as I had not much time to debug.


Cheers,

fb

Another Quick update....

Following feedback from the FreeBSD maintainer, I tested late/runtime microcode loading again, including after downgrading to the older cpu-microcode-intel-20260512 package.

After rebooting, the CPU was back at 0x432. The runtime update then successfully applied 0x43b:

/usr/local/share/cpucontrol/06-9a-04.80: updating cpu /dev/cpuctl0 from rev 0x432 to rev 0x43b... done.

This confirms that runtime loading works even with the older package. The remaining issue appears to be specific to the FreeBSD early loader path rather than the microcode package itself.

The FreeBSD bug report has been updated accordingly.

Hallo Christian,

dein Netzwerk sieht auf jeden Fall interessant aus und man merkt, dass du dir viele Gedanken gemacht hast.

Was mich allerdings etwas wundert, ist der Umfang des Projekts. Nach meinem Verständnis muss eine IHK-Abschlussarbeit einen klar abgegrenzten Projektumfang haben, der vor Beginn durch den Prüfungsausschuss genehmigt wird. Erst danach darf das eigentliche Projekt durchgeführt werden.

Je nach IHK liegt die Projektzeit bei etwa 40 Stunden. In dieser Zeit müssen Planung, Umsetzung, Tests sowie die Projektdokumentation erfolgen. Bewertet wird dabei nicht die gesamte vorhandene Infrastruktur, sondern ausschließlich der genehmigte Projektumfang.

Wenn ich deinen Beitrag lese, erkenne ich unter anderem folgende Themen:

- Einführung von IPv6
- Aufbau eines OPNsense-Firewallclusters mit CARP
- mehrere VLANs
- OpenWRT
- KEA-DHCP
- mDNS über VLAN-Grenzen
- Druckdienste
- Routing zwischen mehreren Netzen

Das wirkt auf mich eher wie eine komplette Netzwerkinfrastruktur als wie ein einzelnes IHK-Abschlussprojekt.

Daher hätte ich eine ehrliche Verständnisfrage:

Wäre es möglich, deinen Projektantrag (selbstverständlich anonymisiert) hier zu zeigen? Mich würde interessieren,

- wie das Projektziel formuliert wurde,
- welche Aufgaben tatsächlich Bestandteil des genehmigten Projekts sind,
- wie die Zeitplanung aussieht und
- welcher betriebliche bzw. kundenseitige Nutzen beschrieben wurde.

Ich glaube, das würde auch vielen anderen helfen, den Projektumfang besser einzuordnen.

Zur Orientierung findest du hier die allgemeinen Informationen der IHK zur Projektarbeit und zum Projektantrag:

https://www.ihk.de/blueprint/servlet/resource/blob/6957958/fd54ae065bc407cd8fc092c654af9a96/leitfaden-fi-systemintegration-data.pdf

sowie beispielhafte Hinweise zum Projektantrag und zur Zeitplanung:

https://www.ihk.de/darmstadt/produktmarken/pruefungen/downloads/muther/it-hinweise-projektantrag-2551070

Mich würde wirklich interessieren, wie der Prüfungsausschuss dieses Projekt genehmigt hat, denn nach meiner Erfahrung wäre ein solcher Umfang für eine IHK-Abschlussarbeit eher sehr ungewöhnlich.

Viele Grüße

fb

Ich stehe hier gerade ein wenig auf dem Schlauch?!?

Es ist wirklich so, dass wenn die Sense nicht auf dem aktuellsten Stand ist, dass man keine Plugins installiert bekommt?! Vermutlich hatte ich diesen Status noch nicht, wirkt aber trotzdem ein wenig suspekt?

@kbthomelab88


I guess you did not implement at all what I've described.

Look at your LAN rules. You use as source the SonosNetwork? Why? These rules are useless.

i have upload the picture

We're still waiting for the picture. At the moment I am troubleshooting an non existing attachment rather than your network.

This my lan setup for sonos

Cool Design, how did you manage L2? Looks you do L2 Filtering was well?
Also your micro segmentation look pretty much impressive.

[First, I am not planning to risk any outage, nor am I willing to accept one at this point.]

Thanks for the suggestion.

I understand the reasoning behind the test, but there are a couple of reasons why I'm hesitant to try it on this particular system.

First, I am not planning to risk any outage, nor am I willing to accept one at this point. While a reboot itself is not a major issue, the proposed test involves changing the microcode loading path and boot behaviour rather than simply observing the existing system state.

Second, the original issue I reported was a packaging problem in FreeBSD. That issue has now been confirmed and fixed upstream. The remaining question is why this specific platform still does not receive a microcode update even though:

- the correct 06-9a-04.80 split file is now present
- IA32_PLATFORM_ID indicates platform ID 7 (0x80)
- newer microcode revisions appear to exist for this CPU family

At this point I'm not yet convinced that the root cause is a timing issue. The current evidence only shows that the microcode is not being applied, not why.

Before testing alternative loading mechanisms, I would prefer feedback from the FreeBSD maintainer of the microcode package. If there is a specific diagnostic procedure recommended from the FreeBSD side, I'll be happy to follow it.

For now I'd rather avoid changing the microcode loading mechanism on a production system and potentially introducing a second variable while the original issue is still under investigation by the maintainer. => See the Bug Report

[Wichtiger Hinweis zur Nutzung:]

UPDATE_AVAILABLE: Current version: OPNsense 26.4.1, Available version: OPNsense 26.1.10. Irgendwie funktioniuert es nicht mehr..

Mit Verlaub: So sollte man keinen Support erwarten.

Ein einzelnes "funktioniert nicht mehr" zusammen mit einer Ausgabe, die offensichtlich zwei unterschiedliche Versionsstände zeigt, ist keine brauchbare Fehlerbeschreibung. Business Version != FREE Version

Wenn man Hilfe möchte, sollte man zumindest die verwendeten Befehle, deren Ausgaben und die eigene Umgebung nennen.  Damit hätte sich innerhalb weniger Sekunden erkennen lassen, was tatsächlich verglichen wird.

Mein Script macht genau das, wofür es geschrieben wurde. Aus der geposteten Ausgabe allein lässt sich weder ein Fehler im Script noch ein Defekt nachweisen. Sie zeigt lediglich, dass die installierte Version und die vom abgefragten Repository gelieferte Version voneinander abweichen.

Wer einen Fehler vermutet, sollte zunächst nachvollziehen, wie die Ausgabe zustande kommt, bevor er pauschal behauptet, etwas würde nicht mehr funktionieren. Manchmal sagt meine Glaskugel auch einfach: Nein.

Code Select Expand

#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

PKG_NAME="opnsense"

CURRENT_VERSION=$(opnsense-version 2>/dev/null | awk '{print $2}')
AVAILABLE_VERSION=$(pkg rquery '%v' "$PKG_NAME" 2>/dev/null)

if [ -z "$CURRENT_VERSION" ]; then
    echo "UNKNOWN: Could not determine installed OPNsense version"
    exit 3
fi

if [ -z "$AVAILABLE_VERSION" ]; then
    echo "UNKNOWN: Could not determine repository version for $PKG_NAME"
    exit 3
fi

if [ "$CURRENT_VERSION" = "$AVAILABLE_VERSION" ]; then
    echo "NO_UPDATE: Current version: OPNsense $CURRENT_VERSION"
    exit 0
fi

# FreeBSD/pkg-kompatibler Versionsvergleich
if pkg version -t "$CURRENT_VERSION" "$AVAILABLE_VERSION" >/dev/null 2>&1; then
    CMP=$(pkg version -t "$CURRENT_VERSION" "$AVAILABLE_VERSION")

    case "$CMP" in
        "<")
            echo "UPDATE_AVAILABLE: Current version: OPNsense $CURRENT_VERSION, Available version: OPNsense $AVAILABLE_VERSION"
            exit 1
            ;;
        ">")
            echo "VERSION_MISMATCH: Installed OPNsense $CURRENT_VERSION is newer than repository version OPNsense $AVAILABLE_VERSION"
            exit 2
            ;;
        "=")
            echo "NO_UPDATE: Current version: OPNsense $CURRENT_VERSION"
            exit 0
            ;;
        *)
            echo "UNKNOWN: Unexpected comparison result: $CMP"
            exit 3
            ;;
    esac
else
    echo "UNKNOWN: Version comparison failed: installed=$CURRENT_VERSION repository=$AVAILABLE_VERSION"
    exit 3
fi

Wichtiger Hinweis zur Nutzung:

Dieses Script wird auf eigene Gefahr von Anwendern, Anwenderinnen, Anwendenden, Anwender*innen, Anwender und sonstigen scriptnutzenden Personen verwendet. Für Schäden an Hardwarern, Softwareinnen, Firmwarenden, Netzwerkern, Netzwerkenden oder sonstigen digital arbeitenden Wesen wird keinerlei Haftung übernommen.

Bitte konsultieren Sie vor der Verwendung Ihren Arzt, Ihre Ärztin, Ihr Ärztendenwesen, Ihren Apotheker, Ihre Apothekerin, Ihre Apothekerndenfachkraft, Ihren Tierpfleger, Ihre Tierpflegerin, Ihre Tierpflegefachperson sowie gegebenenfalls Ihren Systemadministrator, Ihre Systemadministratorin oder Ihre systemadministrierenden Fachkräfte.

Sollten nach der Nutzung Symptome wie "geht nicht", "funktioniert nicht", "habe nichts geändert", "ist plötzlich kaputt", "war gestern noch gut" oder "das Script ist schuld" auftreten, wenden Sie sich bitte umgehend an qualifizierte Troubleshooter, Troubleshooterinnen, Troubleshootende oder anderweitig fehlersuchende Personen.

Mit der Ausführung erklären Sie sich einverstanden, dass Sie die Ausgabe lesen, verstehen, interpretieren und gegebenenfalls darüber nachdenken. Sollten Sie dazu nicht in der Lage sein, lassen Sie das Script bitte durch eine fachkundige Person, Fachkraft, Fachperson oder fachkraftausübende Person Ihres Vertrauens bedienen.

Ich glaube, hier reden wir gerade über zwei unterschiedliche Setups. 🙂

Das Vigor 167 läuft im Bridge-Modus und die OPNsense macht die PPPoE-Einwahl selbst. In dem Fall gibt es ja eigentlich kein geroutetes Transfernetz zwischen DrayTek und OPNsense und auch kein Gateway auf dem DrayTek, das auf dem WAN der OPNsense eingetragen werden müsste. Nebenher kann man dann tolles Doppel-NAT machen... Kann man machen, aber man kann es sich auch ersparen. Denn dafür hat er alles nötige da...

Die einzige IP die das Vigor Modem hat ist die Management IP. Und hier gibt man einfach dem physischen Interface an der OPNsense, wo das Modem dran hängt, eine /30 aus dem Mgmt Netz...

Die eigentliche Frage des OP war für mich eher, wie er möglichst einfach von seiner alten Installation auf die neue Protectli migrieren kann.

Ich würde ganz klar neu installieren und von Scratch konfigurieren. Bei dem ewig wiederkerhrenden mach doch mal "ANY ANY" auf, bekomme ich ehrlich gesagt Bauchschmerzen.

Eine Standardkonfiguration für eine Sense ist in wenigen Minuten eingerichtet. Fine Tuning kommt später...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295351

Some more reading about alder lake with bios/uefi with freeBSD.
loader.conf may be too early to try and push a ucode update.

as a test, remove the load entries from loader.conf (or change to cpu_microcode_load="NO")

rc.local
#!/bin/sh
sleep 10
/usr/sbin/cpucontrol -m /dev/cpuctl0 /boot/firmware/intel-ucode.bin
/usr/sbin/cpucontrol -m /dev/cpuctl1 /boot/firmware/intel-ucode.bin

chmod +x /etc/rc.local

Thanks for looking into it.

The IA32_PLATFORM_ID result seems to confirm that 0x80 is indeed the relevant variant for this CPU, which was very helpful.

As for the manual loading tests, I'd rather wait for feedback from the FreeBSD side first. This is a production firewall and microcode loading happens very early in the boot process, so I'm not particularly eager to start experimenting with manual updates, loader changes or alternative loading paths without a recommendation from the maintainer of the FreeBSD microcode package.

At this point the original packaging issue is fixed, the correct .80 file is present, and the remaining question seems to be why the update is still not being applied on this specific platform. I might also get in touch with Protectli, as usually their support is superb.

Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295351