Messages

Thanks a lot, guys! The floating rules only appear in the interface rules if there is at least one match. I expected to see an empty floating rules section when there are no matches.

That's my question: The way I understand it, floating rules should apply to all interfaces implicitly. Is that not the case?

I was trying to enter text in another window but unintentionally the input was sent to the web interface of the firewall, where I has an interface config open. When I noticed this, the UI had a button on top to apply the changes. I could not identify any change, so eventually I just pressed apply and checked the version history:

Code Select Expand

--- /conf/backup/config-1754987170.9107.xml 2025-08-12 10:26:10.917094000 +0200
+++ /conf/backup/config-1755073081.1818.xml 2025-08-13 10:18:01.189208000 +0200
@@ -1477,9 +1477,9 @@
     <interfaceslistfilter>opt10,lan</interfaceslistfilter>
   </widgets>
   <revision>
-    <username>root@192.168.50.42</username>
-    <description>/firewall_rules_edit.php made changes</description>
-    <time>1754987170.9107</time>
+    <username>root@192.168.50.45</username>
+    <description>/interfaces.php made changes</description>
+    <time>1755073081.1818</time>
   </revision>
   <OPNsense>
     <captiveportal version="1.0.2">
@@ -3114,7 +3114,9 @@
       <vlanif>vlan010</vlanif>
     </vlan>
   </vlans>
-  <bridges version="1.0.0"/>
+  <bridges version="1.0.0">
+    <bridged/>
+  </bridges>
   <gifs version="1.0.0">
     <gif/>
   </gifs>
The only substantial change is the bridged flag. Does anyone know what this is referring to?

Here are the screenshots. The floating rules don't even show up on the WANoE rule set.

Looking at the floating rules a bit closer, there's a counter "6" saying how many interfaces these rules apply to and hovering above the number even shows them by name. This FW has 11 interfaces, one of them disabled. The others are physical, VLANs and PPPoE, V4 only and dual stack, DHCP and static,... I don't see a pattern.

So, my question I guess is what causes floating rules not to be applied? I can't find anything in the docs

I just realised that floating rules are not always applied to WAN interfaces. Running 25.4.2 on 2 DEC750 systems, one has a PPPoE with VLAN WAN interface, the other has a physical ethernet interface as WAN. The floating rules are not applied to the PPPoE WAN. I haven't found any documentation on that. What should be the right behaviour?

Focussing on layer 2, are there any other bridges in your network that circumvent the FW, a switch, a laptop, etc? To find out, I would disconnect the LAN interface from whatever it is currently connected to, then connect something to make sure the interface is up, a simple switch maybe. If you still see traffic ingress from the WAN, your FW is behaving strangely.

And I don't understand your quote. When I do an ifconfig on a VLAN it doen't show the VLAN ID as part of the interface name but this:

Code Select Expand

vlan011: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        description: NetMA2 (opt12)
        options=4000000<MEXTPG>
        ether f4:90:ea:00:85:2d
        inet 192.168.144.1 netmask 0xffffff00 broadcast 192.168.144.255
        inet6 fe80::f690:eaff:fe00:852d%vlan011 prefixlen 64 scopeid 0xb
        groups: vlan Mitarbeiter
        vlan: 144 vlanproto: 802.1q vlanpcp: 0 parent interface: igb2
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

in /var/unbound/unbound.conf steht

Code Select Expand

# Custom includes
include: /var/unbound/etc/*.confScheinbar kann man dort lokale Anpassungen in ein oder mehrere Dateien packen.

While the source MAC is the same on the WAN and LAN interface, is there a chance that there are 2 VMware instances using the same MAC? One on the WAN, one on the LAN side?

Gut, vielleicht nochmal zur Klarstellung: Wenn "Dein" unbound im selben Netzwerk ist wie dein PC, dann ist keine Firewall dazwischen. Wenn jedoch die unbound Instanz auf der Sense verwendet wird, spielen die FW-Regel mit. Hier könnte eine Ursache liegen.

Die zweite Möglichkeit ist der verwendete unbound selbst. Wird die gleiche Version benutzt? Ich würde auch mal die Konfigurationsdateien vergleichen. Auf der Sense ist das /var/unbound/unbound.conf. Darin werden auch noch andere Dateien "include"d. Aus dem Vergleich der beiden Instanzen sollte klar werden, was der Unterschied ist.

Ich hatte auch mal ein ganzes Homelab auf einer Kiste und OPNsense als eine von vielen VMs unter Proxmox laufen. Aber die Abhängigkeiten, die man sich dadurch einhandelt, waren mir zu groß. Wann immer die OPNsense nicht richtig funktioniert, kommt man im Allgemeinen auch nicht mehr an Proxmox ran, usw. Das kann man natürlich alles mit einem zweiten, unabhängigen Netzwerk lösen. Aber das konterkariert irgendwie die Idee von "alles in eine Kiste". Für mich habe ich entschieden eine DEC750 zu kaufen. Damit unterstützt man auch gleich die Entwicklung der Software.

P.S.: Wenn das SFP-Modul durchgereicht wird, kann man die VM auch nicht mehr migrieren, außer - wiederum - durch redundante Hardware.

Wenn die Namesauflösung mit den üblichen Netzwerktools funktioniert, im Browser aber nicht, dann hilft vielleicht ein Blick in dessen Konfiguration. Will der vielleicht DNS over HTTPs machen oder besteht auf DNSSEC? Dann müssten die Firewall Regeln evtl noch dafür angepasst werden. Im LAN würde ich ohnehin eher darauf verzichten. Schon mal in den FW Logs nachgesehen ob das was blockiert wird?

Warum sollte ein Modem effizienter darin sein Ethernet Frames zu taggen als die OPNsense? Haben Modems Hardware dafür?

Danke für die Antwort. Sie ist zumindet so verständlich, dass ich eine neue Idee habe, was reply-to macht, auch wenn ich es noch nicht ausprobieren konnte:

Reply-to merkt sich das WAN Interface, auf dem ein Paket ankam, nicht das Gateway, von dem es kam. Dann darf es natürlich nur ein Gateway pro WAN geben, damit die Funktion eindeutig ist.

Wenn es tatsächlich so ist, dann sollte man die Funktion "reply-to" vielleicht besser "reply-via" nennen.

Bei Deinen Regeln ist das Loggin ausgeschaltet. Was auch immer da im Log steht, ist nicht das, was Du beschreibst.

Mehr als ein Gateway auf WAN Seite würde ich absolut tunlichst vermeiden.

Kannst Du mir bitte helfen zu verstehen, warum asymmetrisches Routing mit zwei Gateways im selben Netzwerk (WAN) ein potentielles Problem ist, aber nicht mit den selben Gateways in 2 Netzwerken?