Zugriff auf Cloudkey über WAN-Schnittstelle

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

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...

Zitat von tomtim

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 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...

Zitat von tomtim

Ja probiere das ruhig mal... Das https://unifi.ui.com/dashboard kennst du ? Hast du dich Online angemeldet ?

Der Remote Zugang über das Online Portal funktionert bei mir nicht. Hier könnte dann tatsächlich das Doppel-NAT der Auslöser sein (?). Aber eigentlich will ich das auch nicht - auch wenn ich das jetzt natürlich auch als Übergang nutzen würde, wenn es denn ginge..

Zitat von EJHome

Hi!

Im Controller braucht es eine Portweiterleitung.

Die Forward IP ist der CloudKey (ich meine mich so zu erinnern).

Grundsätzlich ist der Aufruf ja:

fqdn:8443

Kommst Du mit Deiner VPN-Verbindung schon hinter die FRITZ!Box, sollte der Aufruf:

IP des CloudKey:8443 sein.

Ich bin mir aber in diesem Fall nicht ganz sicher. Du musst es probieren!

Gruß!

Alles anzeigen

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..

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...

Zitat von BlackSpy

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...

Zitat von BlackSpy

Meine Empfehlung für VPN in deiner Konfiguration.

USG in Fritte als Exposed Host

Im USG NAT per Config.gateway.json abschalten.

VPN Fritte deaktivieren

VPN im Controller einrichten und aktivieren, ggf VPN Ports in Fritte weiterleiten.

DynDNS über Myfritz geht.

Alles anzeigen

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...

Zitat von BlackSpy

Okay nimm die Vorlage von @EJHome

Nimm nur Mal einen anderen Eingangsport

Rule Enable

Port zB 52000

Ziel IP dein Cloudkey

Ziel Port 8443

Dann solltest du in deinem VPN mit WANIpUSG:52000 auf den CK kommen

Alles anzeigen

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....

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..

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...

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?