Messages

So,
also ich bekomme das Problem nur mit einer statischen Route gelöst.
Echt unschön, da für die static Routes an dieser Stelle nur IP's zulässig sind und keine DNS-Namen/Alias.
Ich hatte schon den Fall dass der VPNProvider die IP wechselte...

Ich konnte keine Policy-Routing Regel für den ausgehenden Traffic zu dem VPN-Server konfigurieren die diesen VPN Traffic-/Tunnelaufbau greift.
Irgendwas stimmt nicht...., es muss doch ohne die Brechstange "Static Route" möglich sein,
den ausgehenden VPN-Traffic/Tunnel zum Provider auf eines des beiden WAN-Interfaces per Rule zu routen.
- ich glaube das Problem sitzt vor dem Bildschirm...

@viragomann
- mit der 25er Version hatte meine obige Regel definitiv funktioniert.

Nach dem Upgrade von v25.x.x auf v26.x.x funktioniert diese OUT-Rule nicht mehr,
da OPNsense v26.x.x nun Traffic von der Firewall (OpenVPN als Client) selbst nicht mehr so handelt.

IF=WAN_igc1, pass, direction=out, Source any, Destination die VPN-IP als Alias, Port any, Protokoll UDP, Gateway das ausgehende Gateway.

Ich gehe nicht davon aus, dass diese Regel vor dem Upgrade das getan hat, was du beabsichtigst.

Wenn das pppoe0-WAN das Standard-Gateway ist, gehen die Pakete eben standardmäßig da raus. Und genau auf diesem Interface braucht es dann die Policy-Routing Regel für den ausgehenden Traffic zu dem VPN-Server, um diesen auf das alternative Gateway umzubiegen.

Am WAN_igc1 werden diese Pakete sonst nicht anzutreffen sein. Diese Regel kann so also nichts bewirken.

Zusätzlich braucht noch eine Source NAT Regel, die die Quell-IP auf die WAN_igc1 IP umsetzt. Wenn sich nichts geändert hat seitdem ich das mal getestet habe, ebenso am pppoe0-WAN.

Ok, werde ich heute Abend mal testen:

Wenn das pppoe0-WAN das Standard-Gateway ist, gehen die Pakete eben standardmäßig da raus.
- stimmt der connect zum VPN-Server läuft da drüber

Und genau auf diesem Interface braucht es dann die Policy-Routing Regel für den ausgehenden Traffic zu dem VPN-Server, um diesen auf das alternative Gateway umzubiegen.
- jo, hatte ich ja eigentlich oben mal mit der FloatingRegel gemacht, also ich hatte da auch schon beide WAN-IF's drinn

Zusätzlich braucht noch eine Source NAT Regel, die die Quell-IP auf die WAN_igc1 IP umsetzt. Wenn sich nichts geändert hat seitdem ich das mal getestet habe, ebenso am pppoe0-WAN.
- dass hatte ich bisher nicht, wieso brauche ich diese Source-NAT Regel wenn doch der Traffic aus der FW (die selbst OpenVPN Client ist) mit der Floating-Regel gegriffen wird und über WAN_igc1 geleitet wird?

Firewall-Regel outbound mit explizit gesetztem Gateway? Statische Route zum OpenVPN-Server über den Gateway? Eines von beiden.

Nach dem Upgrade von v25.x.x auf v26.x.x funktioniert diese OUT-Rule nicht mehr,
da OPNsense v26.x.x nun Traffic von der Firewall (OpenVPN als Client) selbst nicht mehr so handelt.

IF=WAN_igc1, pass, direction=out, Source any, Destination die VPN-IP als Alias, Port any, Protokoll UDP, Gateway das ausgehende Gateway.

Sachlage: Zwei WAN-Interfaces (1x pppoe-GW über ein Draytek 167 und einmal mit GW/statischer IP über einen Speedport 3)

@patrik: Ich konnte das Problem nun mit einer statischen Route lösen so wie du es oben vorgeschlagen hattest.

IP des VPNServer auf WAN-Gateway WAN_igc1

Unschön ist die Tatsache dass das Web-UI für die Routes an dieser Stelle nur IP's zulässt und keine DNS-Namen.
Ich hatte schon den Fall dass der VPNProvider die IP wechselte, auch Alias werden hiuer leider nicht akzeptiert.

Fall es noch andere Lösungen gibt als her damit :-)

The rule "MyVPNProvider" is at the top but all VPN Traffic goes over GW1: OPT3_PPPOE0_PPPOE (active) and not the WAN_IGC1_GW - 192.168.2.1


https://www.pasteboard.co/6KMF6YyaZqb1.png

Code Select Expand

10113c75-838e-4d0b-9bf7-9cc8ba4600bf;1;keep;;6;pass;1;0;wan;out;inet;any;;;any;0;;MyVPN_Provider;0;;;WAN_IGC1_GW;;0;1;0;0;0;;;;;;;;;;;;;;;;;;;;;0;;;;;;MyVPNProvider

So i think traffic from the firewall it-self (OpenVPN in Client Mode)  can not catched with policy-based-rules on the WAN interfaces.
- at OPENsense 25.x.x works this feature...

I solved this issue - not nice to handle but it works.
- created an static route: System-Routes-Configuration

*** Any other solutions for this behavior are welcome! ***

[Feature-Request]
- handle ALIAS-entrys System-Routes-Configuration in the field "Network Address"
- why: the VPN Provider has DNS-Names for the Server and the IP changed sometime...

Hi.

I upgrade from v25.x.x -> v26.x.x, now a well worked FL-rule don't work.

The rule was migrated from floating-rule to a interface-rule

Policy-Routing/Floating-Regel
IF=WAN_igc1, pass, dir=out, Source any, Destination die VPN-IP als Alias, Port any, Protokoll UDP, Gateway: WAN_IGC1_GW

rule-export

Code Select Expand

10113c75-838e-4d0b-9bf7-9cc8ba4600bf;1;keep;;6;pass;1;0;wan;out;inet;any;;;any;0;;MyVPNProvider;0;;;WAN_IGC1_GW;;0;1;0;0;0;;;;;;;;;;;;;;;;;;;;;0;;;;;;"MyVPNProvider"

Background:
I have two WAN-interfaces, all VPN traffic should go over the gateway WAN_IGC1_GW

GW1: OPT3_PPPOE0_PPPOE (active)
GW2: WAN_IGC1_GW

I think the rule handling was changed in v26.x.x

Any hints for me?

See: https://forum.opnsense.org/index.php?topic=46026.msg264546#msg264546

Hallo zusammen.

Nach dem Upgrade von v25.x.x auf v26.x.x funktioniert diese Floating-Rule nicht mehr.

Policy-Routing Floating-Regel
IF=WAN_igc1, pass, direction=out, Source any, Destination die VPN-IP als Alias, Port any, Protokoll UDP, Gateway das ausgehende Gateway.

Ich hatte da etwas in Erinnerung dass andere User ähnliche Probleme der englischen Rubrik zu v26 gepostet hatten, finde aber nicht mehr das Posting...

Hi franco.

I have found - ? - the problem.

System: Settings: General; in the DNS servers list was two entrys with the same DNS-IP.
Removed both entrys, saved and no popup comes up in the unbound sections
Services → Unbound DNS → Query Forwarding
Services → Unbound DNS → DNS over TLS

For testing, i put the two same entrys again in the list, saved and and no popup comes up in the unbound sections - ???

By the way, i don't need this entrys and removed both.

Issue-Category: Easteregg ;-)



.

Are you using any browser extensions? And is the health audit clean?

- no browser extensions active
- health audit is clean
- updated to 26.1.2, Popup comes up

I have send the crash report.

I have used dns ip's for monitoring. After some months my two wan gateways go down sometimes and i found that using dns ip was a bad idea. The dns infrastructure has no focus for ICMP network pings :-)

sure:

Code Select Expand

[11-Feb-2026 21:42:16 Europe/Brussels] TypeError: Cannot assign stdClass to property OPNsense\Mvc\Dispatcher::$returnedValue of type array|string|null in /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Dispatcher.php:166
Stack trace:
#0 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(156): OPNsense\Mvc\Dispatcher->dispatch(Object(OPNsense\Mvc\Request), Object(OPNsense\Mvc\Response), Object(OPNsense\Mvc\Session))
#1 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(139): OPNsense\Mvc\Router->performRequest(Object(OPNsense\Mvc\Dispatcher))
#2 /usr/local/opnsense/www/api.php(36): OPNsense\Mvc\Router->routeRequest('/api/unbound/se...', Array)
#3 {main}
[11-Feb-2026 21:42:33 Europe/Brussels] TypeError: Cannot assign stdClass to property OPNsense\Mvc\Dispatcher::$returnedValue of type array|string|null in /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Dispatcher.php:166
Stack trace:
#0 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(156): OPNsense\Mvc\Dispatcher->dispatch(Object(OPNsense\Mvc\Request), Object(OPNsense\Mvc\Response), Object(OPNsense\Mvc\Session))
#1 /usr/local/opnsense/mvc/app/library/OPNsense/Mvc/Router.php(139): OPNsense\Mvc\Router->performRequest(Object(OPNsense\Mvc\Dispatcher))
#2 /usr/local/opnsense/www/api.php(36): OPNsense\Mvc\Router->routeRequest('/api/unbound/se...', Array)
#3 {main}



I have deleted, saved the dns entrys in the System: Settings: General.
Restarted the system and enter again the dns-server in System: Settings: General.

But the DANGER message pop up in the two sections:

Services → Unbound DNS → Query Forwarding
Services → Unbound DNS → DNS over TLS

So what the heck is wrong...?????

Hi.

I see that a "Firewall: NAT: Destination NAT" rule with description "abcd" is not presented in the "Firewall: Log Files: Live View" Label section.
Only the label "rdr rule" is shown was complicated the analyse/finding the correct rule.

- bug/feature or what?

Dein Hinweis war goldrichtig: ich hatte eine virtuelle IP auf dem Interface für caddy definiert und vergessen!

Ist aber schon komisch, dass daran dann ssh & co gebunden wird.
- wäre schön, wenn man dies steuern könnte...

Hallo zusammen.

Mir ist gerade aufgefallen dass sshd/lighthttpd auf diesen IP/Ports lauschen:

root     lighttpd   21322 7   tcp4   127.0.0.1:81          *:*
root     lighttpd   21322 10  tcp4   192.168.0.1:81        *:*
root     lighttpd   21322 11  tcp4   192.168.1.10:81       *:*
root     sshd        3427 6   tcp4   192.168.1.10:22       *:*
root     sshd        3427 7   tcp4   192.168.0.1:22        *:*
root     sshd        3427 10  tcp4   127.0.0.1:22          *:*


In System: Settings: Administration ist "Listen Interfaces" LAN_igc0 (dieses ist definiert als IPv4 static und mit 192.168.0.1/23)

Wieso lauscht sshd und lighttpd auf zwei IP's?!

- also diese Meldung bekomme ich nicht weg...