SSL_ERROR_BAD_CERT_DOMAIN ?

[opnsense_user12123]

und die Regeln die ich erstellt habe. Würden die passen?

[fabian]

Kann ich nicht sagen, musst du für dich selbst beantworten weil die Regeln immer nur die Ableitung von den eigenen Sicherheitszielen sind.

[opnsense_user12123]

Kann ich nicht sagen, musst du für dich selbst beantworten weil die Regeln immer nur die Ableitung von den eigenen Sicherheitszielen sind.

OK. DANKE !

Zwei allerletzte Fragen habe ich noch.

1. Was wird früher abgearbeitet. Das Port Forwarding oder die Firewall-Rules ?
2. Bzgl. eigener Anti-Lockout-Rule -> Warum muss zusätzlich zu meiner LAN Regel noch eine NO-RDR NAT-Regel machen damit nur explizite clients auf mein Router GUI zugreifen können ?
Von der Logik her dachte ich, sobald ich eine Regel auf einem Interface erstelle die nur gewissen clients(IP´s) Zugriff auf mein Webinterface zulassen und danach noch eine Regel, dass alle anderen geblockt werden, dachte ich den Zugriff explizit für die clients eingeschränkt zu haben. Zu meinem Erstaunen musste ich aber eine "no-rdr" mit einer "invert source" NAT Regel für die clients hinzufügen damit der Zugriff nur für die ausgewählten clients auf das Router GUI möglich ist.

Warum ist das so ? Ich verstehe das nicht. Kann mir das jemand erklären ?

[fabian]

1. Was wird früher abgearbeitet. Das Port Forwarding oder die Firewall-Rules ?

Es gibt hier nur eine logische Reihenfolge:
* DNAT (Portweiterleitung)
* Filter (Firewall Policy)
* SNAT (Netz hinter einer IP)

2. Bzgl. eigener Anti-Lockout-Rule -> Warum muss zusätzlich zu meiner LAN Regel noch eine NO-RDR NAT-Regel machen damit nur explizite clients auf mein Router GUI zugreifen können ?
Von der Logik her dachte ich, sobald ich eine Regel auf einem Interface erstelle die nur gewissen clients(IP´s) Zugriff auf mein Webinterface zulassen und danach noch eine Regel, dass alle anderen geblockt werden, dachte ich den Zugriff explizit für die clients eingeschränkt zu haben. Zu meinem Erstaunen musste ich aber eine "no-rdr" mit einer "invert source" NAT Regel für die clients hinzufügen damit der Zugriff nur für die ausgewählten clients auf das Router GUI möglich ist.

Die No-RDR verhindert die Portweiterleitung. Der Zweck dieser Regel ist die Verhinderung von einer Portweiterleitung. Dies kann einfacher sein als die Clients zu spezifizieren, die nicht in der Weiterleitungsregel stehen sollen. Zum Beispiel könntest du auch einen Alias definieren und sagen Quelle nicht dieser Alias. Es macht die Regel einfach nur komplizierter und wenn ich eine eigene Ausnahmeregel habe, kann ich die mit einem Klick deaktivieren. Würde mal sagen das ist Geschmacksache.

[opnsense_user12123]

1. Was wird früher abgearbeitet. Das Port Forwarding oder die Firewall-Rules ?

Es gibt hier nur eine logische Reihenfolge:
* DNAT (Portweiterleitung)
* Filter (Firewall Policy)
* SNAT (Netz hinter einer IP)

2. Bzgl. eigener Anti-Lockout-Rule -> Warum muss zusätzlich zu meiner LAN Regel noch eine NO-RDR NAT-Regel machen damit nur explizite clients auf mein Router GUI zugreifen können ?
Von der Logik her dachte ich, sobald ich eine Regel auf einem Interface erstelle die nur gewissen clients(IP´s) Zugriff auf mein Webinterface zulassen und danach noch eine Regel, dass alle anderen geblockt werden, dachte ich den Zugriff explizit für die clients eingeschränkt zu haben. Zu meinem Erstaunen musste ich aber eine "no-rdr" mit einer "invert source" NAT Regel für die clients hinzufügen damit der Zugriff nur für die ausgewählten clients auf das Router GUI möglich ist.

Die No-RDR verhindert die Portweiterleitung. Der Zweck dieser Regel ist die Verhinderung von einer Portweiterleitung. Dies kann einfacher sein als die Clients zu spezifizieren, die nicht in der Weiterleitungsregel stehen sollen. Zum Beispiel könntest du auch einen Alias definieren und sagen Quelle nicht dieser Alias. Es macht die Regel einfach nur komplizierter und wenn ich eine eigene Ausnahmeregel habe, kann ich die mit einem Klick deaktivieren. Würde mal sagen das ist Geschmacksache.

Super Fabian. Habs kapiert!. Konnte dank deiner Unterstützung nun die Regel vereinfachen. :-)

Hab jetzt per NAT pro Interface jeweils eine NO RDR erstellt, die einfach alles auf das Admin Gui blockt.
Danach noch pro Interface eine Filter-Regel die explizit die Clients die ich wünsche zulässt.-> Perfekt! :-) DANKE!

Auf der Manual Seite von OPNsense gibt es zum thema SPAMHOUSE eine Anleitung. -> https://wiki.opnsense.org/manual/how-tos/edrop.html
Nach deinen Infos frage ich micht jetzt aber, warum man den Outbound Traffic nicht mit einer NO RDR blockiert? In der Anleitung wird es mit einer Filter Regel beschrieben.

P.S. Übrigens in der aktuellen Anleitung von OPNsense ist der Link zur Anti lockout rule falsch! Hier wird sie noch so verlinkt -> Goto System -> Settings -> Admin Access :Anti-lockout and select this option to disable!

Die findet sich jetzt ja hier -> FIREALL - SETTINGS - ADVANCED -> "Disable administration anti-lockout rule"
Hier ist die Seite mit der falschen Verlinkung im Wiki von OPNsense -> https://wiki.opnsense.org/manual/how-tos/transparent_bridge.html?highlight=lockout#disable-default-anti-lockout-rule

[fabian]

P.S. Übrigens in der aktuellen Anleitung von OPNsense ist der Link zur Anti lockout rule falsch! Hier wird sie noch so verlinkt -> Goto System -> Settings -> Admin Access :Anti-lockout and select this option to disable!

Die findet sich jetzt ja hier -> FIREALL - SETTINGS - ADVANCED -> "Disable administration anti-lockout rule"

Jetzt nicht mehr - Hab es schon aktualisiert

Mit dem nächsten Version der Dokumentation wird's wieder passen.