Beiträge von hoppel118

Aber die verwendeten Protokolle sind bei S1 und S2 dieselben. Kann mir gerade nicht vorstellen, was da anders ablaufen soll.

Evtl. gibts irgendwann mal grundsätzliche Änderungen. Das würde dann nur für S2 gelten und bei S1 bleibt alles wie gehabt.

Gruß Hoppel

Zitat von thghh

Modem nicht UDM!

Alles klar, habe ich übersehen…

Also bei mir läuft das. Allerdings nutze ich es so nicht.

1. Ich vertraue Sonos, weshalb sie genauso wie meine Smartphones/MacBooks/AppleTV/AndroidTV im Main VLAN hängen.
2. Der Verbindungsaufbau zw. der Sonos App und dem Gesamtsystem dauert in unterschiedlichen VLANs 3 Sekunden, während es im selben VLAN 1 Sekunde dauert. Auf jeden Fall wesentlich schneller.

Wenn ich nun bspw. mein Handy per 802.1x bzw. MAC auth in das Management VLAN schiebe, kann ich mein Sonos System trotzdem bedienen (insgesamt 10 Lautsprecher, alle per WLAN verbunden, ohne Sonos Net, außer beim 5.1 System im Wohnzimmer).

Wenn man die Geräte ausschließlich im WLAN betreibt, benötigt man dafür meiner Ansicht nach:

1. die richtigen Firewall Regeln,
2. mDNS im Netzwerk,
3. IGMP Snooping im Netzwerk,
4. Multicast Enhancements im WLAN,
5. (und optional 802.1x MAC auth).

Wenn man Geräte per Ethernet anschließt, muss man sich zusätzlich noch mit STP/RSTP auseinandersetzen. Bin am Überlegen mein Sonos 5.1 im Wohnzimmer per Eth zu verbinden, weil die Sonos Arc nur im 2.4GHz Band mit meinem Wifi funkt. Der 5GHz Adapter der Sonos Arc wird seitens Sonos für die direkte Verbindung zum Sub und den Rears verwendet. Das will ich aber so nicht. Da ich hier eine saubere Kanalplanung habe und in den Sonos Einstellungen nicht festgelegt werden kann auf welchem 5GHz Kanal Sonos diese proprietäre Verbindung herstellen darf. 2.4GHz ist hier ausschließlich für die Hausautomatisierung und alles was dazu gehört vorgesehen.

Warum 802.1x bzw. MAC auth? Man kann die Geräte erstmal an derselben SSID im selben VLAN in Betrieb nehmen und später in der Radius Konfiguration einfach das VLAN der Geräte ändern, so dass ab dem Moment die Trennung erfolgt. Man muss dann nichts mehr an der Sonos WLAN Konfiguration verändern, Geräte transferieren oder Zurücksetzen bzw. neu Einbinden. Grundsätzlich funktioniert dann erstmal alles im selben VLAN und wenn ich weiter daran arbeiten möchte, schiebe ich die Sonos oder mein Smartphone in das andere VLAN und erstelle bspw. Firewallregeln oder teste andere Konfigurationen bis es läuft. Wenn es nicht läuft, werden die Geräte wieder in das andere VLAN geschoben und ich habe keinen Stress.

Das Sonos Gesamtkonstrukt sollte mal jemand im Wiki dokumentieren. Ich würde dabei unterstützen.

Mein Protect hat übrigens auch ein eigenes VLAN, obwohl ich Protect auf der UDM-SE nutze. Ansonsten habe ich separate VLANs für Gäste, IoT (alles was nur mit Cloud funktioniert) und NoT (Network of Things (alles was auch ohne Cloud bedient werden kann). Meine Firewall ist wie im Wiki beschrieben konfiguriert, nichts spezielles würde ich sagen, außer dass ich mehr VLANs habe.

Gruß Hoppel

Nee, das ist kein Script. Das ist ein Cronjob (oder Crontab? Weiß die genaue Bezeichnung gerade nicht.).

Ich habe die Vermutung, dass der Cronjob auch ohne Startscript auf der UDM-SE persistent bleibt.

Wenn nicht, ist er halt nach dem Reboot weg. Dann können wir immer noch das systemd Startscript bauen.

Wir müssen ja erstmal validieren, ob der Befehl „killall -HUP pppd“ auf der UDM-SE überhaupt funktioniert. Ich gehe aber davon aus. Funktioniert ja auf der USG bzw. UDM(-Pro) auch.

Gruß Hoppel

Zitat von thghh

Dann mach es doch so wie es am einfachsten ist. Schaltbare Steckdose für das Modem. Mache ich so für mein Backup LTE Modem am WAN2 Port auch.

Uff, auf der UDM laufen permanent Datenbankaktivitäten. Ich würde das gute Stück niemals einfach so abschalten.

Zitat von jkasten

sven2084 wofür wird der reconnect denn benötigt? Wenn du dich mit Linux so gar nicht auskennst würde ich von solchen Basteleien am Router die Finger lassen. Nicht bös gemeint.

Da hast du irgendwie Recht. Ich bin jetzt auch kein großer Scripter, verwende aber seit fast 20 Jahren im privaten Umfeld irgendwelche Linux Systeme. Von daher sind mir die meisten Abläufe und Befehle irgendwie bekannt. Den Rest verrät mir Google. Wenn man das selbst so nicht beherrscht, ist es fragwürdig am Router auf diese Weise herumzuschrauben.

Aber was kann hierbei schon passieren? Im schlimmsten Fall muss man die UDM neu aufsetzen...

Zitat von sven2084

Es wäre super, wenn wir den reconnect dann irgendwie eingerichtet bekommen.

Moinsen,

ich hoffe, du hast noch nicht angefangen. Ich habe mir darüber gerade nochmal kurz den Kopf zerbrochen. Evtl. geht's sogar viel einfacher.

Schauen wir mal. Mach erstmal ein Backup für den Fall der Fälle.

Wenn die UDM-SE wirklich so persistent ist, wie es bei Github suggeriert wird, dann reicht es evtl. aus einen simplen Cronjob einzurichten.

1. Logge dich als root per SSH auf der UDM-SE ein

Passe die IP-Adresse bei Bedarf an deine Umgebung an:

ssh root@192.168.1.1

2. Testen, ob "killall -HUP -pppd" auf der UDM-SE funktioniert

Logge dich mit zwei weiteren Sessions als root per SSH auf der UDM-SE ein. Du brauchst drei parallele Fenster, um zusehen zu können, was passiert. Sobald du den dritten Befehl ausgeführt hast, wird die PPPoE Verbindung beendet und neu aufgebaut. Das dauert ein Bisschen (vrsl. weniger als eine Minute, ich weiß es nicht genau). In den anderen beiden Fenstern siehst du nun folgendes:

• im ersten Fenster die Logmeldungen dazu live und
• Im zweiten Fenster wird der ping zum Google Server beim Beenden der PPPoE Verbindung unterbrochen und sobald die Verbindung wieder steht, geht auch der ping weiter.

2.1 Gib im ersten Fenster folgenden Befehl ein:

tail -f /var/log/messages

2.2 Gib im zweiten Fenster folgenden Befehl ein:

ping www.google.de

2.3 Anschließend gib im dritten Fenster folgenden Befehl ein:

killall -HUP pppd

tail und ping kannst du beenden indem du das entsprechende Fenster anklickst und auf deiner Tastatur die Tastenkombination "Strg+C" drückst.

Nur wenn dieser Test erfolgreich war, bei Schritt 3 weiter machen. War er nicht erfolgreich, beschreibe bitte was genau passiert ist. Kopiere bitte sämtliche Logausgaben hier in einen Post (Denk dran, deine öffentliche IP-Adresse zu anonymisieren).

3. Gib folgenden Befehl ein (um 3 Uhr morgens wird PPPoE neugestartet):

Achtung: Ab hier nur weiter machen, wenn der vorangegangene Test erfolgreich war!

Wenn du den Cronjob zu einer anderen Uhrzeit starten möchtest, passe die beiden Zahlen vor den drei Sternchen wie folgt an:

0 = Minuten

3 = Stunden

Beispiel (Cronjob wird um 2:30 Uhr ausgeführt): echo "30 2 * * * killall -HUP pppd" > /etc/cron.d/restart_pppoe

echo "0 3 * * * killall -HUP pppd" > /etc/cron.d/restart_pppoe

4. Prüfe nochmal mit "ls -l" die Rechte und die Verfügbarkeit der Datei:

ls -l /etc/cron.d/

Die Ausgabe des vorangegangenen Befehls sollte dann wie folgt aussehen:

Zitat

total 24

-rw-r--r-- 1 root root 77 Feb 2 23:57 fingerprinting

-rw-r--r-- 1 root root 79 Feb 2 23:57 ips-service-signature

-rw-r--r-- 1 root root 68 Feb 2 23:57 redirector_keys

-rw-r--r-- 1 root root 28 Feb 6 00:05 restart_pppoe

-rw-r--r-- 1 root root 396 Apr 6 2019 sysstat

-rw-r--r-- 1 root root 54 Feb 2 23:57 ubnt-report

Alles anzeigen

Das ist wichtig für deinen "restart_pppoe" Cronjob:

Zitat

-rw-r--r-- 1 root root

5. Gib folgenden Befehl ein, um den Cronjob zu laden:

/etc/init.d/cron reload /etc/cron.d/restart_pppoe

Jetzt wartest du bis zum nächsten morgen und prüfst unter /var/log/messages, ob um 3 Uhr morgens (oder was du auch immer konfiguriert hast) deine PPPoE Verbindung beendet und wieder aufgebaut wurde:

cat /var/log/messages

Wenn das geklappt, führst du einen Reboot durch und prüfst wieder am nächsten morgen, ob noch alles funktioniert.

Man könnte das alles natürlich viel schneller testen/umsetzen. Das setzt aber Voraus, dass der jenige der das umsetzen will, weiß was er tut oder der der jenige der fleißig die Anleitung geschrieben hat, Lust hat noch mehr zu schreiben…

Meiner Ansicht nach, ist das so eine sichere Variante.

Viel Erfolg und berichte bitte.

Ich kann das momentan leider nicht testen, da ich "Uptime" brauche (andere Story).

Gruß Hoppel

Moin,

mit dem Script habe ich mich auf meiner UDM-SE bisher noch nicht auseinandergesetzt, brauche ich auch nicht, da ich mittlerweile eine feste IP von meinem Provider erhalte.

Die boostchicken Variante von der UDM-Pro funktioniert so nicht mehr auf der UDM-SE.

Existiert die Cron Datei denn überhaupt? Zeig mal den Output der folgenden Befehle:

ls -l /mnt/data/on_boot.d/10-restart-pppoe.sh
ls- l /etc/cron.d/restart_pppoe

Wenn du nun das boostchicken Paket installiert hast, empfehle dir das erstmal rückgängig zu machen und dich an folgende Anleitung zu halten:

UDMPRO SE · Issue #214 · boostchicken-dev/udm-utilities

Describe the bug Hi just received the UDMPRO SE. I'm not able to get this package to install on it. Wondering if anyone has any ideas? When I SSH into the…

github.com

Wenn du nur einfache Scripte ausführen willst, werden keine zusätzlichen Pakete mehr benötigt. Auf der UDM-SE macht man das einfach per systemd. Wenn die Anleitung bei github bei dir Fragen oder Fehler aufwirft, melde dich nochmal. Bei mir laufen auf diese Art und Weise ein paar Masqueraden.

Wobei der ganze Script Teil eigentlich identisch sein müsste. Bin ich mir gerade unsicher.

EDIT: Schau mal, der Author des zuvor verlinkten Beitrags schreibt folgendes:

Zitat

Make sure there weren't any issues running your scripts because of bash/sh incompatibilities. You might have to tweak some scripts a little for bash syntax.

Das würde ja zu deinem Ergebnis passen:

root@UDM-SE:/mnt/data/on_boot.d# 10-restart-pppoe.sh
-bash: 10-restart-pppoe.sh: command not found

Wenn du das Script selbst nicht an die Gegebenheiten anpassen kannst, brauchen wir jemand anderes der das kann. Davon habe ich auch keine Ahnung. Kriegen wir aber sicherlich notfalls irgendwie hin.

Gruß Hoppel

Hallo in die Runde,

habe auch mal wieder eine Frage. Nachdem ich nun vor fast 2 Wochen meine neue UDM-SE in Betrieb genommen habe, möchte ich mal eine Frage klären. Unter /var/log/messages sehe ich folgende Meldungen:

root@udm-pro-se-basement:~# cat /var/log/messages | tr -d '\000' | grep "BLOCK" 
Jan 22 03:13:19 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=107.189.14.180 DST=111.111.111.111 LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=33090 PROTO=TCP SPT=4885 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 
Jan 22 03:42:58 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=3191 DPT=63687 LEN=9 
Jan 22 05:51:23 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=4658 DPT=61561 LEN=9 
Jan 22 07:29:30 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=3788 DPT=64569 LEN=9 
Jan 22 09:56:07 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=11347 DPT=54043 LEN=9 
Jan 22 13:25:00 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=13009 DPT=63955 LEN=9 
Jan 22 15:27:21 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=33914 DPT=61408 LEN=9 
Jan 22 17:36:52 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=64886 DPT=61682 LEN=9 
Jan 22 19:50:23 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=64300 DPT=64200 LEN=9 
Jan 22 21:13:43 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=27371 DPT=47570 LEN=9 
Jan 23 00:44:22 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=53889 DPT=35000 LEN=9 
Jan 23 03:22:34 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=82 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=TCP SPT=34845 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Jan 23 05:59:59 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=107.189.14.180 DST=111.111.111.111 LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=10157 PROTO=TCP SPT=51858 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 
Jan 23 06:29:55 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=48 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=52632 DPT=53 LEN=28 
Jan 25 16:25:59 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=7805 DPT=35231 LEN=9 
Jan 25 17:49:48 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=50738 DPT=50481 LEN=9 
Jan 28 08:29:21 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=45.61.187.34 DST=111.111.111.111 LEN=44 TOS=0x00 PREC=0x00 TTL=244 ID=54321 PROTO=TCP SPT=45629 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Jan 28 11:07:14 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=39751 DPT=45111 LEN=9 
Jan 29 02:05:13 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=34402 DPT=988 LEN=9 
Jan 29 02:30:39 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=32794 DPT=9001 LEN=9 
Jan 29 03:07:33 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=45.61.187.34 DST=111.111.111.111 LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=631 PROTO=TCP SPT=6313 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 
Jan 29 06:37:29 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=46533 DPT=5093 LEN=9 
Jan 29 07:27:27 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=45.61.187.34 DST=111.111.111.111 LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=57216 PROTO=TCP SPT=49441 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0 
Jan 29 08:41:18 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=9260 DPT=29698 LEN=9 
Jan 29 09:12:00 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=30313 DPT=5098 LEN=9 
Jan 30 05:11:43 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=52923 DPT=64609 LEN=9 
Jan 30 21:42:27 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=22943 DPT=55011 LEN=9 
Jan 30 23:03:52 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=61387 DPT=56919 LEN=9 
Jan 31 01:07:31 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=31121 DPT=56653 LEN=9 
Jan 31 03:18:39 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=26721 DPT=62159 LEN=9 
Jan 31 05:38:51 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=11963 DPT=58847 LEN=9 
Jan 31 07:40:02 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=54824 DPT=58506 LEN=9 
Jan 31 10:05:33 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=6855 DPT=56315 LEN=9 
Jan 31 13:08:44 udm-pro-se-basement kernel: TOR BLOCK: IN=ppp0 OUT= MAC= SRC=144.172.118.37 DST=111.111.111.111 LEN=29 TOS=0x00 PREC=0x00 TTL=240 ID=54321 PROTO=UDP SPT=14513 DPT=55861 LEN=9

Bei der IP-Adresse 111.111.111.111 handelt es sich um meine öffentliche WAN IP-Adresse, die ich hier anonymisiert habe, da sie statisch ist.

Was sind das genau für Meldungen?

Nach außen habe ich eigentlich keine Ports offen, so dass ich solche Meldungen meinem Verständnis nach nicht haben dürfte. Mir macht das ganze etwas sorgen, da dort sehr häufig "ID=54321 PROTO=UDP" aufgeführt wird. (Dort werden zusätzlich auch ein paar TCP Ports aufgeführt, insofern es sich bei der ID um einen Port handelt: 33090 | 10157 | 631 | 57216 | 2x 54321)

Ich habe mir kürzlich nämlich ein paar Masqueraden für einige Xiaomi Devices eingerichtet, die auf UDP Port 54321 kommunizieren. Diese Xiaomi Devices (bspw. Smart Fan) erwarten nun aber, dass sich andere Kommunikationsstellen im selben Netz bzw. Wifi befinden. Es schient sich um ein "Sicherheits Feature" seitens Xiaomi zu handeln, verschiedene Roborock Modelle (bspw. S50) haben dieses Problem nicht, wenn man einen mDNS "Multicast DNS" Reflector an der UDM(-Pro/-SE) aktiviert. Nähere Informationen dazu findet ihr hier: https://github.com/rytilahti/python-miio/issues/422

Mein Smarthome Server und auch meine Smartphones befinden sich in meinem Hauptnetzwerk, während diese Xiaomi Komponenten sich in einem in sich abgeschotteten VLAN befinden (Typ Guest Netzwerk und Device Isolation aktiv). Somit funktioniert die Kommunikation mit diesen Geräten nicht netzintern, sondern nur über die Xiaomi Cloud. Mit den Masqueraden kann ich ich die Kommunikation über die Cloud umgehen und direkt lokal kommunizieren.

Diese Masqueraden sehen wie folgt aus:

iptables -t nat -A POSTROUTING -s YOUR_SMARTHOME_SERVER_IP/32 -d YOUR_DEVICE_IP/32 -p UDP -j MASQUERADE --to-ports 54321

In dieser iptables Masquerade lege ich also fest, dass diese Regel ausschließlich für meinen Smarthome Server und das entsprechende Xiaomi Device angewendet werden soll.

Diese TOR BLOCK Meldungen oben könnte man jetzt so deuten, dass diese Masquerade auch die Firewall nach außen ins Internet öffnet, der UDP Port 54321 also von außen offen ist.

Oder wird die gesamte Xiaomi Kommunikation über die Xiaomi Cloud vom Intrusion Prevention System als TOR Netzwerk erkannt, weshalb diese BLOCKER entstehen?

Handelt es sich beim TOR BLOCK Meldungsfeld "ID=54321" überhaupt um den Port? Evtl. ist das ja auch nur ein Zufall, dass dort hinter der ID die Ziffernfolge 54321 auftaucht.

Oder bin ich hier völlig auf dem Holzweg?

Danke euch und Gruß Hoppel

Sorry, leider habe ich bisher keinen Plan von IPv6 Firewallregeln. Steht auf meiner ToDo-Liste in ferner Zukunft…

Dennoch solltest du wie von razor empfohlen darüber nachdenken, dein KNX in ein NoT (nicht IoT, sondern Network of Things) VLAN zu packen.

Ich habe mein Smart Home wie folgt getrennt:

• Geräte denen ich vertraue - NoT VLAN
• Geräte denen ich nicht vertraue (mit Cloud Zwang) - IoT VLAN

Wie man die entsprechende Firewall dazu aufbaut, ist hervorragend hier im Wiki beschrieben. Im IoT VLAN kannst du dann zusätzlich Network Type Guests bzw. Device Isolation einstellen. Dann können die ganzen Cloud Geräte sich auch untereinander nicht sehen. Du kannst diese Geräte aus deinem Main VLAN aber weiter erreichen, wenn deine Firewall richtig aufgebaut ist.

Gruß Hoppel

Wenn du den Befehlt dafür auf der Command Line herausgefunden hast, ich schätze das geht mit iptables (Vermutung), dann schau dir das an:

UDMPRO SE · Issue #214 · boostchicken-dev/udm-utilities

Describe the bug Hi just received the UDMPRO SE. I'm not able to get this package to install on it. Wondering if anyone has any ideas? When I SSH into the…

github.com

Das ist meiner Ansicht nach sogar viel mächtiger, als die config.gateway.json. Habe mir damit kürzlich ein paar Masqueraden eingerichtet. Das funktioniert super.

Wenn du dabei Probleme hast, kann ich gern unterstützen. Aber den Command Line Befehl musst du selbst herausfinden oder jemand anderes hier unterstützt.

Gruß Hoppel

Ja, ich habe das vorhin auch schon gelesen. Bisher läuft bei mir alles. Ich habe sogar ein Mesh von einem U6-Pro zu einem anderen und dahinter befindet sich dann ein Switch mit einem weiteren U6-Pro.

Anscheinend kann es beim Mesh AP ein Upgrade/Downgrade Problem geben. Wenn ich es richtig verstehe.

Jo, hat mich auch gewundert. Habs trotzdem installiert und jetzt 20h Uptime. Der Tag im Home-Office mit vielen Teams Session von meiner Frau und mir war ohne irgendwas. Fast Roaming läuft, keine IoT Probleme. Mein syslog Server spuckt bisher auch keine merkwürdigen Meldungen aus. Was will man mehr?

Jetzt muss die Stabilität nur noch gehalten werden…

Meine Umgebung

• udm-pro-se: 2.3.11
• network application: 6.5.55
• protect application: 1.20.3
• 1x usw-enterprise-24-poe: 5.76.7
• 1x usw-lite-16-poe: 5.76.6
• 2x usw-lite-8-poe: 5.76.7
• 6x u6-pro: 6.0.10

Gruß Hoppel

Ich habe die PPPoE Zwangstrennung mal für das USG und die UDM Pro im Ubiquiti Forum beschrieben.

USG:

https://community.ui.com/questions/automatic-wan-pppoe-disconnect-after-24-hours-in-Germany-we-call-it-Zwangstrennung/22bb635d-f163-41d1-afa9-639a678000bb#answer/f43328b4-235d-4faf-85d6-7533c23dfe1c

UDM-Pro:

https://community.ui.com/questions/automatic-wan-pppoe-disconnect-after-24-hours-in-Germany-we-call-it-Zwangstrennung/22bb635d-f163-41d1-afa9-639a678000bb#answer/bfdb2384-ba64-4e7a-a03a-9920dd287ed0

Evtl. Kannst du das mit leichten Anpassungen übernehmen. Wenn du die Befehle herausgefunden hast, mit denen man den erneuten Verbindungsaufbau hinbekommt, ist das ohne Probleme machbar.

Bei der UDM-Pro-SE würde es wieder ganz anders ablaufen, als beispielsweise bei der UDM-Pro. Da braucht man das Boostchicken Paket nicht mehr. Man kann ganz einfach per systemctl Scripte persistent starten. Weitere Informationen dazu findet man hier:

UDMPRO SE · Issue #214 · boostchicken-dev/udm-utilities

Describe the bug Hi just received the UDMPRO SE. I'm not able to get this package to install on it. Wondering if anyone has any ideas? When I SSH into the…

github.com

Habe damit gestern auf meiner neuen UDM-Pro-SE ein paar iptables Masqueraden persistent gemacht. Das ist genial und einfach. 10Minuten hat’s gedauert. Die UDM-Pro-SE fühlt sich damit wie ein echtes Debian an.

Bitte auch hier den Feature Request Voten und ggf. in den Kommentaren ergänzen, dass du das auch für DHCP benötigst:

https://community.ui.com/questions/automatic-wan-PPPoE-reconnect-after-a-period-of-time-in-Germany-we-call-it-Zwangstrennung/a4485430-7910-4e94-9b2f-853827e640d1

Gruß Hoppel

Moin,

hast du schonmal probiert, die IP-Adresse, die die UDM-Pro eigentlich von der Fritzbox per DHCP erhält, statisch am WAN Interface der UDM-Pro zu konfigurieren?

Das wäre zwar auch nur ein Workaround, aber vielleicht hast du dann endlich Ruhe.

EDIT: Vergiss das, habe deinen Opening Post gerade nochmal gelesen.

Gruß Hoppel

Hast du schon probiert die Dream Machine auf 7.0.18 zu heben?

Es ist bekannt, dass Sicherung von einem Gerät auf ein anderes nur funktionieren, wenn die selbe Network Application auf Quell und Zielsystem installiert sind.

Handelt es sich um eine UDM Base oder Pro?

Gruß Hoppel

Moin,

jo, habe damit auch Probleme.

Meine Umgebung:

• udm-pro-se: 2.3.11
• network application: 6.5.55
• protect application: 1.20.3
• 1x usw-enterprise-24-poe: 5.76.7
• 1x usw-lite-16-poe: 5.76.6
• 2x usw-lite-8-poe: 5.76.7
• 6x u6-pro: 6.0.4

Bei mir funktionieren folgende Gerätemodelle:

• iPhone 8, XS, XR, SE2 und 13 Pro Max
• älteres Samsung Galaxy
• MacBook Pro Intel 2016

folgende Gerätemodelle funktionieren nicht:

• MacBook Pro M1 2021
• Microsoft Surface Laptop 3

Alle Geräte haben das aktuellste OS installiert. Bei den beiden nicht funktionierenden Geräten handelt es sich um Geräte, die durch unterschiedliche Unternehmen gemanaged werden. Mit WPA2 (PMF=disabled), WPA3 (PMF=required) oder WPA2/WPA3 (mixed mode PMF=optional) funktionieren alle meine Geräte.

Keine Ahnung, woran das liegt. Mir gehts hauptsächlich darum die Geräte über möglichst wenige SSIDs (momentan 3) in viele verschiedene VLANs (momentan 7) zu schieben. Meine Konfiguration habe ich hier im Wiki festgehalten.

Ein User aus dem offiziellen Ubiquiti Forum hat mir den Tip gegeben, dass es evtl. funktioniert, wenn man das WLAN auf WPA2-Enterprise stellt, die betroffenen Clients anmeldet und dann wieder auf WPA3-Enterprise zurückstellt. Bei mir funktioniert das nicht. Das könntet ihr ja mal ausprobieren. Er ist der Meinung, dass es an macOS Monterey liegt. Es ging wohl auch schonmal ohne diesen „Trick“.

Hier noch ein paar interessante Links seitens Apple bezogen auf 802.1x am MAC:

• https://support.apple.com/en-s…ployment/depabc994b84/web
• https://support.apple.com/de-de/HT207431

Hier noch weitere Links, die auf die Ursache hindeuten könnten:

• https://support.microsoft.com/de-de/topic/windows-10-geräte-können-sich-nicht-mit-einer-802-1-x-umgebung-verbinden-179ef277-e6ef-8ea3-cb0e-11a6b80fa955
• https://community.ui.com/quest…3e-4ea1-82fe-ccd43af8557c

Ich habe auch schon ordentlich gegoogelt. Mehr als diese Recherche habe ich in dieser Thematik aber auch noch nicht geschafft. Irgendwie wurmt es mich. Aber mit der im Wiki beschriebenen Radius MACauth Lösung komme ich Workaround-mäßig zurecht.

Lösen möchte ich es aber trotzdem irgendwann.

Gruß Hoppel

Zitat von Tuxtom007

Wenn man sieht, was Unifi mit der neue WebUI verbrochen hat, verzichte ich auf jedes weitere Update gerne.

Das Teil ist doch eine Vollkatastrophe. Wenn bei uns ein Softwareentwickler mit so einer WebUI um die Ecke kommt, wird der in der Luft zerrissen.

Ganz ehrlich, ich finde das neue WebInterface gut, zumindest wenn ich mir vorstelle, was daraus mal werden kann.

Mit Version 7.x der Network Application wird sich auch nochmal einiges positiv an der Menüstruktur verändern.

Ich arbeite persönlich schon seit längerem ausschließlich mit dem neuen WebInterface und das funktioniert.

Die großen Themen, die mir noch fehlen sind:

• Mehr Statistiken im WebUI
• Allgemein mehr Informationen im WebUI (bspw. IPv6)
• Anpassbares Dashboard
• Bessere Aufbereitung bzw. mehr Informationen zur Konfiguration einiger Services (bspw. Radius)
• Persistente Konfiguration auf den UDM Geräten ohne Boostchicken (config.gateway.json, anscheinend geht da was mit der neuen UDM-Pro-SE)

Richtig cool wäre ein frei zugänglicher App Store, so dass Unternehmen und Open Source Entwickler selbständig Apps für alle bereitstellen können. Das würde auch erstmal etwas Last von Ubiquiti nehmen. Dann könnte dort auch sowas wie ein NTP Server oder die zuvor genannten Punkte als App bereitgestellt werden. Der letzte Punkt könnte dann wahrscheinlich entfallen.

Gruß Hoppel

Zitat von Grendelbox

hoppel118 Gerne doch

Sobald ich mal in den Keller komme, klemm ich mal mein Messgerät davor
und zieh den UAP aus der Buchse ~4,5Watt PoE verbrauch aktuell...

Moin Grendelbox ,

ich möchte das Thema nochmal aufgreifen. Der Stromverbrauch interessiert mich immer noch. Ich weiß, dass es lästig ist. Aber es wäre wirklich toll von dir!

Gruß Hoppel

Wo haben die unterschiedliche Softwarestände? Müsste das nicht bei beiden wie folgt sein?

• UDM(-Pro) Firmware: 1.11.0

• UDM-Pro-SE: 2.3.11

• Network Application Firmware 6.5.55

Die Firmware der UDM ist für das von mir oben beschriebene Verfahren auch gar nicht relevant. Wichtig ist nur, dass die alte und die neue Network Application in der gleichen Version (6.5.55) vorliegen.

Das oben beschriebene Verfahren habe ich übrigens auch genauso schon beim Upgrade von USG-3P und Unifi Network Application im Docker Container zur UDM-Pro durchgeführt.

Auch das hat ohne Probleme funktioniert.

Die UDM-Pro-SE muss natürlich erstmal startklar gemacht werden, also alles manuell einrichten, inkl. Internet, bis die Network Application dann startet. Dann kurz, evtl. die Gateway IP im Default LAN an die vorherige Gateway IP anpassen, neu starten und dann das „Nur Einstellungen“ Backup über das WebInterface der Network Application restoren. Fertig!

Hast du evtl. beim Einrichtungsvorgang probiert ein Cloud Backup deiner UDM auf die UDM-Pro-SE zu spielen? Geht das überhaupt?

Ich denke nicht.

Gruß Hoppel

Was hat denn genau nicht funktioniert?

Bei mir war das total problemlos.

Gruß Hoppel