Keine Verbindung zu self-signed https-Sites

Es gibt 18 Antworten in diesem Thema, welches 4.812 mal aufgerufen wurde. Der letzte Beitrag () ist von CARS10.

    Hallo liebe Gemeinde,


    ich bin neu hier, neu auch in der Unifi-Welt, aber ein "alter Hase" als SysAdmin ;-). Seit ein paar Tagen habe ich ein UDM (pro) im Einsatz. Soweit so gut und auch alles recht logisch. Diese steckt hinter ein Fritz!Box als exposed host. ich habe also doppeltes NAT, womit ich soweit auch gut leben kann. Ich habe jedoch ein Problem, welches sich mir nicht logisch erschließt.


    Wenn ich Server von mir via Browser (https) aufrufe, die über ein self-signed Zertifikat verfügen Funktioniert die Verbindung nicht. Um es genauer zu beschreiben, es geht primär um IPFire-UTM's, die ich nutze um Cloud-Netze abzusichern und die als VPN-Concentrator dienen. Ich kann eine (open)VPN-Verbindung (vom Client zur IP-Fire UTM) ohne Probleme aufbauen, sprich der Server ist erreichbar, ein https-request ist jedoch nicht möglich. Der Safari bleibt beim Ladebalken hängen und der Chrome schreit, dass die Website nicht erreichbar ist mit dem Fehler ERR_CONNECTION_REFUSED.


    Also kurzum, die Verbindung zur IP-Fire funktioniert tadelfrei, aber ich kann sie nicht mehr administrieren, denn ich komme nicht auf die webGUI. Auch die Server, die hinter der IP-Fire stehen sind via VPN einwandfrei erreichbar, nur eben die Appliance an sich nicht mehr. Wenn ich das über das Fritzbox Wlan mache geht es einwandfrei, nur nicht über das Wlan der Unifi.


    Kann mir jemand einen Tipp geben?


    Danke und Euch allen einen schönen Sonntag-Abend!


    Carsten

    Ach ja, kleiner Nachtrag: für mich ist das eine klare Sache, dass die Browser hier eine man-in-the-middle-attacke diagnostizieren/ vermuten. Ich habe das natürlich auch getestet, indem ich DPI und IDS/IPS ausgeschaltet habe. Lösung war das aber auch keine... Wie ich ein Gerät, anhand einer "Benutzergruppe" whitelisten o. ä. kann, habe ich noch nicht rausgefunden...

    Guten Morgen Samhain, danke erst einmal für Dein Feedback. Leider bringt es auch nichts, wenn ich alle Einstellungen und Conntrack Modules disable... Ich finde es schon spannend, dass anscheinend keiner das selbe Problem hat, ich aber mittlerweile auf 2 unterschiedlichen Unifi-Geräten. Einmal auf der UDM und einmal auf einer USM....


    VPN-Einwahl funktioniert einwandfrei, Ping ebenso, https-request passiert nichts. Safari bleibt hängen:


    Google Chrome sagt das hier, ohne eine Ausnahme anzubieten:

    2 Mal editiert, zuletzt von CARS10 ()

    Vermutlich hast Du auch schon mal alle Cookies und den Browser Cache geleert?


    Im Mac würde ich jetzt in der Schlüsselverwaltung alle Einträge zu o.g. IP löschen. Im Windows fehlt mir gerade ausser Cookies/Cache die Idee, wo das falsche/abgelaufene Zertifikat gelöscht werden könnte.

    ------

    vg

    Franky

    Hi, danke nochmal für Dein Engagement. Browserdaten sind alle (mehrfach) gelöscht, neue Browser installiert, neuen Rechner (Windows) aufgesetzt und probiert. Überall das gleiche. Aus einem anderen Netzwerk funktioniert der Zugriff ohne Probleme, so dass es ein UDM-Problem sein muss. Vtl ist noch wichtig, dass ich doppeltes NAT verwende, die UDM als GRE in der FB gekennzeichnet habe...

    Doppeltes NAT sollte keinen Einfluss auf Zertifkats Auswertung haben.


    Trotzdem zur Sicherheit - Folgende Ports sind nicht geblockt?


    - 443

    - 80

    - 8080


    bzw. die Frage, welche Ports geblockt sind?


    Die Erreichbarkeit der Applikation auf den jeweiligen Zielsystemen wurde auch nicht bzgl. Ports verändert?


    Wäre es möglich die Beschränkungen (wenn vorhanden) aus den Subnetzen mit der fehlerhaften Kommunikation zu deaktivieren?


    Mir fällt bei sowas leider nur ein, dass Du mal nen Wireshark anwirfst und Dir den Verbindungsaufbau mitsnifferst, dann sollte schnell klar sein, wo der Fehler zu suchen ist. Auch die Browser bieten über die jeweiligen Schnittstellen Analysefunktionen an.

    ------

    vg

    Franky

    Auf der 172.18.x.x ist IM VPN gar nichts geblockt. Wie gesagt, ich komme ja wunderbar auch drauf - aus anderen Netzen. Aus dem Netz der Unifi in Richtung 172.18.x.x ist auch nichts geblockt, bzw. alles noch auf Werkseinstellung. Diese habe ich am Samstag aktiv nochmal durchgeführt, was auch zu keiner Änderung geführt hat!


    Kommst Du aus Deinem Unifi-Netz via VPN auf https-gesicherte Websites via IPv4?

    Sorry. Hat etwas gedauert. Musste erst schnell VPN und DynDNS einrichten, dein Szenario mit reinem IP4 konfigurieren und nebenbei noch arbeiten :winking_face:


    Gesicherte Webseiten (https) sind über VPN Tunnel erreichbar.

    ------

    vg

    Franky

    Hhey erstmal vorweg: es ist echt freundlich von Dir, dass Du das nachstellst und mir hilfst!


    Also, egal an welcher Maschine ich es teste, ich baue eine OpenVPN-Verbindung (unterschiedliche Clients) zu einem anderen Server auf und versuche dann IM VPN-Tunnel eine https-Seite aufzurufen. Das geht absolut nicht! Ich wüsste auch gar nicht mehr, wo ich am Controller noch gucken sollte, denn erreichbar ist die Maschine ja. Ping ist überhaupt kein Problem, lediglich der httpS-request. Ich vermute, dass die UDM/USM das https aufbricht und neu verschlüsselt und die Browser das als man-in-the-middle-attacke identifzieren...

    Ich habs noch nicht ganz verstanden:


    Ist VPN Tunnel Endpunkt die UDM pro oder der Zielserver?



    Bei mir funktionieren übrigens beide Szenarien (VPN Endpoint UDM pro u. VPN Endpoint Synology). Allerdings ist meine Synology über keinen Standardport erreichbar, da ich den geändert habe.


    Evtl. kollidieren bei Dir Standardports? Kannst Du mal - wenn VPN Endpoint nicht die UDM pro ist - den Zielserver einen anderen Port für die VPN Terminierung verpassen?


    Noch ein Gedanke:

    Kann es sein, dass auch Traffic ausserhalb des VPNs zum Zielsystem gelangt? Das wäre dann fatal.

    ------

    vg

    Franky

    Der Endpunkt ist der Zielserver. Stell Dir vor Du authentifzierst Dich an Deiner Synology (die in einem fremden Netz hängt) und verbindest Dich dann auf die Synology via https://ip-adresse:5001 - das geht nicht!


    Wie sollte der Traffic außerhalb vom VPN zum Zielserver gelangen? Ich spreche ihn ja via 172er IP-Adresse an... Weiterhin ist der Server per public IPv4-Adresse nur via openVPN erreichbar...


    Irgendwas macht da am https die Unifi kaputt, wenn Du mich fragst. Als wenn ein proxy dazwischenhängt, der das Cert aufbricht...

    Die einzige Funktion die ein Aufbrechen des Kanals machen würde wäre DPI. Das ist bei Dir deaktiviert.


    Kommunikation an der VPN vorbei könnte ich mir nur über DNS Kommunikation vorstellen, aber wenn Du den Aufruf des Servers über IP machst, dann entfällt diese Fehlerquelle.


    Eine weitere mögliche Fehlerquelle wäre openVPN. Wäre es möglich, da was anderes zu nehmen oder die VPN Terminierung auf einem VPN Gateway zu machen?

    ------

    vg

    Franky

    Es kann hier schon am OpenVPN liegen, hierzu gibt es auch einige Beiträge im Internet zu. Ich würde auch noch mal ein anderes VPN-Tool nutzen um es zu testen. Sofern du via Windows arbeitest einfach mal den Integrierten VPN-Client nutzen. Der funktioniert in der Regel fehlerfrei.


    Gruß

    [Vigor 165] - [UDM Pro] - [USW-Aggregation-EU] - [USW-Pro-24-PoE-EU] - [USW Flex] - [USW Flex Mini] - [2x UAP-AC-Pro] - [3x UVC G4 Pro] - [3x UVC G3 Flex] - [1x UVC G3 Pro] - [2x NanoStation 5AC] - [Eaton Ellipse Pro 1600]

    Also, danke für Eure Beiträge.


    DPI habe ich zwar mittlerweile wieder aktiviert, aber auch im deaktivierten Zustand hat das nicht funktioniert. Zumindest habe ich es mehrfach schon deaktiviert und dann erneut probiert. Ich gehe davon aus, dass die UDM nach deaktivieren von DPI auch umgehend diese Funktion ausschaltet.


    Ich teste mit macOS11 und W10. VPN-Clients habe ich nun alle gängigen auf allen Plattformen durch. Bei keinem komme ich auf meinen WebServer.


    Das ist zum Mäusemelken mit dieser Thematik!

    • Offizieller Beitrag

    Hi,


    im Bild steht ganz deutlich NET::ERR_CERT_INVALID. Das bedeutet, dass das Zertifikat nicht zum Server passt. Ich vermute, dass die IP nicht im Zertifikat im SAN hinterlegt ist --> deswegen ERROR.


    Wie sieht denn das Zertifikat vom Server aus? Habe ich mit meiner Vermutung recht?


    BTW: sehr kuhler Nick :thumbs_up:. Ich habe auch schon CarStan versucht - vor allem wegen der Aussprache bei Personen im arabischen Raum. So habe ich es aber nicht versucht. :smiling_face:

    Hallo zusammen, ich habe das Problem gelöst, indem ich die Fritzbox neu aufgesetzt habe. An was es schlussendlich lag ist mir bis heute noch ein Rätsel, aber jetzt läuft es. Vielen Dank Euch allen - auch das Nick-Kompliment :winking_face: