Beiträge von gr00ve

    Beim genauen Abgleich erscheinen mir die beiden FB Configs hinsichtlich der phase2localid vertauscht.

    Nein, das stimmt so. Das ist genau die Konfiguration, die bei mir funktioniert. Ich kann aus meinem UniFi Netz über die LAN zu LAN Koppelung auf das Remotenetz und umgekehrt von dort auf alle meine Subnetze zugreifen. Heimnetz(e) <-> USG Pro 4 <-> FritzBox 7490 <-> FritzBox 4020.

    Du hast übrigens Recht, die Outbound Route ist unnötig. Die habe ich bei der Fehlersuche installiert, weil ich mal irgendwo gelesen hatte, daß Router Anfragen für private Adressbereiche normalerweise nicht über die WAN Schnittstelle routen. Aber die Info war wohl nicht richtig, es geht auch ohne die Route.


    Wo hängst Du? In diesem Thread findest Du alles, was Du brauchst. Bei zwei USGs musst Du halt nur die Configs in beiden FBs anpassen.


    Gruß,

    gr00ve

    gr00ve

    Ja, in beiden "..." cfg-Dokumenten ist das gleiche PSK. Ping funktioniert, über das Netzwerk 192.168.10.0/24 kann ich FB B (Büro) 192.168.178.1 anpingen, andere Geräte hinter FritzBox B (Büro) Ich kann nicht anpingen, aber ich kann über "Remotedesktopverbindung" eine Verbindung zu ihnen herstellen. Ich werde Bilder anhängen.


    Das bezieht sich jetzt auf den PC hinter dem Cisco Switch, oder? Möglicherweise blockiert der den Ping, lässt Remote Desktop aber durch.


    Ist die IP Adresse, die die UDM von Box B bekommt fix oder kann sich die ändern? Dann könnte die Route nicht mehr passen. Die Route in der UDM halte ich für falsch, da die UDM ihr Gateway Box B sowieso kennt. Da muß m.M.n. das Netz von Box A mit Next Hop Box B rein. So ist es bei mir.


    ubiquiti-networks-forum.de/attachment/1964/


    Sonst sticht mir mir jetzt gerade kein Fehler ins Auge. Der einzige Unterschied zu meinem Setup ist, daß Du doppeltes NAT hast (Fritzbox und UDM), während ich das bei meinem USG ausgeschaltet habe. Das funktioniert aber bei der UDM nicht mehr.


    Gruß,

    gr00ve

    matijaF

    Ich vermute, daß da der Tunnel nicht steht. Hast Du in beiden Boxen den gleichen PSK? Vielleicht ein Tippfehler oder die Config Datei nur in Box A geändert und den Key in Box B gleich belassen? Kommst Du von Netz 192.168.10.0/24 auf 192 .168.178.0/24? Funktioniert ein Ping auf auf Box B?

    Code
    ping 192.168.178.1

    Wenn diese Fehler ausgeschlossen sind, poste mal bitte Screenshots Deiner FW Rules in der UDM und der static routes in Box B.


    Gruß,

    gr00ve

    matijaF


    Sodale, entgegen dem, was ich gestern geschrieben hatte, wollte ich jetzt doch nicht auf AVM warten und habe selbst recherchiert.


    Deine VPN Config von Fritz Box A (Home) muß wie folgt aussehen:


    Code
    phase2remoteid {
                            ipnet {
                                    ipaddr = 0.0.0.0;
                                    mask = 0.0.0.0;
                            }
                    }
                    phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                    accesslist = "permit ip any 192.168.178.0 255.255.255.0",
                                 "permit ip any 10.1.1.0 255.255.255.0";
            }


    In der Originaldatei, die von Fritz-Fernzugang-Einrichten erzeugt wird, steht bei "phase2remoteid" das gegenüberliegende Netz. Sind dort aber, wie bei Dir und mir, mehrere Netze vorhanden, muß da ipaddr = 0.0.0.0; und mask = 0.0.0.0; stehen und die Remotenetze kommen in die Accesslist (Achtung auf Komma und Semikolon, die sind wichtig). So funktioniert es und ich komme von der Remotesite in alle meine Subnetze.:thumbs_up:


    Die Fritzbox routet mit dieser Konfiguration den Traffic für die Netze aus der Acceslist durch den Tunnel und alles Andere wird normal behandelt. Das habe ich über tracert verifiziert.


    Gruß,

    gr00ve

    matijaF

    Genau zu diesem Problem läuft meine Anfrage bei AVM. Die Fritzbox A muß wissen, daß sie Traffic mit Ziel 10.1.1.0/24 durch den Tunnel zu Box B routen muß. Daher muß in der Config Datei dieses Netz auch als Remote Netzwerk eingetragen sein, zusätzlich zu 192.168.178.0/24. Wie der Eintrag genau lautet (Syntax), ist Gegenstand meiner Anfrage. Das müsste irgendwie wie folgt aussehen:

    Code
    phase2remoteid {
                            ipnet {
                                    ipaddr = 192.168.178.0,
                                    ipaddr = 10.1.1.0;
                                    mask = 255.255.255.0;
                            }
                    }


    Ich weiß aber nicht, ob das genauso richtig ist oder ob auch an anderer Stelle noch was eingetragen werden muß. Ich könnte jetzt experimentieren, aber dazu müsste ich immer hin und her fahren, da frage ich lieber beim Support nach und mache es dann beim ersten Mal richtig. :winking_face:

    Wenn Du durch Experimentieren drauf kommst, sag mir bescheid.

    Zusätzlich wird es wahrscheinlich auch in der UDM eine Firewallregel brauchen, damit Pakete mit Source 192.168.10.0/24 durchdürfen. Das geht im USG über Groups, wie die UDM das macht, weiß ich leider nicht.


    Edit: ich sehe gerade, die Firewall Regeln hast Du schon. Dann kann es nur an der Config liegen.


    Gruß,

    gr00ve

    Jedoch werden wir es nicht ändern können.

    Wir vielleicht nicht, aber die Amis schon mit einem g'scheiten Shitstorm :winking_face: :



    Ich bekomme 6.0.45 noch nicht, also kann ich nicht verifizieren, dass es tatsächlich wieder funktioniert.

    EDIT: ich habe 6.0.45 per ssh installiert, sehe aber kein Multisite. :frowning_face:


    Maddeen Seit gerade eben habe ich 2.0.26 auf dem CloudKey und komme noch immer sowohl per FTP als auch ssh rein.


    Gruß,

    gr00ve

    Guess what, ich habe weder Apple noch Tesla. :smiling_face_with_sunglasses:

    Auch darüber spricht Tom Lawrence in seinem aktuellen Video: es gibt kein Konkurrenzprodukt mit Self Hosted Managementsoftware am Markt, bis auf eine Firma (Name habe ich mir nicht gemerkt), die die Unifi Oberfläche mehr schlecht als recht nachbaut und deren Hardware nicht funktioniert. Alles andere ist rein cloudbasiert mit allen Nachteilen.


    Zitat von Mailoh

    Und was ist dann mit dem integrierten CloudKey in der UDMpro?

    Ist der dann überhaupt noch nötig wenn die Software in einer bzw. über eine Cloud läuft?


    Die UDM / UDM Pro betrifft das gar nicht, da die erstens den Controller selbst hostet und zweitens nie Multisite konnte. Es ist nicht so, daß der Controller nur noch in der Cloud läuft, das hast Du offenbar falsch verstanden. Es geht nur um die neue Firmware des Cloud Key Gen2/2+, die man ohne Account bei Unifi nicht mehr aktivieren kann. Der Controller kann weiterhin lokal laufen oder irgendwo gehostet werden.


    Gruß,

    gr00ve

    Ich habe es mir gerade angeschaut, und auch das erwähnte Video von Lawrence Systems. Es geht um die Firmware des Cloud Key Gen2/2+. Der Hauptkritikpunkt ist, daß Unifi beim Update auf Firmware 2.0.24 ein wichtiges Feature WEGGENOMMEN hat, nämlich die Möglichkeit, weitere Sites einzurichten. Das war mir auch schon aufgefallen und jetzt habe ich die "offizielle" Bestätigung. Ich finde das, gelinde gesagt, eine riesen Sauerei! :pouting_face::pouting_face::pouting_face:

    Wo gibt's denn sowas, das ein Update wichtige Features wegnimmt?!? Dazu muss man allerdings sagen, daß die Controller Software ansich nicht betroffen ist, wenn man sie selbst hostet (Rechner, Pi, NAS) oder auf einem gemieteten Server hosten lässt. Trotzdem ärgert es mich, den ich habe mir den Cloud Key ja genau deshalb gekauft, weil ich eine kleine stabile Kiste wollte, auf der alles bei mir lokal läuft.


    Apropos lokal, die zweite, eben so ärgerliche "Neuerung": das Erstsetup des Cloud Keys Gen2/2+ verlangt jetzt zwingend ein Unifi Account und damit eine Internetverbindung. Man kann nach dem Setup zwar lokale Admins einrichten und ohne Cloud arbeiten, aber wenn Eure Kiste aus irgendeinem Grund einen Hardreset braucht, bekommt Ihr sie ohne Unifi Account nicht mehr aktiviert. Heißt natürlich für die Zukunft auch, wenn Unifi entscheidet, daß die Dinger ab morgen EOL sind, sind sie möglicherweise nicht mehr nutzbar, weil die Onlineaktivierung nicht mehr funktioniert. :pouting_face: Das erinnert mich irgendwie an das Kommunikationsdesaster von SONOS bzgl EOL von diversen Speakern im letzten Jahr, wo die dann aber schleunigst zurückgerudert sind. Ich muss ganz ehrlich sagen, heute überlege ich mir zum ersten Mal, nachdem das System gerade ein Monat alt ist, ob ich nicht auf's falsche Pferd gesetzt habe... :unamused_face:


    Grüße,

    gr00ve

    ja sobald auf z.B. 2 von 3 kabelgebundenen SONOS geräten das WLAN deaktiviert ist kann auch kein loop mehr entstehen.

    Richtig. Oder aber, der Switch verhindert das. Die Sinfonisk Lampe im Zimmer meiner zweiten Tochter ist am Weitesten vom Connect weg und daher habe ich sie an die LAN Dose angeschlossen, welche direkt am USW-24-POE hängt. Das funktioniert auch mit eingeschaltetem WLAN, da der Switch damit umgehen kann. Die USW-Flex-Mini können das jedoch nicht, da würde das gleiche Setup eine Störung verursachen.


    Gruß,

    gr00ve

    Jungs, habt Ihr Eure SONOS Geräte in einem eigenen VLAN oder laufen die im Management LAN? Hintergrund der Frage ist: bei mir hängen sie im untagged LAN, während die Geräte der Kinder im VLAN Kinder sind. Wenn ich SONOS jetzt in ein IoT VLAN verbanne, könnte es laut diversen Berichten im Netz Probleme mit dem Zugriff aus dem Kinder VLAN geben. Wie habt Ihr das gelöst?


    Gruß,

    gr00ve