"Recent posts
#1
26.1 Series / Re: SUPPORT NEEDED - Reply-to ...
Last post by Oriann - Today at 10:12:14 AMQuote from: ProximusAl on April 02, 2026, 11:00:51 AMThe OPNSense docs state:
For legacy compatibility WAN interfaces set to type DHCP or interfaces with a Gateway Rules selection send reply packets to the corresponding gateway directly, also when the sender is on the same interface. This will break connectivity in some rare scenarios and can be disabled via Firewall->Settings->Advanced->Disable reply-to.
With Multi-WAN you generally want to ensure traffic leaves the same interface it arrives on, hence reply-to is added automatically by default. When using bridging, you must disable this behavior if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface.
In my case, I have "Disable reply-to on WAN interface" selected, and my firewall rules have the reply-to explicitly set.
My secondary WAN is DHCP, and my primary is PPPoE, so this felt safest.
That works fine.
EDIT: I should add, I have migrated to the NEW rules....
In this scenario it does not work - https://github.com/opnsense/core/issues/9806#issuecomment-4194715800
EDIT: Also to mention I am using old rules, but nonethless it should work on both because this is core function. Funny is that on pFSense it works correctly and this is project is fork of it...
#2
26.1 Series / Re: SUPPORT NEEDED - Reply-to ...
Last post by Oriann - Today at 10:10:17 AMQuote from: ProximusAl on April 02, 2026, 10:53:38 AMI can tell you it works fine on 26.1.5 so you must have something misconfigured.
You havent really given us enough information.
Have you checked "Disable Reply-To on WAN rules" on Firewall/Settings/Advanced?
Have you set the "Reply-To" on the actual firewall rule? (advanced mode)
Wait what ??? Disable reply-to and using manual reply-to for each rule ? This is completely nonsense isnt it ?
Reply-to is set as default on all rules(written in docs).
Also I have already tried to setting theese options as you suggested but none of it worked correctly. It behave still the same (wrong)
#3
26.1 Series / Re: lots of empty space in new...
Last post by franco - Today at 09:55:37 AMThe functionality change is evident when using the browser zoom.
A screenshot would help explain if the issue you're seeing is relevant to the changes or not.
Cheers,
Franco
A screenshot would help explain if the issue you're seeing is relevant to the changes or not.
Cheers,
Franco
#4
Development and Code Review / Re: cron job parameters only w...
Last post by franco - Today at 09:44:43 AM> nobody uses parameters it seems, only a few (2, IIRC) internal scripts seem to
Yes, that's true for cron-visible actions (tagged with description: in the actions.conf file). Also documented as such in the manual:
https://docs.opnsense.org/manual/settingsmenu.html#cron
It's also that the parameter passing from cron isn't ideal for multiple parameters but we want to change that, see
https://github.com/opnsense/core/issues/10075
> So, since this is cleared up (in a way), can I use the internal interface aliases, like "WAN" in the cron parameters somehow, and if so, how? Would be really handy. :)
Instructions unclear: what does your script do and what do you want to pass? internal identifier "lan" "wan" "optX" ? The passing is verbatim obviously but the question is what you want to input and how you want to use it underneath.
Cheers,
Franco
Yes, that's true for cron-visible actions (tagged with description: in the actions.conf file). Also documented as such in the manual:
https://docs.opnsense.org/manual/settingsmenu.html#cron
It's also that the parameter passing from cron isn't ideal for multiple parameters but we want to change that, see
https://github.com/opnsense/core/issues/10075
> So, since this is cleared up (in a way), can I use the internal interface aliases, like "WAN" in the cron parameters somehow, and if so, how? Would be really handy. :)
Instructions unclear: what does your script do and what do you want to pass? internal identifier "lan" "wan" "optX" ? The passing is verbatim obviously but the question is what you want to input and how you want to use it underneath.
Cheers,
Franco
#5
26.1 Series / Re: 26.1.6 - Health Check
Last post by (MARLOO) - Today at 09:33:08 AMThanks for the correction. I shouldn't have used pkg update -f && pkg upgrade or plain reboot.
In my case the upgrade was:
pkg update -f
pkg upgrade
opnsense-update
reboot
The only non‑recommended parts are the manual pkg usage and direct reboot. The system update was done correctly via opnsense-update.
From now on I'll follow the official upgrade path through the GUI/console and only use opnsense-update plus yes | opnsense-shell reboot if needed from shell.
In my case the upgrade was:
pkg update -f
pkg upgrade
opnsense-update
reboot
The only non‑recommended parts are the manual pkg usage and direct reboot. The system update was done correctly via opnsense-update.
From now on I'll follow the official upgrade path through the GUI/console and only use opnsense-update plus yes | opnsense-shell reboot if needed from shell.
#6
General Discussion / Re: Crashing after upgrading t...
Last post by franco - Today at 09:09:38 AMHi,
Looks like one of the imfamous "cannot happen on FreeBSD" panics relating to turnstile_broadcast() during mutex operation.
The only thing I can say for sure here is that FQ PIE use is the culprit here and turning it off may avoid the panics.
--- trap 0xc, rip = 0xffffffff80c4ad10, rsp = 0xfffffe0084330db0, rbp = 0xfffffe0084330dc0 ---
turnstile_broadcast() at turnstile_broadcast+0x40/frame 0xfffffe0084330dc0
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x76/frame 0xfffffe0084330df0
fqpie_callout_cleanup() at fqpie_callout_cleanup+0x83/frame 0xfffffe0084330e10
softclock_call_cc() at softclock_call_cc+0x129/frame 0xfffffe0084330ec0
softclock_thread() at softclock_thread+0xe5/frame 0xfffffe0084330ef0
fork_exit() at fork_exit+0x81/frame 0xfffffe0084330f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0084330f30
--- trap 0xe0d0e0d0, rip = 0x2c262c262c262c26, rsp = 0xe3c7e3c7e3c7e3c7, rbp = 0x9282928292829282 ---
Cheers,
Franco
Looks like one of the imfamous "cannot happen on FreeBSD" panics relating to turnstile_broadcast() during mutex operation.
The only thing I can say for sure here is that FQ PIE use is the culprit here and turning it off may avoid the panics.
--- trap 0xc, rip = 0xffffffff80c4ad10, rsp = 0xfffffe0084330db0, rbp = 0xfffffe0084330dc0 ---
turnstile_broadcast() at turnstile_broadcast+0x40/frame 0xfffffe0084330dc0
__mtx_unlock_sleep() at __mtx_unlock_sleep+0x76/frame 0xfffffe0084330df0
fqpie_callout_cleanup() at fqpie_callout_cleanup+0x83/frame 0xfffffe0084330e10
softclock_call_cc() at softclock_call_cc+0x129/frame 0xfffffe0084330ec0
softclock_thread() at softclock_thread+0xe5/frame 0xfffffe0084330ef0
fork_exit() at fork_exit+0x81/frame 0xfffffe0084330f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0084330f30
--- trap 0xe0d0e0d0, rip = 0x2c262c262c262c26, rsp = 0xe3c7e3c7e3c7e3c7, rbp = 0x9282928292829282 ---
Cheers,
Franco
#7
German - Deutsch / OPNsense 26.1.6 – Destination ...
Last post by bts - Today at 08:49:52 AMHallo zusammen
ich habe seit OPNsense 26.1.6 ein Problem mit einer Konstellation, die früher mit einer einfachen Destination-NAT-Regel funktioniert hat.
Ausgangslage:
Die Anfrage kommt aus einem OpenVPN-Netz:
172.17.30.0/24
Ein Client aus diesem Netz greift auf folgende Adresse zu:
10.3.0.10:7000/tcp
Diese Anfrage soll per NAT wie folgt umgesetzt werden:
eingehend auf 10.3.0.10:7000/tcp
Weiterleitung intern auf 10.10.11.5:443/tcp
Ziel:**
Die Verbindung soll so umgesetzt werden, dass die Firewall als Absender erscheint, damit der interne Zielhost 10.10.11.5 das VPN-Netz 172.17.30.0/24 nicht kennen bzw. nicht routen muss.
Früher reichte dafür eine einfache Destination-NAT-Regel. Das scheint in dieser Form nicht mehr zu funktionieren.
Bisher versucht:
Port Forward / Destination NAT
zusätzlich Hybrid Outbound NAT
dort eine zusätzliche NAT-Regel, damit die Anfrage beim internen Ziel mit der Firewall als Source ankommt
Beobachtung:
Im Live Log sieht es so aus, als würde die Übersetzung greifen. Trotzdem öffnet sich die Webseite auf 10.10.11.5:443 nicht.
Frage:
Wie bildet man diese Konstellation unter OPNsense 26.1.6 korrekt ab?
Benötigt es inzwischen zwingend eine Kombination aus:
Port Forward / Destination NAT
Outbound NAT
passende Firewall-Regeln auf OpenVPN und LAN
oder hat sich bei der NAT-Verarbeitung etwas geändert?
Falls jemand so ein Szenario bereits umgesetzt hat, wäre ich für ein Beispiel dankbar.
Wichtig ist vor allem, dass der interne Host nicht direkt ins VPN-Netz zurückrouten muss, sondern die Firewall als Absender verwendet wird.
Vielen Dank
ich habe seit OPNsense 26.1.6 ein Problem mit einer Konstellation, die früher mit einer einfachen Destination-NAT-Regel funktioniert hat.
Ausgangslage:
Die Anfrage kommt aus einem OpenVPN-Netz:
172.17.30.0/24
Ein Client aus diesem Netz greift auf folgende Adresse zu:
10.3.0.10:7000/tcp
Diese Anfrage soll per NAT wie folgt umgesetzt werden:
eingehend auf 10.3.0.10:7000/tcp
Weiterleitung intern auf 10.10.11.5:443/tcp
Ziel:**
Die Verbindung soll so umgesetzt werden, dass die Firewall als Absender erscheint, damit der interne Zielhost 10.10.11.5 das VPN-Netz 172.17.30.0/24 nicht kennen bzw. nicht routen muss.
Früher reichte dafür eine einfache Destination-NAT-Regel. Das scheint in dieser Form nicht mehr zu funktionieren.
Bisher versucht:
Port Forward / Destination NAT
zusätzlich Hybrid Outbound NAT
dort eine zusätzliche NAT-Regel, damit die Anfrage beim internen Ziel mit der Firewall als Source ankommt
Beobachtung:
Im Live Log sieht es so aus, als würde die Übersetzung greifen. Trotzdem öffnet sich die Webseite auf 10.10.11.5:443 nicht.
Frage:
Wie bildet man diese Konstellation unter OPNsense 26.1.6 korrekt ab?
Benötigt es inzwischen zwingend eine Kombination aus:
Port Forward / Destination NAT
Outbound NAT
passende Firewall-Regeln auf OpenVPN und LAN
oder hat sich bei der NAT-Verarbeitung etwas geändert?
Falls jemand so ein Szenario bereits umgesetzt hat, wäre ich für ein Beispiel dankbar.
Wichtig ist vor allem, dass der interne Host nicht direkt ins VPN-Netz zurückrouten muss, sondern die Firewall als Absender verwendet wird.
Vielen Dank
#8
26.1 Series / Re: 26.1.6 - Health Check
Last post by franco - Today at 08:38:40 AM> Also, this is not Linux. Reboot and Shutdown -r do different things, and you never want to do a reboot in (OPNsense) FreeBSD
If you're in a hurry you can use
# yes | opnsense-shell reboot
I agree about running pkg alone... it doesn't handle base/kernel and is only (mostly) safe on minor updates.
Cheers,
Franco
If you're in a hurry you can use
# yes | opnsense-shell reboot
I agree about running pkg alone... it doesn't handle base/kernel and is only (mostly) safe on minor updates.
Cheers,
Franco
#9
26.1 Series / Re: 26.1.6 - Health Check
Last post by newsense - Today at 08:33:54 AMQuote from: (MARLOO) on Today at 12:06:01 AM...
upgrade initially hung in GUI but completed cleanly via CLI (pkg update -f, pkg upgrade, reboot).
This is wrong.
There's never been any official OPNsense guidance about running those pkg commands.
Also, this is not Linux. Reboot and Shutdown -r do different things, and you never want to do a reboot in (OPNsense) FreeBSD
#10
26.1 Series / Re: Kea DDNS in practice...
Last post by Monviech (Cedrik) - Today at 08:30:09 AMThere is no manual configuration bailout for the ddns configuration yet. Best open a feature request on github, or alternatively specify what is missing to use the existing GUI.
