Beiträge von ssd376

Super Idee mit dem Rack-Planer.

Das Programm hat leider nur 2HE angelegt und ich konnte keine weiteren HE's und/ oder Geräte hinzufügen.

Bitte meinen "Test"-Eintrag löschen, da ich keine Löschoption gefunden habe. - Danke

Herzliches Beileid und viel Kraft für die Angehörigen.

Wenn ich mich einmischen darf`?!

Ich hatte auch soeben das Problem, nur das nach der von BlackSpy geposteten Lösung

Zitat

apt purge unifi -y

wget https://dl.ui.com/unifi/7.3.83/unifi_sysvinit_all.deb

dpkg -i unifi_sysvinit_all.deb

immer noch der HTTP 404 Fehler angezeigt wurde.

Daraufhin habe ich im Verzeichnis /boot/config.txt des RaspberryPi den Eintrag arm_64bit=0 hinzugefügt.

Anschließend einmal den RaspberryPi rebootet.....und alles ist wieder schick.

Es mag nicht die sauberste Lösung sein, aber für meine Bedürfnisse durchaus genügend. - Vielleicht konnte ich dem ein oder anderen weiterhelfen?!

Vielen Dank ihr beiden für eure Kommentare.

Wie von mir selbst geschrieben und auch von Eckart "quasi bestätigt", scheint es wirklich mit der Version Probleme zu geben.

Wie erwähnt habe ich ein Downgrade durchgeführt und mittlerweile läuft alles auch wieder stabil wie vorher.

Hallo zusammen,

Ich wollte nur mal eine Zwischen- oder eigentlich Abschlussmeldung geben!

Außer dass ich, wie bereits erwähnt, die Firmware der beiden APs zurückgesetzt habe und einmal aus lauter Verzweiflung die USG rebootet habe, wurden von mir keine weiteren Maßnahmen getroffen. Wobei man könnte es auch W U N D E R H E I L U N G nennen.

Vielleicht hat einfach eine Kombination der "Aktionen" die Lösung herbeigeführt.

Auf jeden Fall funktioniert mein (WLAN)Netzwerk wieder wie vorher und gewünscht.

Hallo zusammen,

ich habe aktuell ein Problem mit meinen beiden Accesspoint (1x UAP-AC-Pro, 1x UAP-nanoHD).

Beide habe ich vor ca. drei Tagen auf die aktuelle verfügbare Firmwareversion 6.2.49 upgedatet. - So weit, so gut.

Die beiden Updates liefen ohne Problem durch. Nur mittlerweile kommt es vermehrt zu Problemen mit Endgeräten welche via WLAN, sowohl mit 2,4Ghz als auch 5Ghz, angebunden sind.

An der sonstigen Netzwerkinfrastruktur habe ich keine Änderungen vorgenommen.

Die Probleme äußern sich darin, dass weder IoT-Geräte (z.B. Alexa), SmartTVs aber auch Smartphone eine Verbindung aufbauen können. Letztere betrifft es nur sporadisch. Denn nach einem Trennen der WLAN-Verbindung am Smartphone und erneutem Verbinden funktioniert es wieder für eine gewisse Zeit.

In meinem Unifi-Controller (hosted on RaspberryPi) wird mir mittlerweile das komplette Netzwerk nur noch als "gut" angezeigt. Im Gegensatz zu vorher mit "hervorragend" oder "exzellent".

Ebenso werden mir 81 Unregelmäßigkeiten (meistens "Hohe Latenz bei Endgerät ...") und 60 Anmeldungsprobleme ( 4 Timeout/ Fehler bei WPA-Authentifizierung, 56 DHCP Timeout/ Fehler) auf dem Dashboard angezeigt

Ein Downgrade der beiden o. a. APs auf die vorher installierte Version (6.2.44.14098) brachte auch keinen Unterschied. Die angebundenen Endgeräte zeigen ein ähnliches bis gleiches Verhalten.

Muss ich ggf. meine kompletten Unifi-Geräte inkl. Controller einmal "durchbooten" um hier den gewünschten, alten Netzwerkzustand wieder hinzubekommen?

Oder "schwingt" es sich wieder ein und ich muss einfach nur geduldig sein bzw. abwarten?

Ergänzung: Kabelgebundene Endgeräte sind hiervon nicht betroffen. Deshalb schließe ich persönlich die eigentliche, komplette Netzwerkinfrastruktur aus.

Ich bin etwas ratlos momentan, da bis auf die beiden Up- und anschließenden Downgrades nichts verändert wurde.

Für Tipps und Anregungen eurerseits bin ich offen und sehr dankbar!

Vielen Dank

Vielen Dank für Eure Einschätzung, Tipps und Erklärungen!

Wie bereits in meinem Eröffnungspost geschrieben, habe ich ja mittlerweile die Konfiguration geändert und betreibe nun NAS und Client in dem gleichen VLAN.

Übrige Clients (Notebook, Smartphone, etc.) nutzen nur sporadisch die NAS und nehmen auch weiterhin den langsameren Weg, also aus einem anderen VLAN, über die USG. Da hier aber nur Fotos, Videos und/ oder Dateien, allesamt im Megabyte-Bereich, kopiert werden ein zu "verkraftendes" Problem.

Nochmals vielen Dank!

Zitat von noexpand

Was ist das für ein USG? USG-3P? Dann wäre mein erster Tipp, dass es als Router zu schwachbrüstig ist.

Vielen Dank für die Rückmeldung.

Es handelt sich hierbei um eine USG-3P.

Mein Verständnis war eigentlich, dass sie das schon "verkraftet".

Zitat von Peterfido

Die USG hat kein Switch eingebaut. Das heißt, dass alle Pakete von einem VLAN in ein anderes über den einen Anschluss vom Switch zum USG hin und wieder zurück müssen. Der Internetverkehr und evtl. Kommunikation zwischen anderen VLAN s geht da auch noch mit drüber.

Im selben VLAN sprechen die Geräte "direkt" miteinander.

Vielen Dank für die Rückmeldung.

Würde also eine UDM-Pro oder -Pro SE das Ganze anders regeln, weil hier ein Switch "onboard" ist?

Das im gleichen VLAN der Router außenvor ist, ist mir bewusst.

Mir war nur nicht klar, dass die Bandbreite so drastisch abnimmt sobald man von einem ins andere VLAN wechselt.

Wie könnte ich also das Problem oder vielmehr diesen "Engpass" lösen?

Hallo und Guten Abend zusammen,

Ich bin auf ein kleines "Problem" gestoßen und denke dass es mit einer fehlerhaften Konfiguration meiner VLANs in Verbindung mit Firewallregeln zu tun hat. - Vielleicht ist jemandem so etwas schon mal passiert bzw. weiß ggf. Abhilfe?!

Ich betrieb bis gestern eine alte Synology-NAS in einem VLAN mit weiteren zentralen Netzwerkgeräten. Die NAS ist mit 1GBit angebunden. - Nennen wir es mal VLAN (ID 1).

Mein Arbeitsplatz-PC welcher durch die NAS diverse Netzlaufwerke präsentiert bekommt befindet sich, ebenfalls mit 1GBit angebunden, in VLAN (ID 2).

Zugriff über VLAN-Grenzen hinweg, sowie das Routing erledigt meine USG.

So weit, so gut.

Nun habe ich sonst immer kleine Dateien, Dokumente oder Fotos in MByte-Größe von lokal (PC) auf die NAS kopiert und konnte keine Defizite feststellen. Bis ich vergangene Woche ein iso-File kopieren wollte. - Die max. Übertragungsgeschwindigkeit betrug 14 MB/s.

Als erstes hatte ich die NAS oder vielmehr die HDDs in Verdacht, da diese aus dem Jahr 2015 sind, und bin auf SSDs umgestiegen. - Leider das gleiche Problem bzw. die gleiche Übertragungsgeschwindigkeit.

Nun habe ich hin und her überlegt und gepatcht und habe einfach mal die NAS in das gleiche VLAN, wie den Arbeitsplatz-PC geschaltet. - Hier liegen nun Übertragungsgeschwindigkeiten, mit dem gleichen iso-File von 93-94 MB/s an.

Wo habe ich meinen Denk- oder eher Konfigurationsfehler. - Vielleicht könnt ihr hier Denkanstöße liefern? Ich stehe hier auf dem sogenannten Schlauch.

Sollte ich weitere Informationen liefern (müssen) so lasst es mich bitte wissen.

P.S.: Als Hinweis: Bzgl der Firewallregeln, etc. habe ich mich im Großen und Ganzen an die Tipps hier aus der Wiki gehalten

Viele Grüße und schon mal Danke - ssd376

Hallo zusammen,

Ich wollte noch mal ein Feedback zu den beschriebenen Lösungsansätzen von euch geben.

Was soll ich sagen: "Ich hab' Ruh'!"

Die Eintragung des SIP-Providernetzes als Quell-IP-Adressbereich, wie empfohlen, habe ich vorgenommen und es war Schluss mit den ständigen Threat Management Meldungen.

Vielen, vielen Dank nochmals für eure Unterstützung ( maxim.webster und jkasten).

maxim.webster und jkasten

Vielen, vielen Dank für eure Unterstützung und die schnellen Antworten.

Ich habe, wie vorgeschlagen, nun das Netz 212.227.0.0/16 in der Portweiterleitung eingetragen und hoffe nun endlich Ruhe von den ständigen ThreatManagement-Alarmmeldungen zu haben.

Ich werde das Ganze nun 1-2 Tage beobachten und dann (hoffentlich) final berichten.

Also nochmals Danke für eure Hilfe.

Zitat von jkasten

Das Netz von 1und1 ist 212.227.0.0/16

Gestatte mir zwei Nachfragen.

Kannst Du mir sagen, woher Du diese Information hast? Oder machst Du das anhand der von mir genannten IPs (212.227.124.130 und 212.227.124.129) aus?

Zitat von jkasten

Ja korrekt, aber nicht nur auf eine IP sondern auf den Netz Bereich. Welchen Anbieter hast du denn?

Ich bin bei 1&1, und wenn ich das richtig verstehe heißt der Zugang sip.1und1.de.

Ein nslookup auf den Namen liefert mir die IPs 212.227.124.130 und 212.227.124.129.

Wie sollte ich dann das Ganze eintragen? - Laut Controller ist hier nur folgende Eingabe zulässig "Dieses Feld kann eine einzelne IP-Adresse, einen IP-Adressbereich getrennt durch Bindestrich (-) oder ein Subnetz enthalten."

Zitat von jkasten

Kannst du machen, wird aber automatisch geblockt. Du könntest den Port noch auf deinen Anbieter begrenzen, dann hast Ruhe.

"Helf mir mal auf 's Pferd!" - Wie meinst Du das oder anders gesagt, verstehe ich das richtig:

Das ich die VoIP-IP (Provider-/ Anbieterseitig) als Quell-IP eintragen soll, das quasi nur noch von dort die "Zugriffe" erlaubt sind?

Meinst Du den grünmarkierten Bereich?

Sorry für meine Nachfragen.

Hi jkasten,

Danke schon mal für Deine Antwort.

Heute Morgen hatte ich die erste High-Meldung. Ich habe mir dies dann im Traffic-Log rausgesucht und auf Block ausgewählt (siehe Screenshot).

Ist das so das korrekte Vorgehen?

Hallo zusammen,

wie schon in anderen Threads von mir mal dargestellt hatte ich Probleme mit der Fritz!Box-Telefonie via USG/ Draytek-Modem. Es kamen entweder keine Anruf von Extern an, der Anrufende erhielt "...nicht verfügbar" oder es klingelte einfach nicht. Ebenso beim "Rausrufen" dauerte der Verbindungsaufbau ewig.

Daraufhin habe ich meine kompletten VoIP- und Telefoniegeräte in ein separates VLAN getan und eine Portweiterleitung auf die Ports 5060 und 5061 in Richtung Fritz!Box eingerichtet.

Seitdem funktioniert die Telefonie problemlos, so wie es sein soll.

Als weitere Einstellung habe ich auf der USG unter Threat Management das IPS aktiviert und hier (vorerst) alle Kategorien aktiviert.

Seit diesem Zeitpunkt schlagen in unregelmäßigen Abständen Meldungen mit Network Intrusion Blocked mit unterschiedlichen Quellen auf, wie z.B.:

Threat Management Alarm 2: Misc Attack. Signatur ET DROP Dshield Block Listed Source group 1. Von: xxx.xxx.xxx.xxx:50722, auf: yyy.yyy.yyy.yyy:5061, Protokoll: TCP

Ich habe auch das Ganze, also die Portweiterleitung, testweise deaktiviert was zur Folge hatte die Alarme verschwanden aber auch die Telefonie stellte ihre Arbeit ein bzw. funktionierte unzuverlässig wie in der Vergangenheit.

Wie habe ich nun mit den Meldungen umzugehen?

Muss ich mir Gedanken machen oder sollte/ kann ich weitere Schritte seitens meiner Unifi-Konfiguration unternehmen?

Oder kann ich das Ganze "ignorieren" und mich in Sicherheit "wiegen"?

Solltet ihr noch weitere Informationen benötigen, dann lasst es mich wissen.

Vielen Dank schon mal für Eure Unterstützung.

Ich habe hier nachfolgend den Inhalt der config.gateway.json aufgeführt, in der Hoffnung, dass hier ggf. ein zweites paar Augen einen Fehler findet, welchen ich nach mehrmaligem lesen übersehen habe.

{
    "interfaces": {
        "pseudo-ethernet": {
            "peth0": {
                "address": ["192.168.2.2/24"],
                "description": "Zugriff auf FSDIH-Modem (Draytek Vigor 165)",
                "link": ["eth0"]
            }
        }
    },
    "service": {
        "nat": {
            "rule": {
                "5000": {
                    "destination": {
                        "address": ["192.168.2.1"]
                    },
                    "outbound-interface": ["peth0"],
                    "type": "masquerade"
                }
            }
        }
    }
}

Das json-file endet nach der letzten ' } '. Es existiert nicht noch ein CRLF oder ähnliches.

Vielleicht hilft es ja weiter?!

Den vorgeschlagenen statischen DNS-Eintrag habe ich noch nicht ausprobiert.

Also,... ich habe gerade mal ip a auf der USG ausgeführt.

Ich (nicht root) sehe die eingerichteten VLANs, das Gastnetz und auch die PPPoE-Verbindung. Aber nirgendwo die, laut dem json-File, eingerichtete Pseudo-Ethernet-Adresse.

Das json-File habe ich, laut der Anleitung, angelegt und via WinSCP auf den Controller (RaspberryPi) hochgeladen. Dann auf dem Controller umkopiert und die Berechtigung entsprechend gesetzt (unifi:unifi). Im Anschluss habe ich die Konfiguration via Controller auf die USG provisioniert.

Bei mir befindet sich die IP des USG (Gateway-IP) unter der laufenden Nummer 3 und trägt dahinter eth1. Könnte das der "Fehler" sein? - Denn im json-File ist von eth0 die Rede.

Und dann noch eins. Was passiert wenn ich dass bisherige json-File mit einem anderen mit eth1 überschreibe und die USG neu provisioniere, "vergisst" dann die USG die Informationen des alten json-Files?

Oder habe ich irgendwie einen Denkfehler? - Sorry, dass ich so viel Frage. So ganz ist noch nicht der "Groschen" gefallen.

Hallo Razor,

Vielen Dank für Deine Unterstützung!

Das ist korrekt. Der IP-Adressbereich 192.168.2.0/ 24 existiert lediglich zwischen Draytek Vigor 165 <> USG 3P.

Ich habe mittlerweile (fälschlicherweise) wieder die Ursprungskonfiguration hergestellt, da es heute zu immensen VoIP-Abbrüchen kam. Meine Erstvermutung war eine fehlerhafte Konfiguration. Wie sich aber im Laufe des Vormittags herausstellte, war dies ein Problem auf Providerseite. - Also der ganze "Rückbau" umsonst.

Einzig und allein die json-Datei und damit die Konfig mit der Pseudo-Ethernet-Adresse habe ich belassen.

Ich werde aber zeitnah wieder die neue, daher auch der Post, Konfiguration zurückspielen und erneut testen. Dafür werde ich das Modem auch wieder auf die Default-Werte zurücksetzen und erneut so konfigurieren, dass die notwendige VLAN-ID (Provider) in der USG eingestellt wird.

Bezüglich der Firewallregeln:

Ich habe mich, wie bereits erwähnt grob an die hier im Forum geposteten gehalten. Weiterhin habe ich dann explizit die Kommunikation von dem "Büro-PC" mit dem UniFi-Controller bzw. dem kompletten Managementnetz zugelassen. In diesem Management-Netz befinden sich UnifiController, APs, NAS, FritzBox, USG, Switche.

Die übrigen VLANs habe ich für Büro, Beruf, Smarthome und Mobil.

Wie bereits erwähnt funktioniert bei mir auch alles, nur nicht mit dem Hop auf das Draytek-Modem.

Gebe ich den von Dir erwähnten Befehl auf der USG ein, erhalte ich Device "peth0" does not exist.

Führe ich den Befehl direkt nach dem Login durch oder muss ich erst noch Admin-/ Rootrechte haben?

Vielen Dank erstmal an razor für die ausführliche Dokumentation in Bezug auf DSL-MODEM ERREICHEN.

Leider funktioniert es (bei mir) nicht so, wie dort beschrieben?!

Ich habe bei der Pseudo-Ethernet Address 192.168.2.2/24 und bei Destination Address 192.168.2.1 eingetragen. Letztere ist auch die IP meines Draytek Vigor 165. Aber weder ping an die Pseudo- noch an die richtige IP-Adresse gehen durch.

Auch direkt vom Unifi-Controller (hosted on RaspberryPi) ist ein ping nicht erfolgreich.

Ich setze auch die hier beschriebenen Firewallregeln (oder zumindest ähnlich von der Konfiguration her) ein und habe entsprechend eine für den Zugriff "LAN Eingehend" konfiguriert. In der Hoffnung so Zugriff zu erlangen. - Leider vergebens.

Alle Unifi-Geräte sowie der Controller befinden sich im gleichen VLAN. Der "Management-PC" befindet sich in einem anderen VLAN, jedoch ist der Zugriff in das VLAN via Firewallregel gestattet und funktioniert auch problemlos. Nur, wie bereits erwähnt, der "Hop" auf das Modem vor der USG schlägt fehl.

Hat jemand noch einen Tipp oder eine Idee wo ich einen Denk-/ Konfigurationsfehler haben könnte?

Sollten noch irgendwelche Infos benötigt werden, werde ich die versuchen zu liefern.

Schon vorab danke für die Unterstützung.