Oct 27, 2022, updated at 18:39:37 (UTC)

7479

OPNsense VLANs haben kein Internet

Hallo,

ich bräuchte bitte Hilfe und zwar haben meine 4 VLANs kein Zugriff zum Internet trotzdem vermeintlich korrekten Firewall Regeln.
Mein LAN Netz funktioniert ohne Probleme.
Die OPNsense hat die IP 10.10.10.2

Ich nutze als DNS 2 Piholes 10.10.10.3 und 10.10.10.4. Diese funktionieren im LAN Netz auch super.
Unter System -> Settings -> Global habe ich 2 öffentliche DNS verwendet, da ich WAN Failover nutze.

Wenn ich mich z.B. im Gast (10.10.30.x) oder IoT (10.10.20.x) WLAN anmelde erhalte ich eine passende IP und mir werden beide DNS Server angezeigt.

Ich nutze 2 Regeln nach einem Video bei Youtube von Jürgen Barth:
1) DNS Zugriff von Gast auf die DNS im 10.10.10er Bereich.
2) RFC1989 Regeln als Pass und RFC1918 ist negiert.

Leider bekomme ich mit keinem Gerät Zugriff ins Internet.

Ich habe keine Ahnung wieso es nicht funktioniert. Eigentlich müsste alles richtig sein.

Please also mark the comments that contributed to the solution of the article

Content-Key: 4423483866

Url: https://administrator.de/contentid/4423483866

Printed on: April 27, 2024 at 14:04 o'clock

39 Comments

Latest comment

Hallo,

nur LAN geht per default raus.

Jedes neue VLAN ist Firewall Police techn. erstmal tot. Hier mal mit any Regel. Du kannst es später ja noch eingrenzen. DHCP reicht die neue Range. DNS kann leer bleiben.

Mitunter bleibt auch "Unbound DNS" mal hängen. Dann merkt man es normal auch im LAN. Denke Fw Pol fehlt bei dir....

PS: Sorry, hab überlesen das du schon Fw angepasst hast.

Ich hab WLAN für die Kinder so extra aufgebaut. Da gibt es so keine Probleme.

Was verbirgt sich hinter den Gruppen? Blockst ggf. zuvie? Firewall Live Log gibt Auschluss. Ggf. vorher Loggin aktivieren

Selbst mit der Any Regel am Anfang bekomme ich keine Verbindung (auch wenn die anderen beiden deaktiviert sind).

DNS sind meine beiden Piholes
RFC sind die Standard privat Netze die ich blocke.

EDIT:
IoT 2022-10-27T20:48:40 10.10.20.129 10.10.20.1 icmp Default deny / state violation rule

Hallo,

könnte es sein, das du eine Masqerading-Regel vergessen hast? Bei OPNsense heißt das Outbound-NAT, zu finden unter Firewall/NAT/Outbound.
Was steht da bei Dir?

cu,
ipzipzap

EDIT: Falschen Punkt gepostet

Zitat von @ipzipzap:

Hallo,

könnte es sein, das du eine Masqerading-Regel vergessen hast? Bei OPNsense heißt das Outbound-NAT, zu finden unter Firewall/NAT/Outbound.
Was steht da bei Dir?

cu,
ipzipzap

+1
Klingt für mich auch danach, dass das NAT vergessen wurde…

Gruß
em-pie

Moin,

wie sind denn die Gateways eingestellt?

Falls eine Gateway Group für Failover genutzt würde, müsste diese in die Firewall Policy mit eingetragen werden.

Viele Grüße

Würde erstmal noch wissen wollen, wie die OPNsense eingerichtet wurde. Wizard durchlaufen oder alles manuell?

Hab meine hinter einer FritzBox. Let's Encrypt etc. funktioniert auch alles. In der Standard Konfiguration sollte es eigentlich kaum Probleme geben. Any-2-Any und es müsste für einen ersten schnellen Test alles gut sein.

Bevor wir alles auseiander nehmen: Wie bist du vorgegangen? Läuft die OPNsense sonst normal? Keine Delays beim Speichern der Regeln oder ähnliches?

In der Grundkonfiguration reicht neues VLAN Interface zu definieren. Static IP und Auto-Detect. Unter DHCP reicht die Range. Als DNS würde dann die unter System hinterlegten angesprochen werden.

Sehe grad deine Hybrid NAT Regel. War die erforderlich? Ich hab privat zu Hause alles auf AUTO hier stehen.

Sehe grad: Gast, IoT, Kameras. Du hast also schon einen etwas komplexeren Aufbau.

Was ist mit Block private networks. Da der Haken drin?

Du kannst die Konfiguration binnen Sekunden ja resetten. Wenn es geht, würde ich einmal:
- NAT auf automtik stellen
- Block private networks auf NEIN außer ggf. bei WAN
- Firewall für VLAN auf any-to-any
- Ggf. DNS auf 8.8.8.8, 8.8.4.4 - Use Gateway auf NONE
- DHCP für VLAN: nur Range eintragen - von - bis. Sonst nichts.

So "reduziert" läuft es z.B. grad bei mir. Aus der Box mit diesen minimalen Einstellungen müsste es normal klappen.

Wie gesagt, Reset kostet einen ja müdesl lächeln bei der OPENsense. Ggf. bringt einen das in die richtige Bahn.

NAT kann man später ja wieder korrigierne. Nur dass wir erstmal einen status quo haben.

Hatte mal die Erfahrung gemacht, dass meine auf einen Testserver plötzlich beim Speichern der Regeln rumzickte etc. Am einfachsten ist die Einrichtung via Wizard - Initial. Und dann manuell Schritt für Schritt nach eigenen Wünschen konfigurieren.

Wenn alles nicht hilft, wäre ggf. eine Neuinstallation eine Möglichkeit.

Zitat von @Csui8n1:

Moin,

wie sind denn die Gateways eingestellt?

Falls eine Gateway Group für Failover genutzt würde, müsste diese in die Firewall Policy mit eingetragen werden.

Viele Grüße

Nach der Anleitung von Thomas Krenn, funktioniert auch super.
https://www.thomas-krenn.com/de/wiki/OPNsense_Multi_WAN
Unter Policy based Routing schauen, habe ich 1:1 übernommen.

Die Gatewaygruppe meiner 2 WANs habe ich als Gateway bei LAN ausgewählt. (Die VLANs hatten davor aber auch kein Internet soweit ich mich erinnere).
________________________________________

@Crusher79

Bei mir hängt ein Vigor davor. Die OPNsense macht PPPoE und setzt VLAN7 dazu -> funktioniert.

- Speichern etc klappt eigentlich recht fix, ab und zu hängt es, dann lade ich die Seite neu und es ist gespeichert.
- Block private ist nur bei WAN aktiv.
- Hybrid NAT ist wegen 3CX drin, war in diversen Anleitungen empfohlen daher hatte ich es übernommen. (die VLANs hatten aber vorher schon kein Internet).

IPs und DNS sind korrekt vergeben.

Reset meinst du die komplette OPNsense?

Habe da jetzt etliche Stunden reingesteckt, da ist alles neu aufsetzen natürlich nicht so geil. Würde die Config dann aber als VM in Proxmox laden, damit ich es nachbauen kann.

Zitat von @xhYtasx:

Zitat von @Csui8n1:

Moin,

wie sind denn die Gateways eingestellt?

Falls eine Gateway Group für Failover genutzt würde, müsste diese in die Firewall Policy mit eingetragen werden.

Viele Grüße

Im obigen Screenshot zu der Regel aus dem Netz Gast > !RFC1918 steht aber * als Gateway.
Hier müsste auch die Gatewaygruppe eingetragen werden.
Im Prinzip gilt das bei allen Regeln die Richtung WAN gehen.

Die !RFC1918 Regel kann einem aber bei LTE aber auch auf die Füße fallen da hier ja auch gerne selbige Ranges genutzt werden.

Wenn ich das Gateway in der Regel mit angebe kann auf die !RFC1918 Regel verzichtet werden.

Probiere ich aus. Müsste Any dann nicht auch funktionieren?

Ich habe eine öffentliche IPv4 für mein LTE WAN, daher passt das so.
Hatte vorher die UDM Pro am laufen und dort lief es auch mit den gleichen Einstellungen.

Dein Regelwerk ist unsauber. Du solltest zumindestesn die Source IP immer begrenzen auf Absender aus dem jeweiligen VLAN Netz, sprich es auf das Netz begrenzen. Mit deiner recht oberflächlichen Regel erlaubst du auch Absender Traffic von Gastusern die sich IPs aus allen anderen Bereichen selbst geben usw. was recht unsicher ist.

Dein Problem ist das du nicht wirklich sicher sagen kannst ob du ein reines DNS oder ein reines Routing Problem hast obwohl das sehr leicht zu differenzieren ist. "Kein Internet" ist ja für einen Troubleshooter eher etwas laienhaft.

Fazit:
Um generell Routing Probleme auszuschliessen solltest du als allererstes einmal prüfen ob du eine nackte Internet IP wie 8.8.8.8 anpingen kannst. Das lässt etwaige DNS Problematiken erstmal außen vor. Scheitert allein das schon hast du ein grundsätzliches Routing oder NAT Problem.
Klappt es dann ist auch eine Internet Verbindung an sich gegeben aber dann hast du ein DNS Problem.
Sinnvoll ist immer die Tools Ping, Traceroute und nslookup aus dem Diagnostics Menü auf der FW direkt zu verwenden. Indem man dort die Absender IP korrekt setzt kann man die Connectivity auch aus den VLAN Segmenten testen ohne einen Client dort.
Das sind grundlegende Schritte im Troubleshooting der Firewall. Alle anderen Details erklärt dir, wie immer, das hiesige VLAN Tutorial und seine weiterführenden Links.

Wenn du den Punkt "VLAN Routing mit OPNsense Firewall" meinst, so habe ich es eingerichtet.
Die VLANs etc werden ja korrekt zugewiesen.
Kann es evtl. am Gateway liegen? die IP der VLANs ist mit 10.10.xx.1 eingetragen, im LAN Netz ist es die 10.10.10.2

Also meinst du anstatt * Gast net oder IoT net etc? Klingt zumindest logisch, werde ich machen.

Kann es evtl. am Gateway liegen? die IP der VLANs ist mit 10.10.xx.1 eingetragen

Nein eigentlich ist das völlig unmöglich und außerdem stellt sich die Frage ja gar nicht.
Der DHCP Server in dem/den VLANs bzw. LAN vergibt ja immer die VLAN IP Adresse der Firewall in dem VLAN, folglich bekommen die Clients ja immer das korrekte Gateway. Logisch, denn die Firewall ist ja der Router in den Rest der Welt!
Mit anderen Worten: Bei dir scheitert also schon ein Ping auf 8.8.8.8 ?

Also meinst du anstatt * Gast net oder IoT net etc?

Richtig!

Ah ok, man hangelt selbst so mit den Anleitungen durch, da wird meistens any genutzt.

Ich meinte das Gateway ist in den VLANs 10.10.xx.1 angegeben, im LAN ist es 10.10.102. Aber wenn er es eh korrekt automatisch vergibt, passt es ja.

DNS bzw. meine Piholes funktionieren, diese sind im LAN und in den VLANs identisch und werden ja auch als DNS bei Windows/iPhone angezeigt. Wenn ich dem VLAN 1.1.1.1 als DNS eintrage, gibt es auch nicht.

Ich muss es heute Abend ausprobieren. WireGuard hat aktuell noch keine Verbindung ins LAN.

da wird meistens any genutzt.

Was fatal ist! Wozu setzt man denn sonst eine Firewall ein um Traffic sicherer zu machen.
Mit sinnfreien oder überflüssigen Banalregeln führt man eine Firewall ja völlig ad absurdum und sollte sie dann besser mit einer einfachen FritzBox ersetzen!

Ich meinte das Gateway ist in den VLANs 10.10.xx.1 angegeben

Unverständlich.... Ein Gateway muss man nirgendwo in einem VLAN angeben. Oder meinst du den Client in einem VLAN. Der lernt es doch per DHCP.

Aber wenn er es eh korrekt automatisch vergibt, passt es ja.

Das kannst du ja mit ipconfig -all oder ip a (Linux) immer selber sehen und prüfen!

Wenn ich dem VLAN 1.1.1.1 als DNS eintrage, gibt es auch nicht.

Was gibt es da nicht...unverständlich?

Letztlich aber auch völlig klar, denn wenn keiner deiner Endgeräte (und dazu gehören auch deine externen PiHole DNS Server) überhaupt eine Internet Verbindung hat WIE sollten diese dann auch in der Lage sein Hostnamen in IPs auflösen zu können. Dazu ist ja logischerweise erstmal ne Internet Verbindung nötig und wenn die schon mit nackten IP Adressen aus dem Firewall Diagnostics Menü scheitert hast du ja erstmal ein grundlegendes Problem.
Vielleicht solltest du besser nochmal bei Null anfangen mit einem Standard Setup das erstmal sauber zum Laufen bringen und das dann auf VLANs erweiteren, wiederum wasserdicht testen und dann die Dual WAN Geschichte angehen.
Immer strategisch vorgehen...! 😉

Ich meinte nicht gibt es auch nicht, sondern geht es auch nicht.

Die Piholes haben eine Verbindung ins WAN, die nutze ich ja im LAN Bereich. Da lässt sich auch etwas pingen und alles funktioniert. Also sind die Piholes ja korrekt.

Wenn es nicht anders geht, werde ich es wohl oder übel machen müssen.

Die Frage ist ja generell wie du die DNS Geschichte umsetzt?!
Normal benötigt man mit den PiHoles dann auch die Firewall überhaupt nicht mehr als DNS Server. In den jeweiligen LAN oder VLAN Segmenten vergibt man den Clients immer die PiHole IP per DHCP als DNS, so das diese dann die PiHoles direkt fragen.
Entsprechende FW Regeln natürlich vorausgesetzt das die Clients aus ihrem (V)LAN die PiHoles auch erreichen können. Es reicht ja ein zentraler PiHole der alle VLAN IP Netze bedient.
Der fragt dann seinen Uplink DNS und gut iss. Firewall ist DNS technisch komplett raus...
Eigentlich ja kinderleicht und kein großes Hexenwerk. "nslookup" und "dig" sind, wie immer, deine besten DNS Troubleshooting Freunde! 😉

DNS machen rein nur meine Piholes, die OPNsense macht nichts der gleichen.

Also aus dem Gast VLAN kann ich 8.8.8.8 anpingen

# /sbin/ping -4 -S '10.10.30.1'  -c '5' '8.8.8.8' 
PING 8.8.8.8 (8.8.8.8) from 10.10.30.1: 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=120 time=7.588 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=7.572 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=120 time=7.697 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=120 time=7.464 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=120 time=7.890 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.464/7.642/7.890/0.144 ms

Google.de ebenfalls:

# /sbin/ping -4 -S '10.10.30.1'  -c '5' 'google.de' 
PING google.de (142.250.184.227) from 10.10.30.1: 56 data bytes
64 bytes from 142.250.184.227: icmp_seq=0 ttl=120 time=7.768 ms
64 bytes from 142.250.184.227: icmp_seq=1 ttl=120 time=7.695 ms
64 bytes from 142.250.184.227: icmp_seq=2 ttl=120 time=8.128 ms
64 bytes from 142.250.184.227: icmp_seq=3 ttl=120 time=7.905 ms
64 bytes from 142.250.184.227: icmp_seq=4 ttl=120 time=7.799 ms

--- google.de ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.695/7.859/8.128/0.151 ms

Ebenso lässt sich der Pihole anpingen:

# /sbin/ping -4 -S '10.10.30.1'  -c '5' '10.10.10.3' 
PING 10.10.10.3 (10.10.10.3) from 10.10.30.1: 56 data bytes
64 bytes from 10.10.10.3: icmp_seq=0 ttl=64 time=0.426 ms
64 bytes from 10.10.10.3: icmp_seq=1 ttl=64 time=0.614 ms
64 bytes from 10.10.10.3: icmp_seq=2 ttl=64 time=0.337 ms
64 bytes from 10.10.10.3: icmp_seq=3 ttl=64 time=0.376 ms
64 bytes from 10.10.10.3: icmp_seq=4 ttl=64 time=0.341 ms

--- 10.10.10.3 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.337/0.419/0.614/0.103 ms

Nach meinem Verständnis ist also der DNS korrekt. Dann muss es an den Regeln liegen und nicht an den DNS.

nslookup vom Laptop:

C:\Users\hYtas>nslookup
DNS request timed out.
    timeout was 2 seconds.
Standardserver:  UnKnown
Address:  10.10.10.3

Nach meinem Verständnis ist also der DNS korrekt.

Das ist richtig!
Etwas interessanter wäre aber noch ein dig www.heise.de (ist im dnsutils Package) oder nslookup was dir dann immer zeigt welchen DNS Server der Client befragt.

Dann muss es an den Regeln liegen und nicht an den DNS.

Jepp, das sieht verstärkt danach aus. Ein Blick ins Firewall Log sollte da dann Aufklärung bringen.

Unter LAN steh pi.hole und bei Gast UnKown (siehe Oben).

Die beiden Logs finde ich:

Das war mein iPhone im Gast Netz.

VLAN03 blockt dann inbound ICMPs bei dir!
Das andere ist ein outbound UDP 53 DNS Paket was von 10.10.30.128 abgesendet wurde und an 10.10.10.4 geht.
Nett anzusehen aber wenig hilfreich wenn man das Regelwerk nicht kennt... 🤔

Es gibt nur 2 Regeln pro VLAN der Screenshot ist im ersten Beitrag.

Das mit any in den Regeln habe ich zu Gast net geändert
Die GW_Gruppe hatte ich ebenfalls in der Regel hinterlegt.

Zitat von @xhYtasx:

Es gibt nur 2 Regeln pro VLAN der Screenshot ist im ersten Beitrag.

Das mit any in den Regeln habe ich zu Gast net geändert
Die GW_Gruppe hatte ich ebenfalls in der Regel hinterlegt.

Ich kann jetzt natürlich nicht genau sehen was du umgestellt hast, aber die Gateway Gruppe natürlich nur für Regeln welche in Richtung WAN gehen.

Bei den Regeln zwischen den VLANs hat die natürlich nichts verloren.

Zitat von @Csui8n1:

Ich kann jetzt natürlich nicht genau sehen was du umgestellt hast, aber die Gateway Gruppe natürlich nur für Regeln welche in Richtung WAN gehen.

Bei den Regeln zwischen den VLANs hat die natürlich nichts verloren.

Zwischen den VLANs gibt es keine Regeln.

Die automatischen Regeln bei NAT Outbound sind auch alle angelegt.....

Hier hat jemand exakt das gleiche Problem:
https://forum.opnsense.org/index.php?topic=12865.0
gibt leider keine Lösung dazu.

EDIT:
Wenn ich im Gast DHCP meine Piholes gegen 1.1.1.1 ersetze dann hat mein Gast Netz Internet und es läuft. NSLOOKUP klappt auch.
Also scheint irgendwas am Pihole verkehrt zu sein.
Hatte gelesen das man nicht "Allow only local requests" nutzen soll sondern "Permit all origins" -> klappt aber auch noch nicht. Mal sehen was ich bei google dazu finde.

Auf den Piholes läuft unbound eigentlich ohne Probleme.
Mühsam ernährt sich das Eichhörnchen....

Zwischen den VLANs gibt es keine Regeln.

OPNsense macht in neu angelegten (V)LANs per default "deny all"

Wenn sich die DNS Server in einem anderen (V)LAN befinden wirst du um eine passende Regel wohl nicht herumkommen.

Die automatischen Regeln bei NAT Outbound sind auch alle angelegt.....

Hier hat jemand exakt das gleiche Problem:
https://forum.opnsense.org/index.php?topic=12865.0
gibt leider keine Lösung dazu.

EDIT:
Wenn ich im Gast DHCP meine Piholes gegen 1.1.1.1 ersetze dann hat mein Gast Netz Internet und es läuft. NSLOOKUP klappt auch.
Also scheint irgendwas am Pihole verkehrt zu sein.
Hatte gelesen das man nicht "Allow only local requests" nutzen soll sondern "Permit all origins" -> klappt aber auch noch nicht. Mal sehen was ich bei google dazu finde.

"Allow only local requests" sollte nicht aktiviert sein, da sonst Anfragen nur aus dem Subnetz beantwortet werden in welchem sich der PiHole befindet.

Mühsam ernährt sich das Eichhörnchen....

Zitat von @Csui8n1:
OPNsense macht in neu angelegten (V)LANs per default "deny all"

Wenn sich die DNS Server in einem anderen (V)LAN befinden wirst du um eine passende Regel wohl nicht herumkommen.

Die Regel gibt es ja schon:

Anpingen lässt sich der DNS ja auch und wird auch korrekt zugewiesen.

Irgendwas muss im Pihole nicht richtig sein

Zitat von @xhYtasx:

Die Regel gibt es ja schon:

In der Regel ist aber auch immer noch die Gateway Gruppe eingetragen.
Wie ich oben bereits schrieb ist das für die Kommunikation zwischen den (V)LANS nun nicht gerade zielführend.
Du aktivierst damit Policy-basiertes Routing und schickst die DNS Anfrage aus deinem LAN "GAST" in Richtung der beiden Internet Gateways. Dort wird das ganze logischerweise verworfen.

Anpingen lässt sich der DNS ja auch und wird auch korrekt zugewiesen.

Für ICMP scheint ja eine für uns nicht sichtbare Regel zuständig zu sein. Die aus dem Screenshot ist ja nur für TCP/UDP auf Port 53 zuständig und wird von daher nicht genutzt.

Für die Zuweisung ist ja der DHCP verantwortlich was auch nichts über die Erreichbarkeit aussagt.

Irgendwas muss im Pihole nicht richtig sein

Es macht es nicht gerade einfacher wenn man nur diese eine Regel sehen kann.

Gateway Gruppe aus DNS Regel entfernen
Aliase (DNS_Servers) überprüfen ("Apply" nicht vergessen)
Log in der o.g. Regel aktivieren und schauen ob die DNS Anfrage aus dem (V)LAN GAST Einträge erzeugt.

Zitat von @Csui8n1:

In der Regel ist aber auch immer noch die Gateway Gruppe eingetragen.
Wie ich oben bereits schrieb ist das für die Kommunikation zwischen den (V)LANS nun nicht gerade zielführend.
Du aktivierst damit Policy-basiertes Routing und schickst die DNS Anfrage aus deinem LAN "GAST" in Richtung der beiden Internet Gateways. Dort wird das ganze logischerweise verworfen.

Ok, Regel ist angepasst. Hatte mich verlesen.

Es macht es nicht gerade einfacher wenn man nur diese eine Regel sehen kann.

Gateway Gruppe aus DNS Regel entfernen
Aliase (DNS_Servers) überprüfen ("Apply" nicht vergessen)
Log in der o.g. Regel aktivieren und schauen ob die DNS Anfrage aus dem (V)LAN GAST Einträge erzeugt.

DNS Alias ist korrekt.

Log ist aktiv, es wird die DNS Anfrage UDP geblockt.

Regeln:

DHCP:

DNS General:

Pihole:

Viel besser

Im Log kann man jetzt gut sehen, dass die Default Deny zutrifft und beim PiHole nichts ankommen kann.
Logging hast du in der Erlaube DNS Regel auch aktiviert also sollten wir die in Grün sehen wenn diese zutrifft.

Man kann also davon ausgehen, dass das UDP Paket alle Regeln durchläuft ohne zu matchen und dann zum Schluss von der Default Deny Regel aufgehalten wird.

Was man auch gut sehen kann ist das der Source Port sich immer wieder ändert. Der ist von dir aber auf 53 festgelegt worden

Ändere das doch mal auf * und teste nochmal

Zitat von @Csui8n1:

Viel besser

Ändere das doch mal auf * und teste nochmal

Und schon funktioniert es.

1000 Dank auch für deine/eure Geduld.

Tut mir echt leid, es ist irgendwie nicht so einfach zu verstehen wie ich dachte.

So langsam komme ich aber dahinter :D
Bei UniFi muss man nicht viel denken…

Zitat von @xhYtasx:

Und schon funktioniert es.

1000 Dank auch für deine/eure Geduld.

Gerne

Tut mir echt leid, es ist irgendwie nicht so einfach zu verstehen wie ich dachte.

So langsam komme ich aber dahinter :D
Bei UniFi muss man nicht viel denken…

Dafür hast du mit OPNsense aber aber auch das flexiblere und bessere (meiner Meinung nach) System.

Kleiner Tipp zum Abschluss:
Regeln werden normalerweise von OPNsense von oben nach unten verarbeitet. Du hast in deinen LAN Regeln z.B. erst eine Default Allow und dann eine Block DNS Regel. Die wird so vermutlich nie zutreffen.

Viele Grüße

Von oben nach unten wir bekannt, aber danke für den Hinweis habe ich übersehen/geändert.

Besser auf jeden Fall!

- Ich hatte jeden Tag 10 + WAN Disconnects -> seitdem nur die 24h Disconnects
- Die UDM-Pro hat sich oft aufgehängt, nur Stecker ziehen half.
- Die Firmware ist teilweise ein Katastrophe
- Die Entwickeln lieber neue Produkte als alte zu fixen.
- Kein Loadbalancing
- Keine Möglichkeit von eigenen Blocklisten

und und und

Regeln werden normalerweise von OPNsense von oben nach unten verarbeitet.

Das ist nur zum Teil richtig... Die Reihenfolge gilt zwar aber dennoch gilt die für Firewalls und ACLs gültige Grundregel: "First match wins!"
Sprich beim ersten positiven Hit wir der Rest des Regelwerkes nicht mehr abgearbeitet. Die genaue Reihenfolge des Regelwerkes ist also wichtig.
Die OPNsense supportet zwar auch outbound Regeln man sollte diese aber besser nie oder nur wenn wirklich zwingend nötig nutzen. Sprich das Regelwerk gilt im Normalfall immer inbound. VOM Netzwerkdraht IN das FW Interface hinein.

Wenn ich etwas intern erreichen möchte von außerhalb, muss ich ja outbound nutzen.

Nein, das ist der falsche Ansatz. Dann filterst du logischerweise inbound am WAN Interface. Es wäre ja völliger Blödsinn ungewollten Traffic zuerst in die Firewall zu lassen um ihn dann outbound doch zu filtern. Nicht nur das es gefährlich ist, es kostet auch sinnlos Performance zumal outbound Filter immer über die CPU laufen. Zeugt fast immer von einer fehlerhaften und nicht durchdachten Filterstrategie...

Ich meinte natürlich Port forwarding. Outbound brauchte ich für 3CX.

Da hast du dann Recht. Port Forwarding ist ja ne ganz andere Baustelle und hat mit in- oder outbound Firewallregeln nicht das Geringste zu tun...

Zitat von @aqui:

Regeln werden normalerweise von OPNsense von oben nach unten verarbeitet.

Du hast natürlich völlig recht. Das habe ich wohl etwas zu vereinfacht dargestellt.
Ich wollte jetzt aber auch nicht noch zusätzlich Verwirrung stiften

Glaub mir, aktuell ist da noch einiges an Verwirrung :D
Es wird aber besser, wenn man weiß wie es korrekt ist.

Im Internet gibt es leider viel Mist, auch von vermeintlich guten Quellen. Und wenn dies dann noch falsch ist bzw. es anders besser geht.
Da hat man es als OPNsense Anfänger schwer.

German solved Question Firewall