Beiträge von Irminsul

    Ich habe noch mal etwas genauer geschaut und ganz unbedarft einen USG am PPPoE Zugang mit WAN1 verbunden und mich ans LAN1 gehangen.

    Zugang zum PPPoE Accelerator hatte ich, weshalb ich gegen testen konnte.

    Folgendes kam dabei heraus:


    USG hatte via PPPoE Internet

    Dazu hatte ich das automatisch erstellte WAN unter Networks von "DHCP" auf "PPPOE" umgestellt und "Name" und "Passwort" eingegeben.

    Mehr nicht! Im Bild 0001 sieht man, der USG hatte Verbindung ins Internet.


    ###########################


    Bild 0002 zeigt, was der PPPoE-Server dem USG zugewiesen hat.

    Die per PPPoE mitgegebenen DNS Server sind 1.0.0.1 & 1.1.1.1


    ###########################


    Im Bild 0003 zeigt das WebIf des USG, nachdem ich schon über eine Stunde über den USG mit PPPoE im Internet unterwegs war und dessen WebIf mehrfachst aktualisiert hatte.


    ###########################


    Nach einem kompletten Neustart des Systems, also USG und Controller und gut acht Minuten warten... Siehe Bild 0004

    Ja der USG blieb während des gesamten Tests auf "Provisioning", obwohl alle Änderungen immer komplett auf diesen übertragen worden waren. :grinning_squinting_face:


    ###########################


    Dafür hatte er dann, wie im Bild 0005 zu sehen, in seinem WebIf aktualisierte Daten. (immerhin :grinning_face_with_smiling_eyes:)

    Den DNS setzt die Vyatta in der resolv.conf selbst auf "localhost" und lässt den USG als DNS fungieren.

    Dieser nutzt dann "für sich" die DNS Server vom Provider und leitet Anfragen dahin weiter.


    ###########################

    Ich habe nur vom Test mit dem USG Bilder gemacht, da es der erste war.

    Zum Spaß, welchen ich noch anfänglich hatte, probierte ich noch mal mit einem USG-4 Pro.

    Das Ergebnis war das gleiche, habe das schnell abgebrochen und auf Fotos verzichtet.

    Beim USG hatte ich von Freitag bis Sonntag immer aufs neue Versucht -> Verhalten immer ziemlich ähnlich.




    Ich spare mir hier mein Fazit!

    Ich bin die nächste Woche auswärts und habe u.a. mit spezielleren Unifi Installationen zu tun.

    Ich forciere da ein paar Experimente zum USG/Firmware/DNS an, eventuell kann man dadurch eine Ursache dieser "Vorgehensweise" entdecken und vielleicht auch eine Lösung finden.


    Ich werde berichten :smiling_face:

    Also die Ergebnisse sind eher ernüchternd für eingefleischte "Ubnt Jünger", ich habe es fast befürchtet.

    In den sieben Aufbauten letzte Woche konnte ich dieses Verhalten an keiner Konfiguration nachstellen.

    Die Internetanschlüsse waren Standleitungen mit statischer IP. Der DNS wurde von Hand in den USGs eingetragen und blieb auch so.

    Ein Anschluss war am WAN dynamisch und bekam darüber auch den DNS.

    Ich hatte an keinem USG das Problem, das der DNS auf localhost gesetzt worden war.

    Eventuell ist es ein Problem mit PPPoE, das werde ich mal noch untersuchen.

    Hallo,


    dann wird dein im ersten Versuch notwendiger Reset durch das eingesprungene STP ""nötig"" gewesen sein.


    Das Auto-Neg an den SFP Ports zu deaktivieren ist eine gängige Praxis, wenn man SFP+ und SFP "mischt".

    Ich mache dies sehr oft, der Link steht für mich gefühlt oft schneller.

    Hallo,


    die Aussagen vom Controller würde ich immer mit etwas Skepsis betrachten (aus Erfahrung).

    Wenn man von einem Endgerät aus in der Lage ist, eine öffentlich IP zu erreichen (z.B. ping auf 1.1.1.1 oder 8.8.8.8), dann ist das Internet grundlegend da.

    Kann man des weiteren aus dem Terminal des Controllers aus (z.B. UCK) eine öffentlich IP erreichen, ist auch hier erst mal alles in

    Ordnung.

    Dann kommt diese Meldung durch den USG, welcher sich seit dem letzten Update öfter den DNS auf den "localhost" setzt.

    Dadurch kann er für sich keine Namensauflösung machen und meldet, Internet nicht da.

    Obwohl das Internet da ist, sein "Telefonbuch" fürs Internet ist "nur" falsch.


    Ich bin die nächste Woche auswärts und habe u.a. mit spezielleren Unifi Installationen zu tun.

    Ich forciere da ein paar Experimente zum USG/Firmware/DNS an, eventuell kann man dadurch eine Ursache dieser "Vorgehensweise" entdecken und vielleicht auch eine Lösung finden.


    Ich werde berichten :smiling_face:

    Hallo,


    ich habe viel Telekom, O² und Vodafone. Hier und da gibt es auch Netzwerke mit SIM Karten von kleineren Anbietern, die aber im Endeffekt wieder meißt wieder zu einem großen gehören.


    Nach den APNs suche ich meißtens auch immer im Netz, denn oft wissen die Kunden diese nicht.

    Nur APNs, welche mich mit öffentlicher IP raus lassen, habe ich bisher keine gefunden.


    Zuletzt hatte ich einen Anbieter aus Österreich, bei welchem der APN gleich blieb.

    Es wurde nur die Option der statischen IP aufgeschalten.

    Hallo,


    mal ein etwas anderes Thema, ich setz das mal hier rein.

    So direkt konnte ich es keiner Kategorie zuordnen, da man diese Lösung, sofern es die denn gibt, universell einsetzen könnte.


    Ich hatte hier im Forum gelesen, das man mit den passenden APN Einstellungen am LTE eine öffentlich IP beziehen könne.

    Da wäre meine Frage:

    Mit welchen APN Einstellungen kann ich den NAT am LTE Mast umgehen und bleibe trotzdem mit LTE verbunden?

    Das fände ich ja wie bissel richtig gut :smiling_face:

    Je Provider sicher verschieden, aber wäre gut.

    Denn die Provider lassen sich eine statische IP hier im Lande gut bezahlen. In Österreich kostet mich das nur knapp 5€.


    Bisher muss ich hier im Lande daher den Tunnel meist vom LTE aus initiieren.

    Das ist bei manchen Kunden suboptimal, da viele mit Technik nichts zu tun haben wollen.

    Einfach mal auf die Schnelle einwählen ginge da nicht.


    Gruß und danke schon mal im voraus für Tips :smiling_face:

    Hallo,


    es gibt im DHCP Bereich drei Optionen:

    DHCP Server -> es arbeitet ganz normal ein DHCP Server

    DHCP Relay -> eine Option, wo man einen "entfernten" DHCP Server als zentralen DHCP Server nutzen kann (um es kurz zu beschreiben)

    None -> DHCP Server / DHCP Optionen aus


    In deinem Fall ganz normal "DHCP Server" aktivieren, Leases Bereich (IP Pool) angeben und die DNS von Hand eintragen.

    Beim DHCP Request bekommen dann die Clienten nicht nur eine IP, Gateway und "default Route", sondern auch einen DNS mitgegeben.

    Genau den DNS, welchen du da angegeben hast.

    Z.B. den DNS 1.1.1.1 & 1.0.0.1

    Oder mit entsprechenden APN Einstellungen eine öffentliche IP beziehen. So mache ich es bei der Telekom. Mein LTE Router kann Bridge also liegt die öffentliche IP direkt an der UDM-Pro.

    Mit welchen APN Einstellungen kann ich den NAT am LTE Mast umgehen und bleibe trotzdem mit LTE verbunden?

    Ohne LTE ist mir klar, aber mit?

    Das find ich ja wie bissel gut :smiling_face:

    Denn die Provider lassen sich eine statische IP hier im Lande gut bezahlen. In Österreich kostet mich das nur knapp 5€.

    Hallo,


    ob ein Adapter richtig funktioniert oder nicht, kann man am besten per ssh auf dem jeweiligen Gerät prüfen.

    Auf der Konsole im Linux kann man den Status der Schnittstellen direkt abfragen.


    Grübeln lässt mich, warum nur durch einen neuen Link, das Netzwerk "so spinnt".

    Da muss noch was mehr "im argen" gewesen sein.

    Ursachen schweben mir da einige im Kopf, doch will ich hier keinen Roman starten :smiling_face:

    Hallo,


    mit einer USG und dem Unifi Controller kann man recht simpel einen VPN mit dem Controller im "klickbunti" aufbauen.

    Entweder lässt man sein(e) USG(s) auf einen zentralen Punkt zum VPN einwählen und hat dann quasi seine eigene "Cloud" man lässt den USG einfach als VPN Server fungieren.

    Dann nur noch bei Bedarf von außen einwählen.


    IPsec ist im Controller sehr einfach einzurichten.

    Hallo,


    ich nutze dazu VPN.

    Ich wähle mich von außerhalb per VPN in das Netzwerk ein und kann von da dann so arbeiten, als wäre ich lokal mit meinem Laptop im Netzwerk.

    Für meinen Geschmack ideal und für mein Sicherheitsempfinden perfekt.

    Hallo,


    zwecks mangels an detaillierten Konfigurationsdaten ist die Ursache nur schwer zu erraten.

    Mein erster Gedanke war die Portkonfiguration an der UDMP und die Gbics.

    Kompatibilität zum Ubnt heißt nicht, das alle Ubnt Geräte den Adapter unterstützen.

    Danach kam ich nicht mehr auf den Controller, Internet ging zunächst aber noch.


    komme aber weder auf den Controller noch wählt sie sich ins Internet ein.

    Hast du den Zugang zum Internet mit Ping oder mal mit mtr geprüft?

    Damit auch mal allgemein durchs Netzwerk "getastet"?

    So kann man sehr gut eruieren, bis wohin eine Kommunikation funktioniert und ab wo dieses abbricht.

    und da hat man dann einen Punkt, an dem man ansetzen kann.


    Sonst ist das nur immer Spekulation und eventuell ein zufälliger Treffer dabei.

    Hallo,


    man kann einen resett des USG und Switches machen, das bringt oft abhilfe, nur sollte man eines im Hinterkopf behalten.


    Hat der Switch eine spezielle Konfiguration der Portprofile, ist diese dann auch erst mal weg und muss neu erstellt werden.

    Ist da nichts individuelles, ist ein Reset zumeist "schmerzfrei".


    Hat der USG seinen IP Bereich von 192.168.1.0/24 für das Management nicht mehr, muss man hier auch wieder von Hand anpassen, wenn der Reset gemacht wurde.


    Ich versuche vor dem Reset immer folgendes, das hilft recht oft.

    Ich wähle mich per SSH in das betreffende Gerät und führe folgenden Befehl aus:


    set-inform http://<ip_vom_controller>:8080/inform


    Diesen Befehl locker gleich dreimal hintereinander ohne Pause absetzen (Unifi ist gemütlich)

    Oft bekommt es dann der Controller mit hat die Geräte wieder als "connected" gelistet.