Beiträge von tobias.x

    GELÖST


    Peinlich, peinlich, peinlich.....


    Nachdem ich verwundert feststellte, dass sich auf meinem Cloud Key mit der Version 5.12.66 mitnichten der aktuellste Controller befand, versuchte ich ein Update. Dauernd nur die Meldung: Auf dem neuesten Stand. Komisch, dachte ich. Vielleicht werden Updates zwischen großen Versionen nur über Dateien ausgeführt?


    Also, versucht per SSH upzudaten: Und siehe da: Keine Internetverbindung.


    Komisch....


    Weitere Suche... am Ende sah ich, dass das Gateway im Cloud Key falsch eingetragen war: Statt 192.168.2.1 stand dort 192.168.1.1.


    Tja, nachdem ich das geändert hatte, funktionierte das update auf die 6.0.45 sofort (hoffentlich war das kein Fehler, in der Wartezeit bin ich beim Googeln nach Beschreibungen bei Reddit gelandet - das macht ja keine Freude, dort zu lesen....


    Und auch der Zugriff funktionert nun endlich vom WAN auf den Cloudkey.


    Sogar ohne Portforwarding, genauso, wie ich es mir ausgedacht hatte.


    Vom PC aus im "echten" LAN greife ich nun über unsere PFSense-Firewall und den Umweg über das gemeinsame WAN zurück durch das Ubiqitit Gateway auf den Cloudkey im dortigen LAN zu.


    Ich gebe am PC einfach die IP-Adresse des Cloudkeys ein. Das geht dann ans Default Gateway (unsere PFSense Firewll), von dort an die Fritzbox, dort wird per in der Fritzbox hinterlegter Route das Paket zum WAN-Port des Ubiquiti Gateways weitergeleitet, und das Gateway liefert das dann an den Cloud Key. Genauso, wie es sein soll. Es geht also erfreulicherweise auch ohne Port Forwarding.


    Was ich nun nur noch probieren muss, ob es auch von extern per in der Fritzbox endendem VPN funktioniert, aber davon gehe ich eigentlich aus...


    Danke an alle, die mir versucht haben zu helfen, und auf so einen dämlichen Fehler natürlich nicht kommen konnten...


    Jetzt ist die Welt wieder in Ordnung... :smiling_face:


    P.S.: Und ziemlicher Wahrscheinlichkeit war mein anderes Problem mit der Uhrzeit auch dadurch bedingt. Komisch nur, dass die Controller-Software durchaus die richtige Zeit an manchen Stellen hatte vielleicht vom Webbrowser?

    Noch eine dumme Frage:


    Muss ich nach Änderungen in den Firewalleinstellungen oder Portweiterleitungen anschließend manuell eine "zwangsweise" Provisionierung des Gateways anstoßen, oder geht das automatisch? Das hatte ich nämlich bisher nicht gemacht... Probiere ich gleich mal...


    Etwas später:


    Nein, auch nach manueller Provisionierung des Gateways funktioniert der Zugriff vom Laptop im WAN per Portweiterleitung auf den Cloud Key im LAN nicht.. :frowning_face:

    Ok, also ich teste jetzt mal ganz nativ mit Laptop direkt auf der WAN-Seite (somit sind Doppel-NAT und andere Probleme definitiv ausgeschlossen):


    Hardwareseitig gegeben:

    WAN-Netz: (Fritzbox-LAN: 192.168.180.1, Unifi GW: 192.168.180.30, Laptop: 192.168.180.51)

    LAN-Netz: Cloud-Key: 192.168.2.6


    Einstellung:

    Port-Forwarding am WAN Port:

    Port 52000 an 192.168.2.6 Port 8443


    Eine Firewallregel hat das Gateway automatisch zu der Portweiterleitung angelegt, nice.


    Aktion:

    Eingabe im Webbrowser am Laptop:

    192.168.180.30:52000


    Ergebnis:

    Geht nicht... Netzwerk-Zeitüberschreitung


    Mal dumm gefragt:

    In meiner naiven Vorstellung müsste es eigentlich ja sogar auch ohne Portforwarding funktionieren, einfach indem ich eine WAN-IN Regel in der Firewall definiere, in der ich den Zugriff von z.B. WAN-Netzwerk 192.168.180.0/24 nach LAN:192.168.2.6 (Unifi Key im LAN) erlaube.


    Die Antwort vom Key in Gegenrichtung zum Laptop müsste ja eigentlich sowieso ohne extra Regel durch die Firewall kommen, weil man vom LAN aus ja sowieso auf das gesamte Internet zugreifen kann. Auf jeden Fall - eben gerade gecheckt: Mit dem Laptop, der ans LAN angeschlossen ist, komme ich problemlos auf die Fritzbox im WAN.


    ODER, FRAGE:

    Kann ein Gerät im LAN zwar Verbindungen nach außen aufbauen, aber nicht auf Verbindungsanforderungen von außen antworten?


    Leider kann man die vordefinierten ausgegrauten Firewallregeln sich ja leider nicht im Detail angucken....

    .

    Hast Du das Datum mal manuell (date-Command) sehr nah an HEUTE() gesetzt und klappt das dann mit dem NTP? Ich meine, dass Unix-basierte Systeme das nicht so lustig finden, wenn die Zeit extrem aus dem Ruder läuft.

    Vielleicht hilft Dir das ja.


    KLASSE!


    Danke, das war die Lösung!

    Ob NTP funktioniert, habe ich noch nicht gecheckt, aber jetzt stimmen auf jeden Fall schon einmal die Zeiten in den Logs!


    Auf so etwas Einfaches hätte ich eigentlich auch kommen können :winking_face:

    Danke Dir umso mehr...


    P.S.: Hat der Cloud Key Gen1 eine eingebaute Uhr? Eine zugehörige Knopfzelle?

    Ja, genau so sah die NTP-Serverliste bei mir ursprünglich auch aus. Zur Fehlerlösung hatte ich dann die ersten beiden Einträge durch ptbtime1.ptb.de und ptbtime2.ptb.de ersetzt,., 2.ubnt.pool.ntp.org habe ich stehen lassen, und irgendwann hatte ich dann noch den letzten Eintrag auf die Fritzbox geändert (192.168.180.1).


    Wie gesagt, bis auf die Zeit im Ereignisprotokoll stimmt ja überall die Zeit auch. Sogar direkt obem am Ereignisprotokoll, wenn ich dort auf den Kreis mit der 31 (Monatsansicht) klicke, wird mir der März 2021 als Übersicht angezeigt (aber entsprechend leer).


    Was das Zeitformat angeht, so hatte ich hier tatsächlich gleich am Anfang "herumgemurkst". Bei mir steht dort zurzeit, in der Hoffnung, dass dies die Default Werte sind, wieder:



    Zeitformat: H:mm

    Datumsformat: MM/DD/YYYY


    Ich würde ja aber eigentlich denken, dass dies nur die Formatierung für die Ausgabe der Zeit betrifft, und dass dies nicht essentiell für das Erkennen der von NTP angelieferten Zeit ist... (?)





    Jetzt könnte vielleicht

    Hi!


    Im Controller ist unter Einstellungen> Site / Standort die Zeitzone einzutragen.
    Dann sollten sich die Geräte mit dem Controller aktualisieren!


    Gruß!

    Danke Dir für den Hinweis. Das hatte ich aber schon mehrmals gemacht - auch - um vielleicht eine Änderung zu triggern - indem ich mehrfach zwischen verschiedene Zeitzonen hin und her geswitcht hatte.


    Wie gesagt: Der Controller hat ja auch die richtige Zeit.


    Lediglich die Einträge in der Logdatei haben das falsche Datum und die falsche Zeit.


    Wo könnte denn diese Uhrzeit herkommen?

    Wo genau wird denn diese Log-Datei erzeugt?


    Da ich den Key gebraucht gekauft habe:

    Könnte es sein, dass trotz eines Firmware- und CloudKey Updates mein Vorgänger einen SNMP-Server auf dem Key installiert hat, der beide Updates "überlebt" hat (und jetzt keine Uhrzeit mehr bekommt?)

    Eigentlich würde ich ja denken, dass ein Firmware-update alles platt macht (?)


    Sorry für die vielen Fragen.. aber vielleicht triggert ja die eine oder andere Frage bei einem von Euch eine Idee :smiling_face:

    Das ist nicht möglich, weil wir eine IP-Telefonanlage haben. Die möchte ich auf keinen Fall hinter irgendwelche Firewalls hängen... Auch bleibt ja unser bisherige Firewall bestehen, die unser "richtiges" LAN mit dem Internet verbindet..


    Das Unifi System läuft praktisch parallel zu unserer normalen Firewall, exklusiv für WLAN.


    Deshalb also brauche ich den Zugang per VPN...

    Neuere Cloudkey Versionen haben die 443, 8443 wurde abgelöst

    Interessant!


    Allerdings logge ich mich per Laptop, den ich am LAN des Gateways angeschlossen habe, bisher immer mit der 8443 ein, bzw. werde dorthin weitergeleitet, wenn ich nur die IP-Adresse angebe (so jedenfalls meine mittelschwache Erinnerung). Also bezieht sich das vielleicht nur auf die neueren Cloudkey Generationen? Wie gesagt: Die neueste Version habe ich vorgestern aufgespielt, sowohl die Firmware als auch den Controller...

    Vielen Dank!


    Ich meine, dass ich die Portweiterleitugn so eingerichtet habe. Zuerst hatte ich auch von "any", dann hatte ich strikter auf from 192.168.180/24 gesetzt - aber es ging nicht.. :frowning_face:


    Ich werde es aber noch einmal genau prüfen, und dann alternativ auch statt mit VPN mit Laptop an der Fritzbox testen...


    Brauche ich vielleicht noch weitere Ports, die möglicherweise irgendwelche Java-Skripte im Webbrowser öffnen wollen?


    P.S.: Mangels Fernzugriff kann ich leider nur sporadisch über die konkreten Ergebnisse berichten - da ich ja vor Ort sein muss für die Tests... Konkrete Ergebnisse dauern also leider immer etwas...

    Hmm, ich denke gar nicht.


    Ich habe verschiedene Sites ohne USG hinter Routern, die erreiche ganz normal über das Unifi Portal - Sind Kamera Netze wo nur der Cloudkey Gen 2 läuft. Da funktioniert das.

    Aber du hast ja jetzt 2 Firewalls :smiling_face: Doppeltes Nat eben. Das geht nicht. Soweit ich das kenne.

    Doppeltes NAT sehe ich eigentlich nicht: Denn das Fritzbox-NAT wird ja vom VPN-Tunnel durchbrochen und ich habe danach ja originäre Pakete von der 192.168.180.101, die über den WAN-Port des Gateways 192.168.180.30 zur 192.168.2.6 gelangen wollen/sollen.


    In meinen Augen ist dies das selbe, als ob ich einen Laptop an die Fritzbox hänge, der dann z.B. die 192.168.180.102 bekommt, und auf den Cloud Key zugreifen will. Und an dem ich vorher natürlich noch die Routing-Regel zum Netz des Cloudkeys gesetzt habe. - Nachtrag - Eigentlich müsste es über die Routing Regel in der Fritzbox ja auch OHNE eigene Routing-Regel im Laptop funktionieren, wenn die Fritzbox dort das Default Gateway ist..


    Aber das ist eine gute Idee - ich werde mal probieren, ob es mit dem Laptop von der Fritzbox-Seite her klappt. Aber ich fürchte, dass das auch nicht funktionieren wird.. Mal schauen...

    So, und nun noch meine andere Frage.


    Vermutlich fast schon das Peinliche berührend, aber ich komme zurzeit einfach nicht weiter. Letztlich wohl einfach eine simple Firewall/Routing Frage..


    Also:

    Es geht um einen Zugang auf den Controller, der in einem Cloudkey läuft, der im Endeffekt mit dem (Unifi)-"LAN" des Gateways verbunden ist.


    Der Zugang soll von extern erfolgen, über ein VPN, das in der vorgeschalteten Fritzbox endet.

    Die ausgehenden Ex-VPN-Pakete der Fritzbox haben die IP-Adresse 192.168.180.101

    (Die Fritzbox selbst hat die IP-Adresse 192.168.180.1)


    Die IP-Adresse des WAN-Ports des Gateways ist die 192.168.180.30


    Der Controller / CloudKey, die über den Switch am LAN des Gateways angeschlossen sind, haben die IP-Adresse 182.168.2.6



    Wie steuere ich den Zugriff vom in der Fritzbox endenden VPN auf den Cloudkey?


    Die anfängliche Verwirrung mit den getrennten IN und OUT Regeln habe ich nun so verstanden:

    IN: So, wie ich es bisher von den Firewalls gewöhnt bin

    OUT: Ohne Einträge ist alles erlaubt. Überwiegend setzt man hier die Einträge, um zu sperren.

    Ich hoffe, das stimmt so.. (?)


    Nun habe ich folgendes gemacht:

    a) Fritzbox: Route gesetzt 192.168.2.0/24 auf 192.168.180.30


    b) Gateway WAN IN

    Pakete von 192.168.180.0/24 nach 192.168.2.0/24 erlaubt


    Funktionierte nicht.


    Also setzte ich noch eine behelfsweise noch Portweiterleitung, für den Fall, dass das Gateway die eigenen Netze nicht kennt (?):

    Also, Port 8443 auf WAN weiterleiten nach 192.168.2.6 auf LAN


    Funktioniert immer noch nicht..


    Ich habe auch noch anderes probiert, aber das wäre eher peinlich, wenn ich es hier aufzähle :smiling_face:


    In umgekehrter Richtung scheint mir der Verkehr ja zu funktionieren, denn vom "LAN" des Gateways kommt ein Laptop auf allen Ports überall hin ins Internet, somit auch auf die Fritzbox und somit auch in den dort geöffneten VPN-Tunnel.


    Tja, wer hat hier einen Rat? Ist ja vermutlich total simpel...


    Danke...

    Hi,


    in meinem ganz frisch aufgesetzten Unifi-System bestehend aus dem GatewayP4, 16-Port PoE Switch und CloudKey Gen1, alle mit tagesaktuellen Softwareupdates (vorgestern) habe ich folgendes Problem:


    Die Logdatei unter "Ereignisse" im Controller zeigt als Datum immer den 11. August 2018 an, mit falscher Uhrzeit. Und von dort beginnend läuft das Ganze dann natürlich korrekt weiter hoch.


    Eigenartigerweise scheint aber der Controller die richtige Uhrzeit zu haben, denn wenn ich in dieser Ereignis-Anzeige rechts oben auf die Symbole klicke, wird mir durchaus das aktuelle Datum angezeigt - nur eben leer, weil die Logdateieinträge ja in 2018 liegen...


    Ich habe gesucht und gesucht, wo ich denn in den Geräten noch ein Datum (oder einen NTP-Server) eintragen könnte - nichts gefunden. Alle Geräte schon mehrfach in den Werkszustand zurückgesetzt und neu provisioniert - null Erfolg.


    Hat jemand eine Idee, wo ich hier ansetzen könnte? Als Zeitserver waren irgendwo (ich glaube im Controller?) vier ubiquiti-Server eingetragen. Da habe ich dann auch mal den ersten durch ptbtime1.ptb.de ersetzt, aber auch das: null Erfolg.


    Ich weiß ehrlich gesagt noch nicht einmal, in welchem der Geräte die falsche Uhrzeit gesetzt ist (Switch und APs würde ich natürlich mal ausschließen..:)


    Über jede Hilfe oder Idee dankbar...


    Ciao

    Hi,


    ich hoffe, dass ich hier nun tatsächlich in der Vorstellungsrunde gelandet bin, die mir nach der Anmeldung hier am Forum angezeigt wurde- und möchte mich entsprechend vorstellen. Ansonsten gerne diesen Beitrag löschen oder verschieben..


    Also, ich stand vor der Aufgabe, in einem mittelgroßen Büro (ca. 40 Leute) über 2 Etagen "alles ganz toll mit WLAN" auszustatten. Bisher hatte ich nur nach Bedarf hier und dort ein paar billige Router als APs hingestellt, die hinter unserer PFSense Firewall in der DMZ angeschlossen waren.


    Nach gar nicht so langem Suchen - zuerst zog ich auch Fritz Mesh in Erwägung - stieß ich dann aber auf das Unifi System, zudem ich schon privat mal einen Edge-Router X kannte (den ich aber zusammen mit meinen Fritzboxen nicht wirklich sinnvoll nutzen konnte).


    Und nun haben wir die Bescherung:


    (Erst einmal) 5 Unifi APs lite

    plus einmal das geringfügig größere Modell,

    2 schwarze, nicht unifi-kompatible Einzelboxen von Ubiquiti, wie ich erst später kapierte (aber mit PoE)

    Das Gateway 4P

    Den 16-Port PoE Switch

    (alles neu)


    und gebraucht, weil vor Mai nicht lieferbar, einen CloudKey Gen1


    Wie vermutlich die meisten hatte ich so einiges an Herausforderungen zu bewältigen, aber irgendwie klappte das meiste dann doch irgendwie. Schwierig war für mich, das Zusammenspiel der verschiedenen Anmeldungen zu durchblicken. Weitere Hürden sind, dass das "LAN" des Unifi Systems NICHT mit unserem LAN gekoppelt wird, also eine andere Adresse als die 192.168.1.x bekommen musste.. irgendwie fehlte mir zu Beginn eine Erklärung des Gesamt-Konzepts - und das Forum kannte ich leider noch nicht :smiling_face:


    Die Grundhürden sind genommen - aber nicht alle... und deswegen habe ich mit Freude die Existenz dieses Forums gesehen und mich gleich angemeldet :smiling_face: