Beiträge von DoPe

Zitat von TWIN013

Hallo!

Mir ist beim Erstellen der Regel "allow local DNS" aufgefallen, dass unter Destination nicht nur eine IPv4 Adress Group "09 | DNS Server" angegeben wird, sondern auch die Port Group "09 |DNS Ports", was ja auch Sinn macht. Nur gibt mir der Network Controller 7.4.145 keine Möglichkeit diese zu hinterlegen... handelt es sich hierbei evtl. um einen Bug, oder ist jemandem bekannt, wie ich die Port Group einblenden kann? Ein Screenshot findet sich anbei. Vielen Dank schon mal!

Also auf Deinem Screenshot siehts nach bug aus. Du hast bei Source und Destination die gleiche Einstellung aber bei Destination fehlt das Feld für den Port. Sollte ja genauso ein Feld für IP- und ein Feld für Portgruppe da sein wie eben bei Source.

Was soll denn das Ziel sein? Davon hängt schon ab was sinnvoll ist und was nicht.

Also wenn ich das richtig sehe, ist das Zerotier sowas wie früher Hamachi und jetzt LogmeIn oder so ähnlich. Den einzigen Vorteil den ich sehe, ist dass der ganze Spaß so tun kann als wäre es ein Layer2 Netzwerk ... genau dafür haben wir früher sowas genutzt um nur LAN taugliche Spiele übers Internet zu spielen.

Zumindest geht das mit Open VPN auch ... Wireguard weiß ich nicht ob man da bridgen kann. Führt aber dann dazu das auch Broadcast permanent durch den Tunnel geht.

Wenn man nur eine geroutete Verbindung braucht, dann würde OpenVPN und Wireguard funktionieren. Vorteil wäre eben dass man dazu nicht über einen Dritten gehen muss. Und natürlich kostet es nicht monatlich was extra, nur weil man einen Peer mehr haben möchte.

Die sollte 802.3af/at machen also aktives POE/POE+ nach Standard. Somit greifen Mechanismen um zu erkennen ob das Gerät POE Versorgung benötigt.

Früher hatte Ubiquiti gerne passives POE in allen Varianten in Verwendung wo stumpf eine bestimmte Speisung auf den Port gelegt wurde. Ich hab mich mal bei einem Rettungsturm am Strand vertan und das falsche Kabel in mein Notebook gesteckt ... Es fing an zu rauchen ... Zum Glück sofort gesehen und abgezogen - LAN ist auch heute noch ok Da hatte ich mich an einem passiven POE Injektor an das Kabel gehängt die zu einem passiv gespeisten Accesspoint ging und nicht auf die Zuleitung zum Injektor auf der nur das LAN ohne POE drauf war.

Zitat von surtalogi

Danke, hatte ich sogar schon richtig eingerichtet, aber mir wurde dabei irgendwie nicht bewusst, dass dies die tagged/untagged Ausgabe an einem Port abbildet.

Etwas analoges zu einer PVID find ich hier aber nicht, oder habe ich das auch übersehen?

Sowas wie eine PVID gibt es hier nicht. Wenn auf einem Port etwas ungetagged reinkommt, dann gehört es zu dem Netz, welches in dem entsprechenden Portprofil dieses Ports als ungetagtes Netz (natives Netzwerk) eingestellt ist.

Wenn es Probleme mit kein DHCP oder falsche IP Ranges durch DHCP gibt, dann liegt die Vermutung nahe, dass Du irgendwo Portprofile fehlerhaft eingestellt oder zugewiesen hast oder du aber eine Verbindung gepatcht/nicht gepatcht hast und somit keine Verbindung zu einem Netzwerkbereich hast oder aber zwei eigentlich getrennte VLANs auf Layer 2 verbunden hast.

ohne einen Router, welcher Interfaces in den VLANs hat, sind die VLANs getrennt.

Die Einstellungen was getagged oder ungetagged übertragen wird, kannst Du mit dem erstellen von Portprofilen im Unfi Controller regeln. Dort Profile nach Wunsch anlegen und dann den Ports der Switche zuweisen. Beim anlegen von VLANs werden da auch schon Profile erzeugt. Evtl. reichen die schon für dein vorhaben.

mit vorinstalliertem Schlüssel = with pre-shared key

Oder was ist nicht da? Das ist bei W10 und 11 so. Davor sah das ja anders aus.

Wenn Du das granular haben willst, dann wird es in jedem Fall aufwendig.

Ganz simpel kannst du in beiden Routern ein Profil bei ports und ip groups "lokale Netze" und "remote Netze" erstellen vom typ ip adress/subnet. Dann jeweils in lokale Netze die IP Netze rein, die auf die anderen entfernten Netze zugreifen dürfen. In remote die IP Netze vom anderen Standort auf die zugegriffen werden darf.

Dann in den firewalls bei LAN in eine allow Regel vor dem rfc blocken hinzufügen. Source "lokale Netze" und Destination "remote Netze". Das ganze kann man endlos aufblasen ... je nachdem wie die anforderungen sind.

Also wenn Du die Regel mit dem RFC auf beiden Seiten hast kann das schon das Problem sein. Du musst natürlich in LAN IN auch erlauben dass ein lokales Netz mit einem Remotenetz kommunizieren darf. Und auf der anderen Seite natürlich das passende Gegenstück. Testweise kannst Du auch kurz mal die Firewallregeln pausieren in beiden Routern.

Mit dem Port 1194 UDP in WAN Local bin ich mir ziemlich sicher die Regel selbst erstellt zu haben. Was automatisch angelegt wird sind die statischen Routen für die Remotenetze.

Sieht erstmal okay aus.

Hast Du den Port 1194 UDP auf beiden Seiten in WAN Local zugelassen? Der Vigor wird ja vermutlich im Bridge Mode laufen, also PPPoE Einwahl durch die Unifi Router? Falls nicht hast Du die Ports dort weitergeleitet?

Hast Du in den Firewalls evtl. Regeln drin die den Traffic blocken? Zum Beispiel RFC zu RFC verbieten um Traffic zwischen VLANS zu unterbinden?

Zitat von ulli

So hab ich es probiert. Als vorinstallierten Schlüssel den Pre-Share Key eingegeben. Leider ohne Erfolg.

Was heisst ohne Erfolg? Fehlermeldung beim Einwahlversuch?!? Wie testest Du - real von aussen oder hängst Du im LAN, wo Du ja eigentlich mit VPN Zugriff haben möchtest?

Zitat von ulli

Das Einrichten der VPN-Verbindung gestaltet sich schwierig für mich. Mithilfe des Videos:

[Externes Medium: https://www.youtube.com/watch?v=TOb74xrmj5Q&t=288s]

habe ich Radius/VPN-Server auf der Dream Machine eingerichtet. Übr IP64.net hab ich eine DDNS erstellt mit einem Pre-Shared Key. Unter Win 11 kann ich diesen Key aber nicht einrichten. Oder ich verstehe das nicht richtig. Kann mir jemand sagen, wie ich das richtig einrichten kann!?

Also sollte wie folgt sein.

Meine UDM hat mit der 2.4er schon Spirenzien gemacht. Die meinte mir endlos oft mitteilen zu müssen, dass mein Internet temporär weg wäre oder gar richtig disconnected und wieder connectet. Absurd ... wenn ich dauerping von Arbeit auf meine WAN IP gemacht hab blieben die Meldungen aus. Ping beendet und kurz danach kam die erste Mail ...

Ähnliches gab es ja auch schon mal als Bug. Also:

Hab dann Echo Server auf 8.8.4.4 gestellt und die DNS Server von 1.1.1.1 und 8.8.8.8 abgeändert (das sind ja die IPs hinter ping.ubnt.com) Seit dem ist Ruhe.

Bin auf die 2.5er gespannt.

Zitat von whosdrunk

Ich bin als root am Debian angemeldet, jedoch kennt er sudo Befehl nicht. Da kenne ich mich auch nicht besonders aus,

Wenn Du als root angemeldet bist, musst Du das sudo weglassen. Das sudo wechselt sozusagen auf den oberadmin mit dem dahinterhängenden Befehl, da man ja möglichst wenig als root angemeldet sein soll und so dann trotzdem was administratives machen kann.

Auf dem Port an dem der Cloud Key hängtbrauchst Du nur das native (Untagged) Netz für den Cloudkey. Der Rest wird dort ignoriert.

An den Accesspoints benötigst du alle VLANs die vom Accesspoint für das WLAN nutzbar sein sollen.

Der einfachste Fall. Du nimmst das UniFi Default LAN für das Management und erstellst für alles andere neue VLANs:

Dann also das Default LAN als untaggegt auf den Port vom Cloudkey (Da kannst Du auch Profile ALL lassen)

auf den Accesspoints dann entweder ein Profil erstellen (untagged das Default LAN plus deine VLANs getagged) oder eben wieder ALL verwenden.

Mann kann das Management auch in ein VLAN schubbsen. Dann muss bei den Accesspoints, Switchen bei Service das Management LAN angepasst werden und der Cloudkey sollte dann auch nativ in diesem VLAN hängen. Bei dieser Variante muss aber beim Adopt einiges beachtet werden ... es ist zu klären wie finden sich neues Gerät und Cloudkey (DHCP Option, Manuell per SSH, whatever) und erlaubt das Firewall Setting den Adoptionvorgang

Tja das passiert auch bei den Leuchtringen der alten US Switch Modelle. Wir machen die LEDs an den Geräten inzwischen immer aus. Ist nicht so toll wenn man einen Gerät lokalisieren will und das Blinken nicht mehr sichtbar ist. Switche kann man ja beschriften aber das hilft bei APs in 5m Höhe nicht so sehr.

Hatte mir hier auch mal einen AP aufgefummelt - glaub n alter UAP-LR. Bei dem war eine Antenne wie ein Käfig über die ganze Platine - also für Lötarbeiten störend. Dann hab ich mir die LEDs mal angeguckt und den Austausch verworfen. Ohne vernünftiges Lötbesteck und eine gute Lupe kann man das vergessen.

Azure only hat noch n Jahr ... und ich hätte jetzt vermutet, dass es sich um eine OEM Server Lizenz und nicht um VL Lizenz handelt ... nur so rein vom Investitionswillen

Zitat von jkasten

ESXI 6.5 und Windows 2008!? Da würde ich keine Minute mehr reinstecken. Die Hardware dürfte auch zu alt für ESXI 7 sein. Also da wird die Firma leider mal ein wenig Geld in die Hand nehmen müssen und alles erneuern.

Dann aber wohl gleich auf die 8er Version, sonst setzt man auf das nächste tote Pferd

Eigentlich sollte es nix ausmachen. Viele APs kommen ja mit Kunststoffabdeckung in der OVP und da konnte ich bisher noch kein schlechteres Signal mit oder ohne diese Abdeckung feststellen. Folieren sollte problemlos rückgängig zu machen sein ... da dürfte die Betriebstemperatur behilflich sein.

Ergebnisse würden mich auch interessieren allerdings eher wie die billige Folie auf dem runden gewölbten AP zu verarbeiten ist.

Wenn es getrennte IP Bereiche sein sollen, dann kannst Du auf einem UniFi Switch ein zusätzliches Netzwerk mit VLAN ID deiner Wahl erstellen. Das sollte dann im Netzwerkprofil All auch als getaggt erscheinen. Jetzt suchst Du dir einen freien LAN-Port über den Du das Gastnetz einspeisen willst. Den stellst Du auf das Switchportprofil das den Namen deines Gast Lans trägt (Das sollte automatisch erstellt sein: natives Netz dein Gast LAN und getaggt nix weiter).

Jetzt kannst DU bei deiner Fritte das Gastnetz auf LAN4 aktivieren und LAN4 mit dem oben eingerichteten LAN Port am Switch verbinden. Jetzt nur noch das Gast WLAN auf das richtige VLAN (Gast LAN) packen. Dann verteilt deine Fritte für das "normale" Netzwerk IPs wie bisher und zusätzlich getrennt IPs für dein Gast LAN ... die gibt allerdings die Fritzbox vor! Die beiden Netze sind dann durch die Fritzbox getrennt (auch nicht änderbar).

Das einzige was Du dann noch verstellen kannst ist der Typ des Gast-LAN/Gast-WLAN als Standard oder Gast und den damit verbundenen Dingen wie Isolierung der WLAN Clients untereinander.

Zitat von gierig

Schau dir bitte diesen Artikel an bzw. diesen (recht weit unten) der es Zusammenraft was da abgeht.

Meine alte dreckige Glaskugel sagt das genau das zutreffen könnte bei Dir.

Ohne diese Geschichte würde schon der 1. Client Probleme haben erfolgreich eine Verbindung aufzubauen. Zumal auch die Frage ist ob das überhaupt erforderlich ist. Kenne das nur in Verbindung mit Portweiterleitung zu einem VPN Server z.B. Windows L2TP/IPSec.

Was ist denn an dem Telekom Anschluss für ein Router? Ich tippe darauf, dass eher da das Problem ist. Das Problem hatte ich auch vor ewigen Jahren ... da war es glaube ich allerdings noch PPTP VPN und da lag es am Router auf der Seite mit den 2 Clients ... da ging immer nur eine VPN zu einem Ziel ... 2 gleichzeitige VPNs zu 2 verschiedenen Zielen waren kein Ding. Zu der Zeit gab es noch so Einstellungen wie "PPTP Pass-trough" im Router die oftmals halfen.

OpenVPN und Wireguard sollten aber dieses Problem nicht haben.