Beiträge von anderl1969

Hallo zusammen,

ich beschäftige mich aktuell mit den Firewall-Regeln meiner UDM-SE und habe deswegen (ganz vorbildlich) auch den Wiki-Eintrag bzgl. Firewall studiert und für mich adaptiert. Dabei ist mir speziell bei den LAN local Regeln aufgefallen, dass entweder die Regeln unsinnig sind oder ich noch ein grundsätzliches Verständnisproblem habe. Ich habe den Wiki-Eintrag auch direkt kommentiert, aber da der Autor nicht mehr aktiv im Forum zu sein scheint, wird da keine Reaktion mehr kommen.

Zum Thema:

Die im Wiki-Eintrag formulierten LAN-Local Regeln sollen unterbinden, dass von einem Subnet aus die Gateways der anderen Subnets erreichbar sind.

Zitat von UniFi Allgemein | Firewall-Regeln by EJ

Wir haben mit Regel 3 die Kommunikation der Subnetze untereinander eingeschränkt. Geräte können sich über die Subnetz-Grenzen nicht sehen und auch nicht erreichen.

Die Gateways der Subnetze sind jedoch noch aus den anderen Subnetze erreichbar.

Beispiel: Von einem Gerät im LAN IoT (10.10.2.x) ist das Gateway des LAN 1 -Admin-LAN- (10.10.1.1) erreichbar. Somit auch USG oder UDM.

Das wollen wir im nächsten Schritt unterbinden.

Die angebotene Lösung funktioniert zusammengefasst so:

• in jedem VLAN wird der Zugriff auf die anderen Subnetze gedropt.
• Da es sich um LAN local Regeln handelt, betrifft es die Gatways in den jeweiligen Subnetzen.
• Das Haupt-LAN wird nicht eingeschränkt.

Im Endeffekt verhindern die Regeln, dass ich beispielsweise aus dem VLAN 10.10.2.0/24 das Gateway 10.10.1.1 erreiche. Also im Prinzip machen sie das, was die formulierte Anforderung war.

Soweit so gut. Aber warum wollen wir das überhaupt?

Wenn es darum geht, dass aus einem beliebigen Hinz und Kunz Subnet heraus die UDM/USG nicht konfigurierbar sein soll (was ich für sinnvoll hielte), dann bringen die Regeln nichts! Denn ich kann aus jedem Subnet logischerweise das jeweilge Standard-Gateway erreichen - und zwar auf allen Ports, also sowohl per http(s) als auch per ssh. Somit habe ich immer noch die Möglichkeit, aus jedem Subnet heraus, die Web-GUI der UDM/USG aufzurufen oder eine ssh-Verbindung herzustellen.

Um das zu unterbinden, reichen 2 simple Regeln in LAN LOCAL:

• erlaube aus dem Management/Default-LAN alles (wie bisher)
• verbiete aus allen LANs den Zugriff auf die Ports 80, 443, 23 in allen Privaten Netzen nach RFC1918

Das funktioniert gut.

Aber was sollen die LAN local Regeln aus dem Wiki-Beitrag bewirken. Haben die einen tieferen Sinn, der sich mir nicht erschließt?

Ich würde Dir den Wechsel zu einem DynDNS Anbieter empfehlen, mit dem die UDM Pro klar kommt. Ich hatte zuletzt DDNSS.de erfolgreich mit der UDM SE im Einsatz. Bin jetzt auf Google Domains gewechselt, weil ich eine eigene Domain wollte. Aber ddnss.de sollte funktionieren mit folgenden Einstellungen:

Service = dyndns

hostname = "DeineDomainBei.ddnss.de"

username = "DeinDdnssUsername"

password = "DeinDdnssPasswort

ddns-server = "ddnss.de/nic/update?hostname=DeineDomainBei.ddnss.de&myip=%i"

Beachte bitte, dass Du beim Server den vollen Pfad angeben musst und deinen Hostname hart eintragen musst.

Siehe auch hier

Hmm, auf meiner UDM-SE klappt DHCP

Relay anstandslos, über mehrere Subnetze/VLANs hinweg.

Im Subnetz, in dem sich auch der DHCP/DNS Server befindet, hab ich der UDMSE gesagt, sie soll sich aus DHCP komplett raushalten. Hier funktioniert der Broadcast ja von alleine.

Im Gastnetz darf die UDMSE den DHCP-Server spielen.

Alle anderen Netzen habe ich auf Relay gestellt.

Zitat von o_krause

Habe ihn so konfiguriert, dass er in jedem VLAN ein "Bein" mit der IP xxx.xxx.xxx.254 hat und mit dieser IP jedem Subnetz / VLAN einen DHCP und DNS

Server mit separater IP bereit stellt. ( Außer Gast Netz ).

Was spricht gegen DHCP Relay?

und ich dachte schon, aufgrund der aktuellen weltweiten Lieferketten-Probleme sind die bunten LEDs ausgegangen

Mein Verständnis ist, dass über den WiFi-Type "Guest Hotspot" zwei Dinge passieren:

• Bestimmte Settings in den WiFi Advanced Configurations werden vorbelegt, wie z.B. wird die Client Device Isolation standardmäßig aktiviert. Beim Standard-WiFi Type ist die Client Device Isolation per default abgeschaltet. Das kannst du aber in jedem Fall händisch so einstellen, wie du es gern hättest.
• Beim Guest Hotspot wird halt noch zusätzlich sowas wie eine Landing Page mit optional separater, zusätzlicher Anmeldung, Abnicken von irgendwelchen Disclaimern, Zeitbegrenzung, etc. aktiviert. Darüber hinaus bietet der Hotspot-Manager dann die Möglichkeit, dir das auszuwerten, wie dein Gast-WLAN genutzt wird. Das ist aus meiner Sicht eher interessant für Hotels oder generell öffentliche Räume.
  Außerdem bietet der Guest-Hotspot die Einstellung von erlaubten und verbotenen Subnets und generiert daraus die entsprechenden Firewall-Regeln. Aber auch die lassen sich manuell erstellen.

Mein Fazit:

Für den Heimanwender ist der Guest-Hotspot unnötig. Normales WiFi, das einem Gast-Subnet zugeordnet ist, reicht aus.

Disclaimer:

Ich bin noch relativ neu im Unifi-Universum und komplette Fehlinterpretation meinerseits kann nicht ausgeschlossen werden. Davon abgesehen versuiche ich nach besten Wissen und Gewissen zu helfen. Aber das einholen einer zweiten Meinung schadet sicher nicht

Konnte jetzt doch mit einem Windows Client testen und hab vermutlich die Lösung gefunden:

Damit die VPN-Verbindung mit einem Windows-Client klappt, muss in Unifi-Network unter Settings / VPN / Advanced Configuration die Option "Require Strong Authentification" aktiviert werden.

Hat bei mir funktioniert.

Windows kann ich nicht testen.

Kannst du mal einen Screenshot deiner Windows Konfiguration posten? Vielleicht fällt mir was auf.

Klappt bei dir die Namensauflösung im VPN am iPhone?

Du musst L2TP einstellen und nicht ipsec

Ich habe grad ebenfalls erstmals VPN konfiguriert. Radius und VPN habe ich analog eingerichtet wie Du. An den Firewall Regeln habe ich nichts verändert.

Ich kann mich mit dem iPhone ins VPN einloggen.

Wie hast du denn das iPhone konfiguriert?

Was bei mir nicht geht, ist die Namensauflösung im lokalen Netzwerk. Ich muss aus dem VPN heraus die Geräte im LAN mit der IP Adresse ansprechen.

Guten Morgen,

ich habe gestern mein Netzwerk von einer USG-3P mit Controller in einem Docker-Container (Raspberry Pi) auf eine UDM-SE umgestellt. Dabei habe ich das Netzwerk komplett neu aufgesetzt, aber mit identischen Einstellungen.

Was mir dabei (negativ) aufgefallen ist, dass in meinem neuen Setup in der Client-Device Übersicht zwar alle Geräte angezeigt werden - aber ohne Hostnamen! Im alten Setup wurden die allermeisten Hostnamen korrekt angezeigt.

Wichitg an der Stelle ist, dass nicht die UDM-SE als DHCP-Server fungiert, sondern ein dedizierter Windows-Server im VLAN 2, der auch als DNS-Server fungiert. Das Default-Netz und alle anderen VLANs sind auf DHCP-Relay (mit Verweis auf meinen DHCP-Server) konfiguriert. Der DHCP-Server gibt den Clients neben der IP-Adresse natürlich auch den DNS-Server bekannt. Das funktioniert auch alles wunderbar innerhalb meines Netzes.

Aber die UDM-SE selbst kriegt keine Hostnamen mit. Lässt sich das irgendwie konfigurieren?

Ich hab gestern eine neue UDM-SE hinter einem Vigor 167 an einem Telekom-VDSL 250/40 Anschluss online gebracht - ohne Probleme. Ich habe aber auch nicht die App verwendet, sondern klassisch über einen direkt an der UDM-SE angeschlossen PC konfiguriert.

Das VLAN-Tagging macht bei mir das Modem. Ein Neustart der UDM war bei mir nach Umstellung auf PPOE nicht notwendig.

Hier nochmal zum Abschluss des eingetlichen Themas:

Ich bin mittlerweile auf die UDM-SE umgestiegen. Aber da es mir keine Ruhe gelassen hatte, habe ich auch in der alten Konfiguration mit USG-3P (und Controller im Docker) das Netzwerk nochmal neu aufgesetzt. Das Vigor 167 hatte ich nur mit 1 Lan-Kabel (an P1, auch wenn es in der Vigor 167 Anleitung anders steht) an die USG angebunden. Keine weitere Patch-Verbindung zw. Vigor und USW!

Damit hat dann alles wie gewünscht funktioniert. (Topologie richtig angezeit, Uplink-Port am Switch korrekt identifiziert).

Was allerdings passiert, wenn ich die 2. Patchverbindung zw. Vigor und Switch wieder hergestellt hätte, kann ich nicht sagen, da ich es nicht probiert hatte. So wichtig ist der Zugriff auf's Modem dann auch wieder nicht.

Kurzer Zwischenstand: da ich mittelfristig vom USG / Docker-Controller auf DMPro umsteigen will, habe ich beschlossen, die Umstellung vorzuziehen. Dann kann ich bei der Gelegenheit eh komplett neu aufsetzen.

Die von Razor angehängten Anleitung beziehen sich auf das 165er und auf das 166 Modell - vom 167 ist da nicht die Rede. Dass es einen Unterschied gibt, sieht man schon daran, dass beim 167 die Anschlüsse "seitenverkehrt" sind im Vergleich zum 165/166. Ich habe mal die Anleitung vom 167 angehängt. Da ist auf Seite 3 eben P2 mit "PC or Broadband Router" verbunden.

darkman242: Hast du das Vigor 165 oder 167?

Ich werde den zweiten Anschluss, wie empfohlen, erst mal bei Seite lassen. Trotzdem muss ich wissen, ob ich das USG jetzt an P1 (wie beim Vigor 165/166) oder an P2 (siehe Anleitung 167) anschließen muss. Will ja nicht nochmal in das gleiche Problem laufen.

Der Controller läuft in einem Docker Container auf einem Raspberry Pi 4.

Ok, da ich bisher noch nicht allzuviel Arbeit in die Konfiguration gesteckt habe, bin ich geneigt. nochmal frisch aufzusetzen. Was ist da der Königsweg? Mein Controller läuft wie gesagt in einem Docker-Container. Einfach mal das Volume des Unifi-Containers plattmachen? Oder vorher alle Unifi Geräte vom Controller "ablernen"? Das Modem ebenfalls auf Werkseinstellungen?

Nochmal zum Modem: Aus der Anleitung des Vigor 167 habe ich herausgelesen, dass P2 mit dem Router/USG verbunden werden soll. P1 habe ich als LAN-Port interpretiert und direkt mit dem Switch verbunden (sh. Bild). Ist das falsch oder egal? (ich meine P1 und P2 am Vigor 167 zu vertauschen?)

Habe ich jetzt gelesen, aber leider nicht verstanden, was das mit meiner Konfiguration zu tun hat. Ehrlich gesagt, will ich auch nicht in den config-files rumbasteln.

Was mich am allermeisten irritiert: wieso erkennt der Controller das USG nicht mehr, wenn ich die direkte Verbindung vom Switch zum Vigor kappe? DAs USG ist doch selbst mit dem Switch an dessen Port #2 verbunden.

Jetzt ist das 1. Problem aufgetaucht:

Meine Verkabelung:

TAE ==> Vigor 167 #2 ===> UGS-3P ===> #2 USW-24-G1 ( = UPLINK)
                  #1 ===============> #9 USW-24-G1 ( = Monitoring DSL-Modem)

Laut Doku von DrayTek ist Port2 der Anschluss für den Router und Port1 habe ich auf 192.168.0.254 konfiguriert.

An dem USW-24-G-1 hängen weitere Unifi-Switche, aber auch direkte Clients.

Damit funktioniert alles im Prinzip, bis auf 2 Schönheitsfehler:

• Im USW-24-G1 wird Port #9 als Uplink-Port angezeigt, obwohl daran nur der Monitoring-Port des DrayTek Vigor 167 ngeschlossen ist. Der richtige Uplink-Port müsste #2 sein.
• Die von Controller erzeugte Netzwerk-Topologie stimmt ncht. Die allermeisten non-Unifi-Clients, die am USW-24-G1 hängen, werden in der Topologie fälschlich einem anderen, nachgelagerten Unifi-Switch zugeordnet!

Probeweise habe ich mal das Vigor 167 (#2) vom USW-24-G1 (#9) getrennt, um zu sehen, ob er dann den korrekten Uplink-Port wieder identifiziert. Und dann wurde es seltsam:

Sobald diese Verbindung getrennt wird, zeigt der Controller das USG-3P als offline an und es findet kein Routing mehr statt. Die USG selbst leuchtet blau. Ein Neustart sowohl des Controllers als auch des USG hat nichts gebracht. Erst als ich die Verbindung zw. dem Vigor und dem USW-24-G1 wieder hergestellt hatte, ging die USG-3P wieder online.

Das verstehe ich jetzt überhaupt nicht.

Es gibt Neues zu berichten!

Zitat von anderl1969

Was steht als nächstes an:

1. alle Switche mit Unifi Geräte ersetzen:
   1. Den 24 Port im Keller habe ich bereits ersetzt
   2. Der 16 Port POE fürs Büro ist bestellt
   3. von den 5 USW-Flex-Minis ist einer im Zimmer vom Sohn installiert, für die anderen 4 muss ich noch Netzteile organisieren*
   4. der USW-Lite-8-POE fürs Wohnzimmer gestaltet sich schwierig in der Beschaffung
2. WLAN von Fritz-APs auf Unifi-APs umstellen
3. VLANs aufsetzen

1.4 Kaum hatte ich es gerschrieben, war der Lite-8-PoE im Shop verfügbar. Hab sofort zugeschlagen und nun ist das Teil auf dem Weg

2. Einen ersten AP habe ich im Keller bereits installiert. Er soll dort die Lücke schließen, die die abgebaute Fritz 6591 hinterlassen hatte. Im EG und OG verrichten noch die AVM-Geräte ihren Dienst.

3 Ich hab mal angefangen ein paar VLANs aufzusetzen und habe es tatsächlich geschafft, die ersten beiden Geräte (PV-Anlage und Wasser-Enthärter) in das IoT-Netz zu verfrachten. DHCP-Relay auf meinen DC hat einwandfrei funktioniert

Juhuu

Hat mein 24er Switch nicht. Hatte ich beim Kauf nicht bedacht. Aber mittelfristig will ich eh das USG gegen eine DMP SE ersetzen und dann hätte ich PoE für die Minis. Bis dahin muss ich improvisieren...