"Recent posts
#1
25.7, 25.10 Legacy Series / Re: Double NAT + Multi-WAN: Po...
Last post by GG - Today at 03:07:22 PMHi everyone,
I wanted to give a quick update to keep you in the loop and respect the great suggestions shared so far. We are actively troubleshooting based on your feedback.
Here is what we checked and the current status:
Regarding the suggestions to trace the packets: We ran tcpdump on the inner firewall's WAN interface. The traffic from the outside world successfully reaches the inner firewall's external interface on the correct port without any changes from the outer firewall.
The issue we hit: When we configure the port forward rules in the inner firewall's web GUI, the interface says "Applied Changes" and successfully writes the lines to the temporary configuration file (/tmp/rules.debug). However, when checking the live kernel rules via root SSH using pfctl -s nat and pfctl -s rules, the output is completely empty. The changes are simply not reflecting in the active pf kernel.
Next Steps: Since the GUI changes are stuck and not being pushed to the operating system, we are currently restarting the configd service via backend and will try to force a rule reload to see if we can get the kernel back in sync.
I will test again right after the reload and update you with the final result. Thank you all for the brilliant guidance so far!
I wanted to give a quick update to keep you in the loop and respect the great suggestions shared so far. We are actively troubleshooting based on your feedback.
Here is what we checked and the current status:
Regarding the suggestions to trace the packets: We ran tcpdump on the inner firewall's WAN interface. The traffic from the outside world successfully reaches the inner firewall's external interface on the correct port without any changes from the outer firewall.
The issue we hit: When we configure the port forward rules in the inner firewall's web GUI, the interface says "Applied Changes" and successfully writes the lines to the temporary configuration file (/tmp/rules.debug). However, when checking the live kernel rules via root SSH using pfctl -s nat and pfctl -s rules, the output is completely empty. The changes are simply not reflecting in the active pf kernel.
Next Steps: Since the GUI changes are stuck and not being pushed to the operating system, we are currently restarting the configd service via backend and will try to force a rule reload to see if we can get the kernel back in sync.
I will test again right after the reload and update you with the final result. Thank you all for the brilliant guidance so far!
#2
General Discussion / Re: Managing OPNsense upgrades...
Last post by franco - Today at 02:57:12 PMBTW:
> https://dev.to/builderall_uniq/i-gave-claude-access-to-my-opnsense-firewall-heres-what-happened-nif
That's an interesting theory, but since the given opnsense-update script can fix that in situ this explanation is wrong.
The more straight-forward answer lies in the upgrade log, because it most certainly starts upgrading packages, but then fails for one reason or another.
# opnsense-update -gG
The fact that the system can't recover is unfortunately plentiful since we've had to deal with stricter pf syntax WRT route-to, new OpenSSL 3.5 validation killing connections on HTTPS when DTLS is misconfigured and Realtek and CPU microcode third party issues.
To be frank I don't think we can really achieve to fix all of this within the time we have for a major release, but that also means a script proposed such as this will fail for similar reasons as you get closer to the root of the particular problem.
Cheers,
Franco
> https://dev.to/builderall_uniq/i-gave-claude-access-to-my-opnsense-firewall-heres-what-happened-nif
QuoteThe FreeBSD base and kernel get upgraded first, triggering a reboot. After that reboot, the new base ships a different pkg ABI — and the old pkg binary can no longer install or upgrade anything. The web UI has no recovery path for this. You're on your own.
That's an interesting theory, but since the given opnsense-update script can fix that in situ this explanation is wrong.
The more straight-forward answer lies in the upgrade log, because it most certainly starts upgrading packages, but then fails for one reason or another.
# opnsense-update -gG
The fact that the system can't recover is unfortunately plentiful since we've had to deal with stricter pf syntax WRT route-to, new OpenSSL 3.5 validation killing connections on HTTPS when DTLS is misconfigured and Realtek and CPU microcode third party issues.
To be frank I don't think we can really achieve to fix all of this within the time we have for a major release, but that also means a script proposed such as this will fail for similar reasons as you get closer to the root of the particular problem.
Cheers,
Franco
#3
General Discussion / Re: Managing OPNsense upgrades...
Last post by franco - Today at 02:49:28 PM> handles the pkg ABI mismatch after base/kernel upgrades
We already know what happens:
base/kernel installs fine, but packages abort
We also know the fix:
# opnsense-update -upr 26.7 -a FreeBSD:15:amd64/26.7
(reboot)
What we don't know is why packages are not installing.
Knowing this would help improve the current code or at least put more upgrade checks in place.
Another thing to note is that we don't test updates with third party repositories for a few reasons:
1. We don't know what was enabled by the user.
2. Incompatible packages could be installed that cause runtime issues.
3. Incompatible packages could be installed that cause later upgrade issues.
4. Even if we knew what to fix we have an upgrade schedule to adhere to and don't have access to third party repos.
This is also why you can see this in the latest release notes:
https://github.com/opnsense/changelog/blob/de1d2dc557a/community/26.7/26.7#L99
Cheers,
Franco
We already know what happens:
base/kernel installs fine, but packages abort
We also know the fix:
# opnsense-update -upr 26.7 -a FreeBSD:15:amd64/26.7
(reboot)
What we don't know is why packages are not installing.
Knowing this would help improve the current code or at least put more upgrade checks in place.
Another thing to note is that we don't test updates with third party repositories for a few reasons:
1. We don't know what was enabled by the user.
2. Incompatible packages could be installed that cause runtime issues.
3. Incompatible packages could be installed that cause later upgrade issues.
4. Even if we knew what to fix we have an upgrade schedule to adhere to and don't have access to third party repos.
This is also why you can see this in the latest release notes:
https://github.com/opnsense/changelog/blob/de1d2dc557a/community/26.7/26.7#L99
Cheers,
Franco
#4
General Discussion / Re: System memory cache is con...
Last post by camellia - Today at 02:37:27 PMQuote from: sopex on July 16, 2026, 04:35:53 PMIn case you want to try it: opnsense-core -a sopex 5bfd77c
You cannot view this attachment.
Cache is back!
Thanks.
#5
26.7 Series / Re: 26.7 DHCP WAN gateway onli...
Last post by livtec - Today at 02:24:04 PMHello
We are experiencing a similar problem.
The issue is not that no default gateway exists. Rather, the system selects an incorrect gateway instead of the intended upstream gateway. We believe this occurs because the correct gateway takes longer to initialize at boot, and the system temporarily uses an alternative gateway that is already available.
Other forum posts mention DHCP issues and delayed WAN interface initialization. This appears to be the common factor.
The following solutions have worked for us (temporary workaround):
Option 1: Click «Apply» in the WEB UI Router/Gateway configuration, or
Option 2: Execute: configctl interface routes configure
This forces a route recalculation and ensures the correct gateway is used.
Please note: This fix is not permanent. After a reboot, the problem reoccurs and the same steps must be repeated.
We are experiencing a similar problem.
The issue is not that no default gateway exists. Rather, the system selects an incorrect gateway instead of the intended upstream gateway. We believe this occurs because the correct gateway takes longer to initialize at boot, and the system temporarily uses an alternative gateway that is already available.
Other forum posts mention DHCP issues and delayed WAN interface initialization. This appears to be the common factor.
The following solutions have worked for us (temporary workaround):
Option 1: Click «Apply» in the WEB UI Router/Gateway configuration, or
Option 2: Execute: configctl interface routes configure
This forces a route recalculation and ensures the correct gateway is used.
Please note: This fix is not permanent. After a reboot, the problem reoccurs and the same steps must be repeated.
#6
German - Deutsch / Re: MAC addresses Alias - wie ...
Last post by Monviech (Cedrik) - Today at 02:22:46 PMDer Vorteil bei Hostwatch ist dass es in einer persistenten Datenbank gespeichert wird. Selbst nach einem Reboot ist die temporäre IPv6 Adresse noch bekannt. Natürlich muss dann auch der Präfix der selbe bleiben, was aber ein anderes Problem ist.
Ich glaube nicht, dass der MAC alias beim NDP parsen zwischen STALE und REACHABLE unterscheidet. Hier hat NDP nämlich einen 30 Sekunden timeout.
Ich denke es ist also alleine der unterschied zwischen Runtime vs Datenbank.
Noch komplizierter macht es, dass der letzte bekannte Status eines alias in einem cache gespeichert wird auf der Festplatte, das bedeutet theoretisch kennt der MAC Alias nach einem Reboot immer noch den alten Status, auch ohne Datenbank.
Aber wie man sieht gibt es hier viele mechanismen die voneinander Abhängig sind.
Am meisten Sinn ergibt die 1 Minute aktualisierungsrate, die den Alias "langsam" machen kann wenn eine neue Addresse kommt.
Ich glaube nicht, dass der MAC alias beim NDP parsen zwischen STALE und REACHABLE unterscheidet. Hier hat NDP nämlich einen 30 Sekunden timeout.
Ich denke es ist also alleine der unterschied zwischen Runtime vs Datenbank.
Noch komplizierter macht es, dass der letzte bekannte Status eines alias in einem cache gespeichert wird auf der Festplatte, das bedeutet theoretisch kennt der MAC Alias nach einem Reboot immer noch den alten Status, auch ohne Datenbank.
Aber wie man sieht gibt es hier viele mechanismen die voneinander Abhängig sind.
Am meisten Sinn ergibt die 1 Minute aktualisierungsrate, die den Alias "langsam" machen kann wenn eine neue Addresse kommt.
#7
German - Deutsch / Re: MAC addresses Alias - wie ...
Last post by meyergru - Today at 01:59:34 PMEcht? Ich habe keinen Hostwatch laufen. Es reicht doch völlig, wenn ein IPv6-Paket die OpnSense erreicht oder passiert, dann wird der Neighbor Cache doch auch gefüllt? Klar, Hostwatch merkt es schneller, aber der Sinn ist ja die Verwendung in Firewall-Regeln und die können sowieso nur greifen, wenn Unicast-Traffic über die Firewall läuft.
#8
German - Deutsch / Re: MAC addresses Alias - wie ...
Last post by Monviech (Cedrik) - Today at 01:41:32 PMDer Alias wird einmal pro Minute aktualisiert (es gibt einen Cron job, kannste mit "crontab -e" sehen. filter_update_tables)
Die Quelle des Alias ist Hostwatch. Das bedeuted Hostwatch muss an sein, damit die privacy Extension IPv6 Addressen erkannt werden. (Interfaces -> Neighbors -> Automatic Discovery).
Wenn ein Host eine neue Privacy Addresse generiert, sendet er ein DAD Paket, dieses wird von Hostwatch erkannt und die MAC->IPv6 Addresse wird gemapped (Discovered Hosts). Dieses Paket wird nur einmal gesendet pro neuer Addresse, wenn es irgendwo verloren geht dann wird sie nicht gelernt.
Die Quelle des Alias ist Hostwatch. Das bedeuted Hostwatch muss an sein, damit die privacy Extension IPv6 Addressen erkannt werden. (Interfaces -> Neighbors -> Automatic Discovery).
Wenn ein Host eine neue Privacy Addresse generiert, sendet er ein DAD Paket, dieses wird von Hostwatch erkannt und die MAC->IPv6 Addresse wird gemapped (Discovered Hosts). Dieses Paket wird nur einmal gesendet pro neuer Addresse, wenn es irgendwo verloren geht dann wird sie nicht gelernt.
#9
26.7 Series / Re: 26.7 Default Gateway no lo...
Last post by sc00by1984 - Today at 01:01:43 PMi have the same issues ince upgrading to 26.7
#10
German - Deutsch / Re: MAC addresses Alias - wie ...
Last post by Bob.Dig - Today at 12:41:13 PMQuote from: meyergru on Today at 12:31:16 PMDu bringst zwei Themen zusammen, die nichts miteinander zu tun habenNope.
Quote from: meyergru on Today at 12:31:16 PMkann es sein, dass sogar MAC-basierte Aliase verzögert greifen.Nur darum ging es mir, danke trotzdem.
Wer hierzu praktische Erfahrungen hat, gerne hier posten, z.B. ob Webbrowsing manchmal deswegen nicht klappt etc.
Oder wer die genauen Details kennt, wie häufig dieser Alias aktualisiert wird. Vielleicht ist es ja praktisch gar kein Problem.
