OPNsense Forum
International Forums => German - Deutsch => Topic started by: opnsense_user12123 on December 25, 2017, 03:25:02 pm
-
Hi!
self signed zertifikate funktionieren in allen Browsern ohne Probleme.
sobald man aber versucht ein server, client oder ein authority certifikat auf einem server zu verwenden wird dieses vom Browser als SSL_ERROR_BAD_CERT_DOMAIN nicht akzeptiert. Hab wirklich alles ausprobiert.
Einzig wenn man "Log SNI information only" aktiviert funktioniert es. Da ich aber gelesen habe, dass dies sicherheitstechnisch nicht gut ist, wenn man dies aktiviert, habe ich es wieder deaktiviert.
Unter Pfsense hat das alles ohne Probleme funktioniert. Unter OPNsense geht es nicht.
Hat das schon mal jemand getestet ?
Was kann ich tun ?
Ich würde dringend um Hilfe bitten!
Danke Euch!
Alles Details siehe Screenshots
-
First of all: your request and your domain do not match (home != local).
Second: Squid does not trust your self signed certificate which is the reason for this waning. You can add this server to the no bump sites (you cannot intercept it but it will work) or trust it via the configuration file (would not recommended that).
-
das "local" das der Browser ausgibt, habe ich nirgends angegeben.
1. Ich muss also den DNS Namen des Problemservers in der no bump liste eintragen damit es funktioniert?
2. Warum kann man dann das CA Zertifikat auswählen ( CA to use ), wenn dies sowieso nicht funktioniert?
meine domain ist "home"
und beim erstellen der zertifikate habe ich als dns den FQDN angegeben. z.b drucker.home und ie IP (siehe screenshot mit der nummer "3")
So steht es auch im Zertifikat wenn ich mir die details ansehe.
Deshalb verstehe ich die Browsermeldung auch überhaupt nicht. Wo das local herkommt konnte ich in keiner Weise nachvollziehen.
-
1. Damit kannst du das Problem umgehen, dass Squid dem Zertifikat nicht traut (was auch das korrekte verhalten ist.
2. Das CA-Zertifikat ist für die Verbindung zwischen deinem Proxy und deinem Client. Es gibt allerdings eine zweite TLS-Verbindung zwischen Proxy und Server (bzw. in deinem Fall Drucker). In letzterer agiert Squid als client und muss das Zertifikat validieren, kennt diese nicht da es selbstsigniert ist und verweigert die Verbindung wie es auch ein Browser machen würde. Im Gegensatz zum Browser gibt es halt derzeit keinen trotzdem erlauben Button.
-
1. Damit kannst du das Problem umgehen, dass Squid dem Zertifikat nicht traut (was auch das korrekte verhalten ist.
2. Das CA-Zertifikat ist für die Verbindung zwischen deinem Proxy und deinem Client. Es gibt allerdings eine zweite TLS-Verbindung zwischen Proxy und Server (bzw. in deinem Fall Drucker). In letzterer agiert Squid als client und muss das Zertifikat validieren, kennt diese nicht da es selbstsigniert ist und verweigert die Verbindung wie es auch ein Browser machen würde. Im Gegensatz zum Browser gibt es halt derzeit keinen trotzdem erlauben Button.
Das hat leider nicht funktioniert. Zwar bekomme ich jetzt nicht mehr die BAD_CERT_DOMAIN Fehlermeldung aber egal ob ich .home .PC.home oder PC.home oder IP im no bump eintrage noch immer nicht den gwünschten erfolg. seltsamerweise kann ich auch auf meinen router mit webgui ssl zertifikat nur von einem einzigen pc zugreifen ohne den Fehler SSL_ERROR_BAD_CERT_DOMAIN zu bekommen. Obwohl ich auf allen anderen Windows Clients (win7) das self signed zertifikat genau so installiert habe. im firefox und im certmgr.msc (vertrauenswürdige stammzertifikate). nur die normalen webseiten https webseiten machen keine probleme. alles was im lan ist funktioniert auf keinem client. nur auf einem einzigen lässt sich der router ohne fehlermeldung aufrufen. Bin mit meinem Latein am Ende. Muss schon sagen. Keines dieser Probleme hatte ich unter pfsense. da ging das alles ohne probleme.
-
1. Damit kannst du das Problem umgehen, dass Squid dem Zertifikat nicht traut (was auch das korrekte verhalten ist.
2. Das CA-Zertifikat ist für die Verbindung zwischen deinem Proxy und deinem Client. Es gibt allerdings eine zweite TLS-Verbindung zwischen Proxy und Server (bzw. in deinem Fall Drucker). In letzterer agiert Squid als client und muss das Zertifikat validieren, kennt diese nicht da es selbstsigniert ist und verweigert die Verbindung wie es auch ein Browser machen würde. Im Gegensatz zum Browser gibt es halt derzeit keinen trotzdem erlauben Button.
(https://webssl)
Das ist der Fehler den ich von den anderen Clients bekomme wenn ich nur versuche auf den Router per ssl per FWDN zuzugreifen. (screenshot) -> per ip kommt die alte Fehlermeldung.SSL_ERROR_BAD_CERT_DOMAIN
es wird zwar im browser "grün" angezeigt, aber nicht akzeptiert. (screenshot)
wie gesagt, der zugriff funktioniert auf den router per https nur von einem pc aus.
aber auf allen anderen pc´s ist das self signed zertifikat genau so installiert.
-
wenn router.home die OPNsense ist, kann es sein dass es unterschiede in den NAT-Regeln gibt (Anti-Lockout?)
-
wenn router.home die OPNsense ist, kann es sein dass es unterschiede in den NAT-Regeln gibt (Anti-Lockout?)
Hallo Fabian,
ich habe dir einen screenshot der NAT Forwarding Regeln gemacht und die firewall regeln für jedes interface
Die noproxy regel habe ich deaktiviert. macht aber keinen unterschied.
lg und Danke
-
Im Fall LAN1 verhindert die Anti-Lockout die umleitung an den Proxy, Für LAN2 (keine Ahnung was in "noproxy" drin ist) ist die Regel deaktiviert.
-
Im Fall LAN1 verhindert die Anti-Lockout die umleitung an den Proxy, Für LAN2 (keine Ahnung was in "noproxy" drin ist) ist die Regel deaktiviert.
Siehst du einen Grund für mein Problem anhand der Regeln?
Im Lan2 und LAN3 habe ich genau dieselben Probleme. Wenn es nicht an den Regeln liegt, dann hat die squid Konfiguration oder das OpenSSL ein Problem.
Wie komm ich jetzt zu einer Lösung?
Lg und Danke
-
* Entweder die auf die no bump liste setzen
* diese Hosts am Proxy vorbei erlauben (no-rdr)
-
* Entweder die auf die no bump liste setzen
* diese Hosts am Proxy vorbei erlauben (no-rdr)
1. das Problem das clients aus anderen Subnetzen nicht auf die Admin Oberfläche des Routers gekommen sind, konnte ich durch eine "Antilockout"- NAT Regel beseitigen. Das heißt jedes LAN hat nun seine eigene Antilockout-Regel. Danach musste ich noch die gesamte Domain ".home" auf die NO Bump Liste setzen.
2. Das zweite Problem mit den einzelnen Servern (Drucker usw.) werd ich mal versuchen mit einer "no-rdr" Regel hinzubekommen!. Hoffe ich bin da gedanklich am richtigen Weg.
Da hätte ich eine Frage zu der "no bump" Liste. Kann man hier auch einen ALIAS verwenden? und welche (URL,HOST usw) -Liste müsste ich verwenden um ".home" und IP Adressen gemeinsam eintragen zu können?
Danke Fabian. Du hast mir schon sehr geholfen und wahrscheinlich auch vielen anderen die OPNsense verwenden.
Ich sollte mir ein Buch kaufen. Denn ganz nachvollziehen kann ich die diversen Regeln noch nicht ganz.
-
* Entweder die auf die no bump liste setzen
* diese Hosts am Proxy vorbei erlauben (no-rdr)
ich habs hinbekommen. Die gewünschten Clients kommen jetzt auf die Admin GUI und die Zertifikate der Server werden akzeptiert.
1. so wie beschrieben habe ich die gesamte Domain und die ip´s der server clients in der no bump liste eingetragen.
2. dann habe ich mir drei nat port forwarding rules erstellt. pro interface eine (screenshot)
3. dann habe ich mir pro interface eine eigene anti lockout regel erstellt. (screenshot) -> die standardregel habe ich deaktiviert.
alles funktioniert jetzt. siehe screenshots.
Es wäre toll wenn sich jemand die screenshots anschauen könnte und mir vielleicht sagen könnte was man anhand der regeln besser bzw sicherer machen könnte.
eine Letzte Frage dazu. NAT Portforwarding wird nicht von oben nach unten abgearbeitet ? Ist das richtig ? und zweitens: Kann ich mir das Portforwarding wie direkte Brücken vorstellen die unter bestimmten Bedingungen befahren werden können aber nicht müssen ?
Danke an Fabian!
-
* Entweder die auf die no bump liste setzen
* diese Hosts am Proxy vorbei erlauben (no-rdr)
ich habs hinbekommen. Die gewünschten Clients kommen jetzt auf die Admin GUI und die Zertifikate der Server werden akzeptiert.
1. so wie beschrieben habe ich die gesamte Domain und die ip´s der server clients in der no bump liste eingetragen.
2. dann habe ich mir drei nat port forwarding rules erstellt. pro interface eine (screenshot)
3. dann habe ich mir pro interface eine eigene anti lockout regel erstellt. (screenshot) -> die standardregel habe ich deaktiviert.
alles funktioniert jetzt. siehe screenshots.
Es wäre toll wenn sich jemand die screenshots anschauen könnte und mir vielleicht sagen könnte was man anhand der regeln besser bzw sicherer machen könnte.
eine Letzte Frage dazu. NAT Portforwarding wird nicht von oben nach unten abgearbeitet ? Ist das richtig ? und zweitens: Kann ich mir das Portforwarding wie direkte Brücken vorstellen die unter bestimmten Bedingungen befahren werden können aber nicht müssen ?
Danke an Fabian!
Wäre über Feedback sehr erfreut! DANKE! :-)
-
Alle Regeln werden von oben nach unten abgearbeitet - egal ob Filter oder NAT.
Nat kannst du dir eher so vorstellen as ob jemand bei einem Brief die Adresse (Absender und/oder Empfänger) auf dem Postweg überklebt. Es sollte nichts am Inhalt ändern aber außen steht was anderes drauf.
PS: In OPNsense wird alles standardmäßig blockiert. Das heißt do solltest keine eigene Regel dafür machen.
-
und die Regeln die ich erstellt habe. Würden die passen?
-
Kann ich nicht sagen, musst du für dich selbst beantworten weil die Regeln immer nur die Ableitung von den eigenen Sicherheitszielen sind.
-
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 ?
-
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.
-
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 (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 (https://wiki.opnsense.org/manual/how-tos/transparent_bridge.html?highlight=lockout#disable-default-anti-lockout-rule)
-
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.