Messages

I was not aware that "Rules [new]" section is possibly not (yet) stuffed with all features of the old system.

It is already, as far as I know.

However, it's not recommended to use both, old and new rules.
You should migrate your rule at some point.

So far I had tried to live with destination NAT rules and the option "Firewall rule": "Register rule".

With "Register rule" OPNsense creates the firewall rule for you and you're able to modify it later. But I'd rather create rule manually instead.

1) what is the sense of "no RDR (NOT)" (Enabling this option will disable redirection for traffic matching this rule.) Wouldn't make this the rule itself pointless?

For a single port forwarding rule, it does.
I guess, this can make sense if you forward multiple / all ports. So using this option you can define an exception.

2) "NAT reflection"

NAT reflection mirrors a NAT rule to internal interface in short.
So if you define a NAT rule on WAN for the WAN IP to forward port 443 to webserver 1 in DMZ. NAT reflection enable you to access the webserver using the WAN IP also from LAN.

3) "Set tag" I suspected to be what I should use.

No, this is for custom tagging.
With this you can instruct OPNsense to tag connection and use this tag by following rule, e.g. outbound rules.

Now the packets flow as expected, I can reach my services with both published IP addresses.

Fine.

So I have to define such a rule for every port forwarding for each of the two upstream interfaces?

You only need this for incoming traffic from the internet (from source addresses, which OPNsense has no specific route for. This could also be a remote client accessing your resources over VPN).
You can also use aliases for forwarded ports or destination IPs. So don't need one for each NAT rule.

I'd expect this to be default behaviour, that return packets go back the interface they came in.

Yes, it is. But possibly this doesn't work together with a load balancing gateway group.

Tagging of incoming traffic should be done automatically by the firewall rule on the WAN interface, which passes it. You should just get sure, that the respective interface pass rule is applied to the traffic, but no other (floating or group).
OPNsense should route the replies accordingly to the reply-to tags.

If no success either, you can state the reply-to gateway in each rule manually.
But anyway you have to ensure that the respective rule is applied. This presumes that you state a unique name for the rule and enable logging.

In a multi-WAN setup rerouting the traffic to the correct gateway is normally managend by reply-to.
For this to work it's required that each WAN interface has a gateway assigned, either manually or automatically by DHCP or PPP.
The gateways must be shown up in Interfaces: Overview for the respective WAN.
Futher gateway monitoring must be enabled for each and the status in System: Gateways: Configuration has to be shown up as online.

The reply-to tagging is done by a firewall pass rule, which is defined on one of the WAN interfaces then.
So you have to ensure, that the rule is applied to the incoming (forwarded) traffic. It doesn't work with floating rules or interface group rules, because these could be applied to multiple interfaces. So the reply gateway is not distinct.

Note that group rules and floating rule have precedence over interface rules. So you have to ensure, that there is none of these overriding your WAN rules.
Instead of "pass" in the port forwarding I'd rather create the rules manually on each WAN. State a unique description for each rule, e.g. HTTPS WAN1, HTTP WAN2 and enable logging. So you can check in the log if the WAN2 rule is applied to the incoming traffic.

If it doesn't work either, you can try to explicitly state the WAN2 gateway in the rule at "Reply-to".

However, I'm not certain, if this works a load balancing configuration.
Also there are several threads here, complaining about trouble with reply-to in 26.1.

An L3 switch in front of OPNsense can only help here, if it does hairpinning incoming traffic to its interface IP. But this removes the information about origin source IP and is probably unwanted.

Is the gateway status shown up as "online" for both IPv4 gateways in System: Gateways: Configuration?

How did you configure firewall rule for incoming traffic?

Hallo,

ich verwende Zertifikats-Authentifizierung selbst nicht und kann daher nicht mit Erfahrung dienen. Doch würde ich annehmen, dass, wenn die Client Authentifizierung im Frontend aktiviert ist, diese für alle Zugriffe gilt.

Wie sehen die Regeln aus, dass du dir davon einen Bypass versprichst?
Mit der Einstellung "optional" würde ich mir allerdings erwarten, dass auch Verbindungen ohne Client-Zertifikat akzeptiert werden, aber dennoch wird schickt der Server erst mal einen Zertifikats-Request, und möglicherweise mag das dein Client nicht.

Ist eine IP-basierte Authentifizierung nicht umsetzbar?
Wenn die Zugriffe von externen dynamischen IPs kommen, geht das natürlich nicht.

Soweit ich HAproxy kenne, würde dein Vorhaben nur mit TCP Frontends möglich sein. Da könntest du die Clients per SNI auf das richtige Frontend leiten und auf dem für xx.meinedomain.tld die Zertifikats-Auth aktivieren.

Deine Darstellung lässt aber vermuten, dass das auch schon alles ist, was du von HAproxy in deinem Setup erwartest. Meine Empfehlung wäre dann, auf Caddy zu wechseln. Der kann das und ist insgesamt sehr einfach zu konfigurieren.

Da kannst du die beiden Domains anlegen (Frontends) und direkt da auch eine oder mehrere in OPNsense eingerichtete CAs für die Client Authentifizierung auswählen.
Wenn du ein eingefleischter HAproxy Nutzer bist, ist die Caddy Konfiguration anfangs etwas gewöhnungsbedürftig, weil das Ding vieles automatisch macht und so die Einstellungsmöglichkeiten auf die nötigsten reduziert sind. Man möchte meinen,dasss Funktionen fehlen, doch für mein Heimnetz reicht es voll und ganz aus.

Grüße

Ahh.
No idea, how to do this.

Would use MAC auth.

Is there a way to configure the WAN to use 802.1x certificates to authenticate on the network?

Not clear, what you want to achieve with this in fact.

IEEE 802.1X is a network access control standard, which is not implemented in OPNsense out of the box. And certificates can be just used with it, but not necessarily.

You can install the FreeRADIUS plugin on OPN as authentication server and manage user accounts in it. But it requires an external authenticator like a switch to control the network access.
And of course this would also work on WAN.

Hallo,

hast du vielleicht einen alten Snapshot aktiviert?
Ein "R" in der Spalte Active bedeutet, dass dieser gebootet wird.

Grüße

Ahh. Thank you!

I searched the release notes for "kernel", but didn't find anything regarding this.

May we expect a fix for the business edition as well?

The most recent release from today is based on 26.1.9 and there is no fix regarding this CVE mentioned on the page. So I guess, it might be still vulnerable.

Or should we go the manual path by setting the tunable?

Hallo,

Warum gibt es die Unterpunkte "Regeln" und "Rules [new]" parallel nebeneinander ? Welches verwendet man besser ?

weil OPNsense das Regel-System gerade umstellt. Regeln / Rules sind die bisherigen. "Rules (new)" die neuen. Aktuell gibt es wegen Rückwärtskompatibilität eine Überschneidung. Wer alte Regeln verwendet, muss sie noch innerhalb der 26.x Version auf neue konvertieren, soweit ich weiß.

Wenn du also neu startest, beginne gleich mit den "Rules (new)".

Nehmen wir die PASS Regel als Beispiel - ginge auch:
Eingehend IPv4  LAN1Netzwerk  *  Firewall  DOMAIN(53) * *            - quasi das komplette LAN1 Netzwerk sendet DNS an die Firewall ?

Das erlaubt Zugriff auf den lokalen DNS Server.
Betreibt man einen in OPNsense (ist standardmäßig aktiviert), wird auch eine solche Regel automatisch gesetzt. Ist doch vernünftig.

Was bedeuted genau Eingehend und Ausgehend ??

Das ist die Sicht des Interfaces.

Regeln werden auf einem Interface definiert, bspw. LAN. Eingehend bedeutet, die Regel wird auf Traffic angewändt, der von einem LAN-Geräte rein kommt und irgendwo hingehen möchte (wohin, hängt von der Routingtabelle ab).
Ausgehend bedeuter eben, die Regel wird auf Traffic angewandt, der auf dem Interface raus geht.

Typischerweise definert man eingehende Regeln. Ausgehende für spezielle Zwecke.

Und warum wird das "Internes DNS erlauben" genauso eingestellt wie das "Externes DNS blockieren" ?

Wo ist diese Einstellung im Menü? Das sagt mir jetzt nichts.

ch will angenommen nur die Basis (53,67,68,80,443) erlauben für LAN1, alles andere was nach draußen will soll geblockt werden. Was rein und raus geht will ich nur durch Regeln erlauben.

Port 67,68 UDP auf die OPNsene ("This Firewall") wird auch automatisch erlaubt, wenn ein DHCP Server am Interface betrieben wird.

Dann gibt es noch die sog. "Anti-Lockout" Regel, die den Zugriff auf das Web-Interface auf den in System: Settings: Administration eingestellten Interfaces erlaubt.
Wenn du Port 443 für interne Services nutzt, solltest du auch den Web GUI Port da auf einen anderen ändern.
Wenn du Port 80 nutzt, sollte "HTTP Redirect" deaktiviert werden.

Standardmäßig hat OPNsense am LAN eine Regel gesetzt, die alles erlaubt, damit man erstmal starten kann. Das gilt aber ausschließlich für LAN. Bei weiteren Interfaces ist von Haus aus nichts erlaubt.
Wenn du nur die Ports 80 u. 443 ins Internet erlauben möchtest, setze eine Regel am jeweiligen Interface für eingehenden Verkehr und Protokoll TCP/UDP und den entsprechenden Zielport.
Die Standard Erlaube-alles Regel kannst du dann deaktivieren.

Bei den mehreren Erlauben- u. Block-Regeln bedenke, dass OPNsene den Regelsatz von oben nach unten prüft. Treffen die Bedingungen einer zu, wird sie angewandt. Weiter Regeln kommen dann nicht mehr zum Tragen.
Zu den Bedingungen gehören Interface, Protokoll, Richtung, IP-Version, Quell- u. Ziel-IP u. -Port.

Ein häufiger Anfängerfehler ist auch "WAN net" als das Internet anzusehen. Wenn du Traffic ins Internet erlauben möchtest, muss das Ziel "Alles" sein.

Bei Angabe der Firewall als Zielhost müsste es lauten 192.168.1.1 statt 192.168.1.1/24 in dem Fall, oder ?

Wenn deine Firewall dieses Ziel hat, ja.
Ist das eine OPNsense Interface IP?

Wenn du Subnetze als Ziel oder Quelle verwendest, muss eine Netzwerkadresse angeben werden.

Please try the forum search before posting.

https://forum.opnsense.org/index.php?msg=268021

Either not very many people are using VPN here, or they are not having the trouble.

I guess, it's the latter one.

I'm running two s2s IPSec, one s2s OpenVPN and three OpenVPN access servers on one instance. On another one I'm running the other site of the s2s OpenVPN plus an IPSec access server. All are running very stable.

If you have dropouts on both, there is probably an issue with the WAN connection or the hardware.
So check the system log for hints, enable gateway monitoring using a public monitoring IP, post logs...

I have only one public IP, therefore I use Edgerouter X as "dumb router" with switch interface (DMZ) as WAN gateway for both Opnsense instances.

So both nodes have configured an IP with the correct mask in the switch DMZ subnet?

Also ensure, that you have an outbound or source NAT rule for the source subnet 127.0.0.0/8, which uses the WAN IP as translation target on both.

Hallo,

Es ist so, dass bei uns die OPNSense zusammen mit HAProxy als reverse Proxy dient. Der ACME-Client erneuert für unterschiedliche Server die LE-Zertifikate regelmäßig direkt auf der OPNSense.

Nun ist es aber so, dass ich diese Zertifikate auch herunterlade (und zwar: firewall:/var/etc/acme-client/cert-home/$id/$hosts/fullchain.cer !!) und lokal direkt auf die Server verteile, damit man auch lokal bzw im Intranet damit arbeiten kann.

Andere Herangehensweise:
Ich verwende ebenfalls HAproxy, tlw. mit LE Zertifikaten vom ACME Client, und ebenfalls TLS Verbindungen zu den Backends. Allerdings habe ich auf diesen Zertifikate von einer internen CA auf OPNsense installiert.

Ich verwende hierfür kein Split-DNS, so dass die Hostnamen auf die auf WAN-IP aufgelöst werden. So laufen interne Verbindungen ebenfalls über HAproxy und die Clients bekommen das passende Zertifikat.

Wenn du allerdings einen Router davor geschaltet hast, müsstest du dennoch DNS Overrides konfigurieren, aber diese eben auf die OPNsense WAN setzen.

Grüße