Nubbler
Firewall sieht gut, jedenfalls wenn die einzigen sind. Wenn du auf der UDM den IVITE siehts sollte su ih auch auf
deinem Mirror Port sehen. Wenn nicht wird er verschluckt oder geht woanders hin. (Fritze noch aktiv) ?
(sofern keine festen Weiterleitungen sollte "cat /proc/net/nf_conntrack | grep 5060“ auf welches ziel das Paket geht.
Steht hier nichts is die Tabelle schon wider gelöscht oder dein Telefon hat sich nicht rechtzeitig wieder refrescht.
Zur not halt die UDP Timeouts auf 15 min setzen, da ist LAAAANGE aber für ein test ganz angenehm)
Alles anzeigen
Also zunächst kam
ipv4 2 udp 17 286 src=192.168.1.5 dst=62.52.28.195 sport=5060 dport=5060 packets=4113 bytes=178301 src=62.52.28.195 dst=77.181.86.52 sport=5060 dport=1024 packets=125 bytes=125800 [ASSURED] mark=0 use=2
ipv4 2 udp 17 295 src=192.168.1.2 dst=62.52.28.195 sport=5060 dport=5060 packets=2751 bytes=115907 src=62.52.28.195 dst=77.181.86.52 sport=5060 dport=5060 packets=27 bytes=17399 [ASSURED] mark=0 use=2
Also erste Zeile ist src das Gigaset, die zweite die Fritzbox
Nachdem ich dann einmal raustelefoniert und danach erfolglos reintelefoniert habe kamen neue Einträge dazu:
ipv4 2 tcp 6 109 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=50604 dport=8080 packets=6 bytes=10266 src=127.0.0.1 dst=127.0.0.1 sport=8080 dport=50604 packets=4 bytes=469 [ASSURED] mark=0 use=2
ipv4 2 tcp 6 105 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=50600 dport=1080 packets=9 bytes=701 src=127.0.0.1 dst=127.0.0.1 sport=1080 dport=50600 packets=9 bytes=15110 [ASSURED] mark=0 use=2
ipv4 2 udp 17 106 src=127.0.0.1 dst=127.0.0.1 sport=35060 dport=53 packets=1 bytes=55 src=127.0.0.1 dst=127.0.0.1 sport=53 dport=35060 packets=1 bytes=55 mark=0 use=2
ipv4 2 udp 17 296 src=192.168.1.5 dst=62.52.28.195 sport=5060 dport=5060 packets=4205 bytes=181740 src=62.52.28.195 dst=77.181.86.52 sport=5060 dport=1024 packets=133 bytes=139109 [ASSURED] mark=0 use=2
ipv4 2 udp 17 274 src=192.168.1.2 dst=62.52.28.195 sport=5060 dport=5060 packets=2813 bytes=119754 src=62.52.28.195 dst=77.181.86.52 sport=5060 dport=5060 packets=37 bytes=33678 [ASSURED] mark=0 use=2
Nach einiger Zeit sind dann wieder nur die beiden Einträge der ersten Abfrage vorhanden.
Um die Firewall kümmern...Nun ja, da bräuchte ich dann schon genaue Handlungsemfehlungen...
Danke für eure Diskussion aber bitte nicht streiten :-).
Bin kurz davor einfach mal die UDM komplett zurückzusetzen und einfach mal alles neu aufzubauen......Wenn es so schwierig ist weiter zu kommen.
Was mich immer noch wundert ist, das die Fritze aktuell nur eine Rufnummer registiert (habe mehrere durch die ISDN Option, wobei aktuell nur noch 2 in Benutzung sind). Aktuell ist hier nur die Hauptnummer auf "grün". EIne der anderen bei der DX800 zu registrieren hat funktioniert.
update:
Lt. google reicht anscheinend eine Rufnummer in der Fritze aus, das diese den Port 5060 abgreift.
Daher konzentriere ich mich nun es rein mit dem DX800 ans laufen zu bekommen. Nicht das die Fritze das irgendwie beeinflußt.
Also alle Rufnummern aus der Fritze gelöscht und neugestartet.
Beide Rufnummern in der DX800 registriert.
UDM Pro neu gestartet.
Nun bringt cat /proc/net/nf_conntrack | grep 5060
ipv4 2 udp 17 610 src=192.168.1.5 dst=62.52.28.195 sport=5060 dport=5060 packets=2 bytes=1048 src=62.52.28.195 dst=77.189.76.161 sport=5060 dport=5060 packets=2 bytes=1132 [ASSURED] mark=0 use=2
ipv4 2 udp 17 712 src=192.168.1.234 dst=217.91.44.17 sport=50606 dport=123 packets=1 bytes=76 src=217.91.44.17 dst=77.189.76.161 sport=123 dport=50606 packets=1 bytes=76 mark=0 use=2
ipv4 2 udp 17 1494 src=192.168.1.5 dst=62.53.165.195 sport=5060 dport=5060 packets=59 bytes=13229 src=62.53.165.195 dst=77.189.76.161 sport=5060 dport=5060 packets=39 bytes=51483 [ASSURED] mark=0 use=2
Also zwei einträge für die DX800.
Den dritten eintrag kann ich mir aber nicht erklären.
192.168.1.234 ist ein raspberry mit Kodi.
217.91.44.17 ist laut nslookup kashra.com
Laut google ein Laden für Akkus.
Ich versteh's nicht mehr, bin raus.