Beiträge von Maddeen

Wie Razor schon gesagt hat, einfach das Gäste-Netzwerk editieren, runterscrollen bis zum Gateway und dann als ersten DNS den Pi-Hole hinterlegen.

Sieht dann so aus

So - ich habe meine LAN LOCAL Regeln noch erweitert. Daher habe ich die eine von dem vorherigen Post, hierhin verschoben.

Vorwort:

Für diese Regeln habe ich mir auch eine weitere Firewall-Gruppe angelegt.

Diese habe ich "Admin_Devices" genannt und enthält alle Geräte, die in Zukunft Zugriff auf die UDM erhalten sollen.

LAN LOCAL-Regeln

1. Regel = "Allow Admin Mgmt"

Hinweis: Mit dieser Regel wird sichergestellt, dass ich mit meinen Admingeräten (definiert durch die o.a. Firewall-Gruppe) weiterhin auf die UDM komme - und zwar aus jedem VLAN, da ja die andere Firewall-Gruppe (Local_Gateways) alle VLAN-IPs der Gateways enthält.

2. Regel = "Block IoT to Gateways"

Hinweis: Mit dieser Regel wird unterbunden, dass sich ein Client aus dem IoT_LAN auf eines der Gateways verbindet.

Ich habe die FW-Gruppe nur der Einfachheit gewählt - ich hätte auch überall die jeweilige IP des Gateways hinterlegen können.

Diese Regel werde ich für alle anderen VLANs auch setzen. Aber Achtung beim Nachmachen. Bitte immer erst die Regel #1 umsetzen, um weiterhin Zugriff zu haben!

3. Regel = "Block Home to Gateways"

Hinweis: Diese Regel ist fast identisch zu Regel #2 - bezieht sich jetzt aber auf das VLAN = HOME_LAN.

Auch hier gilt: Achtung beim Nachmachen. Bitte immer erst die Regel #1 umsetzen, um weiterhin Zugriff zu haben!

4. Regel = Block IoT to MGMT

Hinweis: Diese Regel verhindert den Zugriff von Clients aus dem IoT_LAN auf die restlichen Clients aus dem MGMT_LAN (Zugriff auf die Gateways wurde ja schon mit Regel #2 und #3 verboten)

Auch hier gilt: Achtung beim Nachmachen. Bitte immer erst die Regel #1 umsetzen, um weiterhin Zugriff zu haben!

5. Regel = Block HOME to MGMT

Hinweis: Diese Regel ist fast identisch zu Regel #4 - bezieht sich jetzt aber auf die Clients im HOME_LAN.

Auch hier gilt: Achtung beim Nachmachen. Bitte immer erst die Regel #1 umsetzen, um weiterhin Zugriff zu haben!

So... nach einer schönen nächtlichen Runde zwischen meiner UDM Pro und mir - mit kalter Pizza - kamen wir zu folgende Erkenntnisse bzw. Umsetzungen.

1) FW-Gruppe "RFC1918" erstellt. Diese beinhaltet die Netze 192.168.0.0/16; 172.16.0.0/12 und 10.0.0.0/8 und deckt somit alle meine VLANs ab.

2) FW-Gruppe "Local_Gateways" erstellt. Diese beinhaltet jedes Gateway aus jedem VLAN - in meinem Fall also 10.1.0.254 / 10.10.0.254 / 10.20.0.254 und 10.30.0.254.

3) FW-Gruppe "IoT_Server_Devices" erstellt. Diese beinhaltet jedes Device aus dem IoT_LAN, welches Zugriff auf meinen Server (der PLEX hosted) benötigt. z.b. 10.30.0.1 (PS4) oder 10.30.0.2 (ATV4k)

Jetzt habe ich unter LAN IN folgende Regeln erstellt. Wichtig - das sollte man auch in dieser Reihenfolge machen, da man sich sonst ggf. selber ausschließt

• Grüne Parameter = Source/Quelle
• Blaue Parameter = Destination/Ziel
• Gelb = Hinweistexte oder nicht verifizierte Informationen

LAN LOCAL-Regeln

1. Regel = "Allow_Established_Related"

Hinweis: Das ist wohl eine Standardregel, die man immer für jedes VLAN hinterlegen sollte, da sie (sofern ich das richtig verstanden habe) bereits bestehende Verbindungen weiterhin erlaubt.

Das soll wohl viel Arbeit sparen. Allerdings habe ich auch gelesen, dass man diese Regel nicht setzen soll, wenn man eine bereits bestehende Kompromittierung im Netz vermutet - was logisch klingt - weil ja sonst die nicht gewünschten Verbindungen weiterhin bestehen bleiben würden. Sollte ich die Regel FALSCH ausgelegt haben, bitte korrigieren.

2. Regel = "Allow_PiHole_DNS"

Hinweis: Diese Regel ist dafür da, dass die Geräte aus allen VLANs auch an meinen Pi-Hole für die DNS Auflösung kommen. Der Pi-Hole ist bei mir bei allen VLANs als DNS fest an Nummer 1 gesetzt!

Als Fallback ist DNS = 1.1.1.1 und 1.0.0.1 gesetzt

3. Regel = "Allow_PLEX"

Hinweis: Diese Regel ist dafür da, dass die Geräte aus der Gruppe "IoT_Server_Devices" Zugriff auf den PLEX-Server bekommen. Da der Server nicht nur der Host von PLEX, sondern auch Dateiablage sensibler Daten, diverser VMs und Docker ist, habe ich mich für diese Gruppenregel entschieden. Man könnte auch einfach das ganze VLAN "IoT_LAN" Zugriff auf den Server geben. Das war mir zur kritisch.

In meiner Konstellation reicht es somit für den "Eindringling" nicht aus, nur im richtigen VLAN zu sein - er müsste auch in die FW-Gruppe administriert werden. Was nur geht, wenn man auf die UDM kommt.

Das habe ich aber - Regel kommt weiter unten - in Verbindung mit der FW-Gruppe "Local_Gateways" verboten

4. Regel = "Allow_WoL"

Hinweis: Diese Regel ist dafür da, dass die Geräte aus der Gruppe "IoT_Server_Devices" das MagicPacket für Wake on LAN an den Server senden können.

Hinweis 2: Hierfür habe ich bisher keine Lösung gefunden

Sowohl ICMP Freigabe als auch TCP/UDP 7-9 haben nicht zum Erfolg geführt

5. Regel = "Block IoT to LAN"

Hinweis: Mit dieser Regel wird alles, was nicht durch die Regeln 1-4 erlaubt wird, komplett geblockt. Das VLAN "IoT_LAN" ist somit (ausgehend) isoliert von meinen anderen VLANs.

Diese Regel kann natürlich jetzt beliebig dupliziert werden, um auch andere Inter-VLAN-Kommunikation zu verbieten.

Für z.B. ein Verbot vom HOME_LAN einfach bei SOURCE das Network HOME_LAN hinterlegen - und schon kann man aus dem HOME_LAN auch keine Inter-VLAN-Kommunikation mehr aufbauen.

Das dürfte dann eigentlich ja auch das sein, was ich will

Nämlich von meinem AppleTV (VLAN-30 @ IOT_LAN) auf meinen unRAID-Server (Plex) der im VLAN-20 | HOME_LAN steht.

Ich werde heute Abend wieder was rumspielen - kann das nur machen, wenn die Frau das Netz nicht braucht - die hat nämlich nicht so viel Verständnis wenn immer wieder das Netz weg ist...

Sehr gut - danke. Werde ich nachher oben man ergänzen. Früher oder später wird jemand genau das benötigen.

Die FW ist in der Tat alles andere als einfach - jedenfalls für Otto Normal. Das ist selbstselbst ne Windows-FW simple gegen....

Bin mal auf weiteres Feedback gespannt. Aktuell kann ich nicht weiter machen, weil Stromausfall 🙈😂

Hi zusammen,
ich habe seit ein paar Tagen auch die UDM Pro und habe jetzt mal bei dieser Gelegenheit (CK2+ und USG mussten raus) mein komplettes Netzwerk überarbeitet.

Konkret bedeutet das, dass ich insgesamt 5 Netze erstellt haben - bitte nicht in Frage stellen wieso, weshalb, warum - ich mag einfach Ordnung

Hier mal kurz angerissen

• VLAN-ID = 1 = MGMT-LAN - das ist das default LAN, wo man auch keine VLAN-ID vergeben kann, weil es immer = 1 ist. Hier befinden sich der Vigor 165 (über den Port 2 des Vigors), meine UDM Pro, mein USW-16-POE-Gen2 und mein UAP-IW-HD.
• VLAN-ID = 10 = CAM_LAN - das ist das VLAN für meine Kameras (G3-Flex usw)
• VLAN-ID = 20 = HOME_LAN - das ist das VLAN für alle Geräte, die nicht in die anderen Kategorien passen - also sozusagen das "default" für meine Macs, iPads, iPhones, Drucker, Server usw.
• VLAN-ID = 30 = IOT_LAN - das ist das VLAN für alle IoT-Geräte wie z.B. Apple TVs, Apple HomePod, SmartTVs, SkyQ, AV-Receiver, Konsolen, Homey und alles andere "SmartHome-Zeugs" (also Steckdosen, Lichtschalter usw)
• VLAN-ID = 40 = VPN_LAN - das ist das VLAN, wo man landet, wenn man sich via VPN in mein heimisches Netz ein wählt
• VLAN-ID = 50 = GUEST_LAN - das ist das VLAN, wo meine Gäste drin landen - inkl. Guest-Landingpage usw.

Jetzt geht's mir darum, entsprechende Netzhärtungen vorzunehmen.

Mein zweites Ziel wäre - wie auch bei der WoL-Thematik - dass ich am Ende ausreichend Detailinfos zusammen habe, dass ich wieder eine Tutorial schreiben kann.

Dann wäre das Firewallthema nämlich einmal transparent für alle beschrieben. Leider hat mein Lieblings-UniFi-Mensch (Crosstalk Solutuions@Youtube) nämlich sein Video zum Thema Firewall mit einem EdgeRouter gemacht.

Da passt dann leider gar nichts - ich glaube selbst die Funktionsbeschreibung ist abweichend (zwischen EdgeOS und UnifiOS).

Aber genug geredet - jetzt erst mal zu dem, was ich bisher verstanden habe. Hier wäre es gut, wenn das mal einer verifizieren kann - nicht das ich schon Blödsinn gelernt/abgespeichert habe

Das doofe ist nämlich, dass es die Regeln natürlich nur in englisch definiert sind und es sich 1:1 übersetzt manchmal dämlich anhört.

Ich konzentriere mich hier auch ausschließlich auf IPv4, da man (aus meiner Sicht) im privaten LAN eh kein IPv6 braucht und es ja auch im WAN noch lange kein Standard ist.

Es gibt insgesamt 9 Bereiche für Firewallregeln, die ich wie folgt verstanden habe Wie man sieht - schon einige Lücken

Bezeichnung	Funktion / Beschreibung	Nutzbar für ...
WAN IN	Bezeichnet den Traffic, der IN das WAN Netzwerk kommt und IN andere Netzwerke will.	z.B. Port-Forwarding - also Traffic, der vorne am Gateway ankommt und an ein Ziel (Client) geleitet werden soll
WAN OUT	Bezeichnet den Traffic, der AUS dem WAN Netzwerk kommt und IN andere Netzwerke will	??? Gibt es hier einen Usecase?? Aus meiner Sicht macht hier doch nur sowas Sinn wie "ich will nicht, dass jemand aus meinem Netz einen FTP Server bedient." Ergo "drop" ich alles was über Port TCP 21 von der Quelle "xyz" zum Ziel "alles" geht. 1. UseCase von kaetho - siehe HIER
WAN LOCAL	Bezeichnet den Traffic, der über den WAN Port auf die UDM/USG (Local) will.	Grundsätzlich ist hier "Drop" gesetzt, damit niemand aus dem Internet, auf die UDM/USG zugreifen kann. Dieser Bereich wird automatisch um Regeln erweitert, sobald ihr den VPN-Server aktiviert, da es ja dann notwendig ist, dass L2TP Traffic für den Verbindungsaufbau zum UDM/USG kommt.
LAN IN	Bezeichnet den Traffic, der IN das LAN Netzwerk kommt und IN andere Netze will	Hier habe ich z.B. die Regel zum Härtung von IoT-Spam. Sprich "DROP" jeglichen Traffic vom Netz "IOT_LAN" in das Netz "HOME_LAN"
LAN OUT	Bezeichnet den Traffic, der innerhalb des LAN-Netzwerk möglich ist Diese Annahme ist nicht verifiziert, da die englische Beschreibung "komisch" ist Zitat: Applies to IPv4 traffic that exists the LAN (egress), destined for this network (default accept).	Hier bin ich mir auch nicht sicher, ob es einen Usecase dafür gibt. Hängt aber auch mit dem Nichtverständnis der englischen Beschreibung zusammen. Wenn ich die englischen Beiträge richtig verstanden habe, ist diese Regel eigentlich auch obsolet, weil man mit LAN IN exakt das gleiche bewirken kann.
LAN LOCAL	Bezeichnet den Traffic der über das LAN Interface auf die UDM/USG (Local) will.	Auch hier habe ich z.B. die Regel zur Härtung von IoT-Spam- Sprich "DROP" jeglichen Traffic vom Netz "IOT_LAN" in das Netz "HOME_LAN"
GUEST IN	Bezeichnet den Traffic, der in das GUEST-Netzwerk kommt und IN andere Netze will.	Hier findet sich z.B. die Einstellung beim Gästeportal "Post-Authorization Restrictions" wieder Sprich "DROP" jedes Paket was in die verbotenen Netze will. (192.168/172.16/10.0) Aus meiner Sicht gibt es hier auch nichts mehr (sinnvolles!) einzuschränken oder zu erlauben. Wenn doch - gerne Beispiele schreiben
GUEST OUT	Bezeichnet den Traffic, der innerhalb des GUEST-Netzwerk möglich ist Diese Annahme ist nicht verifiziert, da die englische Beschreibung "komisch" ist Zitat: Applies to IPv4 traffic that exists the guest network (egress), destined for this network (default accept).	Hier gibt es eine Regel, die aber leider default ist, und somit für mich nicht klar ist, was hier überhaupt möglich ist bzw. was der Sinn hier ist. Vielleicht kann hier einer aufklären.
GUEST LOCAL	Regelt den Traffic aus dem GUEST-Netzwerk auf die UDM/USG (Local)	Da das Netzwerk im Sinne seiner Funktion extrem eingeschränkt ist, sind hier einige Regeln automatisch hinterlegt wie z.B. Zugriff auf DNS, ICMP, DHCP oder auf das Gästeportal. Aus meiner Sicht gibt es hier auch nichts mehr (sinnvolles!) einzuschränken oder zu erlauben. Wenn doch - gerne Beispiele schreiben

Bisher habe ich aus den englischen Videos/Tutorials nur zwei Regeln übernommen, die augenscheinlich auch funktionieren

Bereich	Aktion	Protokoll	Quelle	Ziel	Hinweis/Sinn
LAN IN	DROP	ALL	IOT_LAN | IPv4 Subnet	HOME_LAN | IPv4 Subnet	Alles im IOT_LAN kann keine Kommunikation ins HOME_LAN herstellen
LAN IN	DROP	ALL	IOT_LAN | IPv4 Subnet	MGMT_LAN | IPv4 Subnet	Alles im IOT_LAN kann keine Kommunikation ins MGMT_LAN herstellen
LAN LOCAL	DROP	ALL	IOT_LAN | IPv4 Subnet	MGMT_LAN | IPv4 Subnet	Alle im IOT_LAN kann keine Kommunikation ins MGMT_LAN Hinweis: Das ist z.b. etwas, was ich nicht verstehe. Warum müssen Regeln aus den Bereichen "WAN/LAN/GUEST LOCAL" überhaupt ein Ziel haben. Ich habe das so verstanden, dass hier das Ziel eh immer die UDM/USG ist...

Jetzt aber zu dem Zielstatus, den ich gerne hätte und trotz der o.a. Erkenntnisse einfach nicht gebacken bekomme

Generell will ich das ganze Inter-VLAN-Routing komplett verbieten und nur bestimmte Konstellationen erlauben.

Problem gelöst - siehe unten Regel "Block_IoT_to_LAN" (Beispielhaft für das IoT_VLAN)

Die Regel muss dann einfach nur dupliziert werden und die Quelle angepasst werden.

1) Ich will von einem definierten Client (feste IP) aus dem HOME_LAN auf ein Ziel (feste IP) im MGMT_LAN.

Selbst wenn ich das ganz grob nur mit "LAN IN" und ERLAUBE ALLES von Quelle "HOME_LAN" zu Ziel "MGMT_LAN" setze (Regel nach ganz oben!), funktioniert das nicht

Problem gelöst - siehe unten Regel "Allow Admin Mgmt"

2) Ich will, dass definierte Clients (feste IP) aus dem IOT_LAN auf ein Ziel (feste IP) im HOME_LAN zugreifen können.

z.B. AppleTVs und PS4 zum Server (Plex installiert)

Problem gelöst - siehe unten Regel "Allow_PLEX"

3) Der Homey soll seinen WOL Befehl an den Server senden können

Vermutlich gar nicht lösbar, da man WOL nicht von einem VLAN in ein anderes VLAN schicken kann

4) Ich will, dass definierte Clients (feste IP) aus dem HOME_LAN auf definierte Ziele (feste IP) im IOT_LAN zugreifen können

z.B. Mac, iPhones, iPads auf die AppleTVs

Problem gelöst - siehe unten Regel "Allow_Established_Related"

Und je nach Antworten kommen da sicherlich noch einige Fragen dazu -- was mir z.B. aktuell direkt einfällt, wo ist eigentlich der Unterschied bei Quelle/Ziel zwischen IPv4 Subnet und Gateway IP Adresse.

In meiner Welt, ist die Gateway IP Adresse doch sowieso geblockt, wenn ich IPv4 Subnet auswähle - oder?

Schon mal vielen Dank an alle, die sich an der Diskussion beteiligen - am Ende werde ich, wie oben beschrieben, mal ein Tutorial für alle machen, was man sinnvoll umsetzen sollte (IOT-Isolation) und was noch (und wie) geht

Schönen Abend zusammen,

unRAID ist wie z.B. FreeNas ein OS für den NAS-Betrieb. Nichts spezielles. Aber die Webgui ist, wie so oft bei solchen sachen eben per default nur http und nicht https.

Für https muss man unRaid "einfach" ein Zertifikat über letsencrypt generieren. Das bietet die Webgui auch komfortabel an.

Aber die Durchführung klappt nicht, weil das USG per default kein Rebinding erlaubt. (siehe "OOPS" Screenshot )

Im anderen Screenshot (blauer Hintergrund) sieht man dann die ganzen Hinweise, für die wichtigsten Geräte, wie man das rebinding für die Domain "unraid.net" aktiviert.

UPDATE: Irgendwie hat die Provisionierung innerhalb unRAID jetzt doch geklappt - https läuft Ich habe aber nichts am USG verändert. Sehr mysteriös

Schönes WE

Hi zusammen,

ich hätte da mal ein Problem

Ich habe seit ein paar Tagen einen unRAID-Server live. Geile Sache - aber das ist ein anderes Thema.

Jetzt will ich die Verbindung auf die WebGui von unraid auf SSL umstellen.

• Problem: Zertifikatserstellung schlägt bei der Provisionierung fehl
• Grund: DNS Rebinding mag das USG natürlich gar nicht.

Die Lösung bzw. das command die unRAID explizit für das USG angibt lautet:

Zitat

set service dns forwarding options rebind-domain-ok=/unraid.net/

Gut - etwas mehr hätte es dann für mich schon sein können, aber naja. Ich bin mir jedenfalls FAST sicher, dass diese Info in die Datei "config.gateway.json" muss - korrekt?

Da würde sie jedenfalls Sinn machen.

Allerdings kann ich mich aus dem WOL Thema noch dran erinnern, dass man in die JSON natürlich nicht einfach den o.a. command setzen kann.

Via Google habe ich das hier gefunden

{
  "service": {
    "dns": {
      "forwarding": {
        "options": [
          "rebind-domain-ok=/unraid.net/"
        ]

Auch das für sich ist verständlich - aber wie o.a. habe ich die config.gateway.json Datei ja schon mal (vor mehreren Monaten) geändert.

Sofern sich seit der Zeit nichts von alleine geändert hat, müsste die Datei auf meiner USG bereits so aussehen, damit das WOL funktioniert.

{
   "protocols":{
      "static":{
         "arp":{
            "192.168.1.2":{
               "hwaddr":"ff:ff:ff:ff:ff:ff"
            }
         }
      }
   }
}

Hier wäre ggf. schon mal eine Info interessant, wie ich mir die aktuelle auf dem USG befindliche config.gateway.json "runterladen" kann - damit ich diese bearbeiten kann.

"Eigentlich" wäre also danach nur noch ein "Zusammenführen" beider Parameter zu erledigen - aber das führt bei mir zum stack-overflow

Kann mir jemand dieses (vermutlich simple) Zusammenführen abnehmen?

Ich bin da relativ vorsichtig, weil eine inkonsistente, zum USG hochgeladene config.gateway.json, vermutlich zum kompletten Crash des USG führt

Im Vorfeld schon mal vielen Dank.

Da unRAID auch hier immer populärer wird - und Rebind ggf. auch ein wiederkehrendes Thema ist/wird, sollte die Umsetzung aus meiner Sicht danach auch in die FAQ

ja ich nutze die mit meiner DynDns-Adresse - wobei ich mir noch meine eigene Domain vorgeschaltet habe.

Sprich

vpn.meinedomain.de leitet weiter auf 30334mniodf34834.kostenfreierdyndns-anbieter.de und dahinter steht dann meine public IP.

Habe dann ein SSL Zertifikat entsprechend erstellt, sodass ich bei der Weiterleitung keinen Zertifikatserror bekomme (solche Weiterleitungen per http mag das iPhone nämlich nicht, weil unsicher )

Das ist aber nur kosmetisch und macht es einfacher, den FQDN zu merken ...

Zitat

Der Weg ist zwar nicht so elegant wie direkt im VPN, aber zur Not....

Und genau das hatte ich mir auch irgendwann gesagt. Es hat einfach keine weitere Recherche mehr gerechtfertig - denn Internet hab ich überall. Daheim ist es natürlich vom Weg her total Banane, weil er ja quasi aus meinem Wlan/LAN raus geht, auf die Internetdomain, die dann wieder in mein Netzwerk kommt und den WOL startet.. aber hey - es funktioniert immer und ich muss mich nicht immer erst ins VPN einwählen, um einen simplen WOL Befehl abzusetzen

Bzgl. des Screenshots -- dann wundert mich aber etwas, weil du sagst, dass bei dir

192.168.20.230 0x1 0x6 00:22:4d:a7:c2:a3 * eth1.20 (bei mir ist es die 192.168.20.230 im VLAN20). steht.

Aber ich meine das funktioniert nur, wenn die Mac = ff:ff:ff:ff:ff:ff ist, da die ja sozusagen als "Verteiler" dient.

P.S Und generell würde ich dem ssh-output immer mehr Wert geben, als der GUI. ggf. ist es ein Bug oder ähnliches.

Sowas gibt es in der shell nicht - wenn die shell dir die korrekten Werte ausgibt, sind die auch "vorhanden"

Hi,

ich kann dir leider nicht mehr konkret helfen, aber wenn ich mich recht entsinne, konnte ich das Problem nur via WOL per Internet lösen.

Daher nutze ich mittlerweile "iNet WOL" aus dem App-Store. Hersteller ist Banana Glue und wecke meinen Server immer direkt über das Internet (also über die dynamische öffentliche IP) auch wenn ich im LAN bin

Du kannst es ja mal ohne DynDns versuchen, in dem du deine öffentliche IP rausfindest und die in dem Tool eingibst.

EDIT - hier meine Einstellungen in der App:

P.S trotzdem wundert es mich, dass dir hier in der WebGui nichts anzeigt -- das meinst du doch oder?

Ich habe ja schon einen Artikel geschrieben - ich gucke mal, vor was ich alles für Fragen stehe und baue daraus dann Infos.

Bin ja auch erst seit ca. 1 Monat im Unifi-Universum - vorgestern meine neue G3-Flex in Betrieb genommen

Aber das organisatorische drum herum müsstest du vermutlich machen... ich habe zu dem Büro nämlich noch nen 4-jährigen der die restliche Zeit frisst

Unbedingt die Gen2.

Die erste Generation zeichnet sich (nach meinen Recherchen) durch diverse Probleme und - ganz oft - einer Zerstörung der internen Datenbank aus.

Zudem würde ich direkt den Gen2-PLUS empfehlen, damit du für die Zukunft auch Unifi Protect nutzen kannst.

Außer du kannst natürlich jetzt schon ausschließen, dass du das niemals haben möchtest - dann tut es auch der normale Gen2

Ich habe selber vor 2-3 Wochen komplett von 7590+2x1750e auf Unifi (USG+CK2+IWHD+USW) gewechselt.

Ich würde daher auch empfehlen, alle anderen "fremden" Netzkomponenten zu entfernen.

Das doppelte NAT wird dir früher oder später die Haare rauben - erhöht nur die Komplexität bei null Benefit.

Die Kombination Vigor 165 + USG ist deutlich professioneller und bietet viel mehr Möglichkeiten.

Zudem geht einem, aus meiner Sicht, der große Unifi-Vorteil flöten - nämlich eine Oberfläche um alle Konfigurationen vorzunehmen und auch alles immer auf einen Blick im Auge zu haben.

Die Fritzbox ist da aus meiner Sicht eher das fünfte Rad am Wagen.

Hi zusammen,

bin seit ein paar Wochen dabei, mein UBNT Netzwerk aufzubauen.

Begonnen mit USG und einem CloudKey2+, kam vor ca. 1 Woche auch endlich der 16-Port Switch (Gen.2) und ein Inwall HD AP dazu.

Jetzt, wo ich soweit alles am laufen habe, gab es aber doch eine kleine Herausforderung.

Ich habe daheim einen PLEX-Server - allerdings auf einem echten PC - und somit läuft der natürlich nicht 24/7 bzw. 12/12

Langer Rede kurzer Sinn - WoL ist im Unifi-Universum leider nicht so einfach, wie man bzw. ich es von der Fritzbox kannte.

Denn bei der Fritzbox konnte man alle Clients über die GUI wecken oder - da eine Verbindung ins VPN nicht als separates Netzwerk realisiert wurde - einfach dort das MagicPaket absetzen.

Und da bestimmt der ein oder andere hier vor der gleichen Herausforderung steht, hab ich mal ein kleines HowTo verfasst

Hier mal die Schritte zum Erfolg

1. Testen, ob WoL im LAN funktioniert --> CHECK!
   1. Das ist die Grundbedingung, damit man sicher sein kann, dass generell das WoL funktioniert.
   2. Als Tool für iOS empfehle ich hier "MOCHA WOL" - kostenfrei und funktioniert tadellos
2. JSON-Datei runterladen
   1. config.gateway.json
3. JSON-Datei mit einem beliebigen Editor öffnen und die IP abändern.
   1. WICHTIG: Ihr müsst eine IP nehmen, die außerhalb eurer DHCP Range ist und die NIEMALS ein anderer Client bekommt.
      1. Ich habe mich für die 192.168.1.2 entschieden, da meine DHCP Range erst bei 192.168.1.100 beginnt.
4. JSON Datei via JSON-Formatter zur Sicherheit validieren
5. JSON Datei via SSH auf den CloudKey (Verzeichnis = /usr/lib/unifi/data/sites/default) hochladen.
   1. cd Desktop/
   2. scp config.gateway.json <user>@<ipaddr>:/usr/lib/unifi/data/sites/default
6. USG neu provisionieren
7. USG rebooten
   1. Dient nur zur Sicherheit - Bei Einigen hat ein reines provisionieren nicht geholfen.
8. Jetzt muss kontrolliert werden, ob der Inhalt der JSON auch korrekt geladen wurde. Dazu gibt es zwei Wege
   1. via SSH auf dem USG einloggen und das Command cat /proc/net/arp eingeben und prüfen, ob dort der Eintrag aus der JSON angezeigt wird.
   2. via GUI auf dem USG einloggen und auf der Startseite unter "DHCP LEASES AND ARP" prüfen, ob dort der Eintrag aus der JSON angezeigt wird.
      In meinem Fall also --> 192.168.1.2 ----- ff:ff:ff:ff:ff:ff
9. Wenn das geschafft ist, seid ihr schon fast am Ziel
10. Jetzt nur noch folgende Port Forwarding Regel hinzufügen
    1. From: ANYWHERE
    2. Port: 9
    3. Forward IP: Die Fake-IP-Adresse aus der JSON (in meinem Fall also 192.168.1.2)
    4. Forward Port: 9
    5. Protocol: UDP
11. Am besten jetzt einen weitere Test machen. Dazu einfach auf Wake on LAN - online gehen und
    1. MAC = die MAC eures Clients, den ihr wecken wollt!
    2. IP = eure öffentliche IP-Adresse (http://www.wieistmeine.ip) oder über euren DynDNS
    3. Subnet = 255.255.255.255
    4. Port = 9
12. Wenn alles funktioniert, in der unter Punkt 1 (oder jeden anderen App) erwähnten App, einen zweiten Eintrag anlegen, mit den Parametern aus Punkt 11.
13. Am Ende habt ihr zwei Einträge in der App - einen für ein WoL im LAN (was man nur noch im Notfall braucht) und einen für WoL via WAN (was solange euer Netzwerk aus dem Internet erreichbar ist, immer funktioniert - egal ob ihr daheim oder unterwegs seid)

So - hoffe das hilft dem ein oder anderen. Anbei auch noch ein paar Screenshots

Guten Rutsch zusammen.

Screenshots - Prüfung, ob ARP Eintrag korrekt gesetzt wurde. Console / GUI

Screenshot - Port Forwarding

Bezüglich der Anzeige auf einem TV kommt wohl bald ein neues Produkt.

Name: Unifi Protect ViewPort

Ob es die 200€ wert ist, muss jeder für sich entscheiden. Da ich bereits an jedem TV ein AppleTV habe, werde ich darüber wohl den Live-Feed anzeigen. Ist natürlich nicht so komfortabel, aber 200€ find ich schon happig.

Alternativ geht es wohl auch über einen RasPi als StreamViewer der dann via HDMI an den TVs angeschlossen ist - RasPI HowTo

P.S Ich bin auch erst seit 2-3 Wochen ins Unifi-Universum umgestiegen und daher noch keine Cam.

Werde jetzt zeitnah eine G3-Flex für die Haustüre kaufen und mal schauen, wie die sich so macht