Beiträge von Renek83

    Ja, bei mir habe ich auch an br0 inzwischen IPv6 Adressen. Dort habe ich es die Einstellung auf DHCPv6 belassen.


    Der Unifi Support hat inzwischen auch auf mein Ticket geantwortet, auch wenn es inzwischen bei mir funktioniert. Sie empfehlen auch SLACC zu verwenden und schreiben auch das es schon relevant ist das auch an PPP0 eine IPv6 Adresse anliegt.


    Zitat

    Currently, IPv6 IP is not assigned to the WAN interface, so IPv6 isn't working for the LAN clients as well. First, please upgrade the UniFi OS version on the UniFi Cloud Gateway UDM-Pro to the latest version v3.2.12. Navigate to the UDM-Pro's GUI tab>Application>set the UniFi OS release channel to "Official"; it will give the option to update the UniFi OS version on v3.2.12.


    Now, configure the IPv6 setting in WAN using the SLAAC option and configure the prefix delegation size /56 here. Attached is a screenshot with this email for your reference. Then, in the LAN/VLAN network, configure the IPv6 setting in the prefix Delegation mode. Save the settings. Now, check and see if the internet over IPv6 works.

    Wo ich nun Ipv6 am Laufen habe stoße ich auf neue Probleme. Die Clients verwenden nun teilweise den IPv6 DNS Server, was den PiHole umgeht. Wollte nun mal schauen wie ich dem PiHole Ipv6 beibringe.


    Kann man irgendwo in der Unifi Console sehen welche IPv6 Adressen die jeweiligen Clients haben? In der GUI finde ich keine Spalte dafür. Auch keine Option um analog Ipv4 eine fixe Adresse zu setzten.

    Bin auf dem Official Branch. Mache da immer die neusten Updates. Mit Beta oder EA Versionen habe ich noch nie getestet. Ich kann mir auch irgendwie nicht vorstellen das IPv6 bei Unifi einfach nicht richtig funktioniert. Dafür sollte Unifi doch zu groß sein als das sie sich sowas leisten könnten


    OS v3.2.9

    Network 8.0.28


    Einen Support Request habe ich aber auch noch mal erstellt. Mal sehen was dort kommt.

    Ich habe jetzt noch mal rumgespielt und beim WAN Interface einfach mal auf SLACC umgestellt, Prefix weiterhin auf /56, wie von ISP angegeben. Nun sehe ich auf einmal auch eine IPv6 Adresse in meinem VLAN und auch bei PPP0. Komischerweise bei PPP0 aber mit /64, was ja eigentlich nicht passen kann.


    Journalctl gibt weiterhin den Fehler aus

    Code
    Feb 15 07:16:13 UDM-pro ubios-udapi-server[3033796]: odhcp6c[3033796]: Starting REQUEST transaction (timeout 4294967295s, max rc 10)
    Feb 15 07:16:13 UDM-pro odhcp6c[3033796]: Starting REQUEST transaction (timeout 4294967295s, max rc 10)
    Feb 15 07:16:13 UDM-pro ubios-udapi-server[3033796]: odhcp6c[3033796]: Send REQUEST message (elapsed 0ms, rc 0)
    Feb 15 07:16:13 UDM-pro odhcp6c[3033796]: Send REQUEST message (elapsed 0ms, rc 0)
    Feb 15 07:16:13 UDM-pro ubios-udapi-server[3033796]: odhcp6c[3033796]: Got a valid REPLY after 13ms
    Feb 15 07:16:13 UDM-pro odhcp6c[3033796]: Got a valid REPLY after 13ms
    Feb 15 07:16:13 UDM-pro ubios-udapi-server[3033796]: odhcp6c[3033796]: Server returned IA_PD status 'No Address Available (No addresses have been assigned)'
    Feb 15 07:16:13 UDM-pro odhcp6c[3033796]: Server returned IA_PD status 'No Address Available (No addresses have been assigned)'
    Feb 15 07:16:13 UDM-pro ubios-udapi-server[3033796]: odhcp6c[3033796]: IA_PD 0001 T1 1800 T2 2880
    Feb 15 07:16:13 UDM-pro odhcp6c[3033796]: IA_PD 0001 T1 1800 T2 2880


    Die Geräte scheinen aber nun eine IPv6 Adresse zu bekommen. Test vom iPhone war schon mal erfolgreich.


    Danke, hatte das Manuel nicht gelesen. Das erklärt die Traces.


    Es funktioniert aber nun. Lag dann wohl bloß am falschen WLAN Namen in der Fritz Fon App.


    Habe nun auch noch zuvor gesetzte Einstellungen auf der Udm zurückgenommen. Upnp wieder deaktiviert und Firewallregeln entfernt.


    Nur die Portweiterleitung für Port 5060, von den vom Provider genannten Sip Servern zur Fritzbox, habe ich belassen. Weiterhin die State Timeouts auf 600 Sekunden.

    Client (aktuell iPhone meiner Frau) ist im selben Netz. Testanruf von ihr ausgehend über FritzFon App geht auch. Das komische ist, ich habe ja wie im Screenshot zu sehen auf die IP der FB gefiltert. Da ist kein weiterer Traffic aufgezeichnet. Ich hätte erwartet das ich dort nun sehe das er eine Verbindung mit der Client IP aufbaut.


    Die 200 Ok und ACK Pakete sehe ich auch im sngrep Trace wenn ich warte bis der AB das Gespräch annimmt. Hab irgendwie das Gefühl die FB findet das Zielgerät mit der Fonapp nicht. Leider kann ich gerade vom remote nicht auf das Protokoll der FB schauen, falls da überhaupt etwas erscheint.


    Was ich auch komisch finde - ich habe jetzt noch mal einen Trace erstellt mit tcpdump -w sip.pcap, also ohne auf ein bestimmtes Interface eingeschränkt. Diesmal gewartet bis der AB rangeht. Komischerweise taucht im dem Trace nicht die IP der Fritzbox auf.



    --------------------------------------


    Habe gerade noch diesen Hinweis bei AVM gefunden. Das könnte noch passen. Wenn ich bei mir in die App schaue steht in der Einstellung aktuell WLAN-Funknetze: Fritz!Box 7490, das ist aber nur der Name der FB, nicht unsere WIFI SSID.



    So, kaum richtig eingerichtet funktioniert es auch :smiling_face:


    Muss man erst mal drauf kommen, dass diese App per Default meint man ist im Wlan der FB, obwohl diese gar kein Wlan ausstrahlt, sondern nur IP-Client ist.

    Der Trace hat mir noch nicht viel weitergeholfen. Auch hier sehe ich das der Anruf eingeht (192.168.1.147 ist die Fritzbox)



    Die Fritzbox meldet dann auch den Status Ringing zurück an den Anrufer, aber weiter sehe ich nichts im Trace. Ich erkenne jetzt nicht welche Daten gesendet werden um über Callkit die FritzFon App anzusprechen.


    Es gibt keine weiteren Geräte, die die Nummer registrieren. Sie ist nur auf der Fritzbox eingerichtet. Andere Geräte ide Port 5060 nutzen wären mir jetzt keine bekannt. Im Trace taucht der Port auch nur in Verbindung mit dem Anruf auf.

    Ich hatte es vorhin noch auf 600 Sekunden gestellt. Hatte nichts geändert. Sobald ich 1-2 Min warte nach dem ausgehenden Anruf, geht eingehend schon nichts mehr. Ich glaube daher nicht das es am Sessiontimeout liegt. Eigentlich sollte die Fritzbox ja auch schon alle 30 Sek. ein Keepalive schicken.


    Ich muss mir noch mal ein Dect Telefon besorgen. Würde mich interessieren ob es damit geht und es dann nur ein Problem bei Verwendung der Fritz Fon App gibt.

    Hier noch der Output (Extended bzw. Raw) von sngrep. Ich werde daraus nicht wirklich schlau.



    Es kommt erst dann ein Acknowledge wenn der AB rangeht.


    Wie kann ich prüfen ob die Invites bei der Fritzbox ankommen?

    das Thread Management ist nicht Dynamisches wenn es anschlägt und die Automatisiert was blockt dann siehst du eine

    Regeln in der Firewall einstellungen.


    Wie meinst du das genau? Ist das Thread Managment nur aktiv wenn ich eine solche FW Regel sehe? Ich habe keine solche Regel, aber ich sehe auch keine Einträge unter System Log -> Security Detections. Dort hätte ich gedacht sehe ich auch wenn die FW eingehende Verbindungen blockieren würde.


    Sngrep habe ich schon mal installiert. Testen muss ich das heute Abend.

    Hallo zusammen,


    auch wenn dieser Thread schon etwas älter ist scheint mein Thema hier rein zu passen.


    Ich habe Probleme die Internettelefonie per Fritz Fon App ans Laufen zu bekommen.


    Die Fritzbox hängt als reiner IP-Client für VOIP an meiner UDM Pro. VOIP ist in der Fritzbox konfiguriert und läuft grundsätzlich. Wir möchten als Telefon rein unsere Handys mit Fritz Fon App verwenden. Fritzbox und Handys sind im selben VLAN.


    Ausgehende Anrufe funktionieren problemlos. Eingehende Anrufe nur sporadisch. In der Regel dann, wenn kurz nach einem ausgehendem Anruf wieder raus telefoniert wird. Das war gestern auch der einzige Test den ich mehrfach wiederholt habe. Es scheint als wenn auch bei mir irgendwo ein Problem damit besteht die Anrufe von extern intern zur Fritzbox zu routen.


    In der FB habe ich die typischen Einstellungen gesetzt, inkl. dem Haken für Portweiterleitung offen halten auf 30 Sek. In der UDM habe ich schon diverse Dinge getestet. Folgendes ist aktuell eingerichtet:


    - Port Forwarding für Port 5060 und noch einen Port für STUN von WAN auf Fritzbox, eingeschränkt auf die Netze die der Anbieter Epcan für seine SIP Server beschreibt


    - Conntrack Modules: SIP rausgenommen

    - State timeouts für UDP Stream und UDP others auf 300 Sekunden gesetzt



    - Firewall Regeln für Internet und LAN für die vom Anbieter genannten Server, plus den, den ich bei Tcpdump sehe, gesetzt.



    Wie ich gelesen habe sollten Firewallregeln und Conntrack Modules eigentlich keine Rolle spielen. Es macht bisher auch keinen Unterschied ob ich diese Einstellungen gesetzt habe oder nicht.


    Folgende tcpdump Traces habe ich bekommen:


    Ausgehender Anruf - funktioniert immer

    Eingehender Anruf - direkt nach Auflegen des vorherigen Anrufes. Anruf erfolgt von dem zuvor angerufenem Mobilgerät. Hat funktioniert.

    Code
    root@UDM-pro:~# tcpdump -n -i ppp0 port 5060
    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
    listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
    20:44:49.194122 IP 130.255.125.86.5060 > 149.50.183.132.5060: SIP: INVITE sip:[email protected]:5060;uniq=FD399BB83F08E47670A3109ABD87EE0 SIP/2.0
    20:44:49.229563 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 100 Trying
    20:44:49.257568 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 180 Ringing
    20:44:56.363051 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 200 OK
    20:44:56.639539 IP 130.255.125.86.5060 > 149.50.183.132.5060: SIP: ACK sip:[email protected]:5060;uniq=FD399BB83F08E47670A3109ABD87EE0 SIP/2.0
    20:45:00.189810 IP 130.255.125.86.5060 > 149.50.183.132.5060: SIP: BYE sip:[email protected]:5060;uniq=FD399BB83F08E47670A3109ABD87EE0 SIP/2.0
    20:45:00.210040 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 200 OK

    Eingehender Anruf - kurze Zeit später. Wird nicht durchgestellt. Freizeichen aber es klingelt nichts

    Code
    root@UDM-pro:~# tcpdump -n -i ppp0 port 5060
    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
    listening on ppp0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
    20:46:08.712920 IP 130.255.125.86.5060 > 149.50.183.132.5060: SIP: INVITE sip:[email protected]:5060;uniq=FD399BB83F08E47670A3109ABD87EE0 SIP/2.0
    20:46:08.750036 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 100 Trying
    20:46:08.760601 IP 149.50.183.132.5060 > 130.255.125.86.5060: SIP: SIP/2.0 180 Ringing

    Kann ich irgendwo erkennen ob das Thread Management etwas blockiert?


    Hier noch ein paar technische Informationen meines Anbieters.

    SIP-Trunk-Konfigurationshinweise_1-3.pdf


    Gurß

    René

    Ok, dann ist es soweit ja erst mal normal das unter ppp0 keine IPv6 Adresse auftaucht.


    Woran erkenne ich denn ob SLAAC oder DHCPv6 nicht funktionieren im WAN? Im Journal protokolliert er ja eine Adresse.


    Ist die Range ::2 bis ::7d1 am Interface so korrekt? Ich bin nicht so bewandert was IPv6 angeht. Die Range hat die UGM automatisch vorgeblendet. Keine Ahnung ob das zur Adresse passt die über WAN geliefert wird.


    Müssten sich Änderungen in der Webgui direkt auswirken oder muss ich dazu die Box komplett neu starten? Hatte es bisher nur mit "sudo systemctl restart unifi" versucht.

    Hallo,


    ich versuche eine IPv6 Verbindung mit meinem Provider Epcan hinzubekommen. Habe mir diverse Threads durchgelesen. Mein Prefix vom Provider ist /56. Diesen habe ich entsprechend am WAN Interface hinterlegt.



    Ich sehe an ppp0 allerdings noch keine gültige IPv6 Adresse. Müsste dort nicht schon eine auftauchen?


    Code
    36: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN group default qlen 3
    link/ppp
    inet 149.xxx.xx.xxx peer 130.255.xxx.xxx/32 scope global ppp0
    valid_lft forever preferred_lft forever
    inet6 fe80::e87a:54e0:1e9b:1db5 peer fe80::a67b:2cff:feb3:2601/128 scope link
    valid_lft forever preferred_lft forever



    Im journalctl sehe ich scheinbar schon eine korrekte Adresse, allerdings wird diese scheinbar nicht im Netzwerk verwendet.

    2a04:9740:12f:5600::/56



    Egal wie ich IPv6 auf meinem VLAN einstelle, es ist keine Adresse verfügbar.


    Code
    root@UDM-pro:~# ip address show br0
    15: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether da:b3:70:2e:ec:66 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 scope global br0
    valid_lft forever preferred_lft forever
    inet6 fe80::d8b3:70ff:fe2e:ec66/64 scope link
    valid_lft forever preferred_lft forever



    Hat noch jemand einen Tipp? Ich habe mich jetzt mal diesem Thread angeschlossen da dieser der aktuellste für die Thematik zu sein scheint.


    VG

    René



    Hallo,


    ich habe auch Probleme nach Einrichtung von Wireguard auf Internet oder interne Ressourcen zuzugreifen. Wireguard habe ich schon mehrfach neu eingerichtet. Das Log zeigt einen Handshake Fehler.


    2024-01-12 11:38:08.757289: [NET] peer(SsuB…9Mn4) - Handshake did not complete after 5 seconds, retrying (try 2)

    2024-01-12 11:38:08.757637: [NET] peer(SsuB…9Mn4) - Sending handshake initiation


    Ich betreibe eine UDM pro hinter einem Telekom Speedport. Wireguard ist auf Port 51280 konfiguriert und der Port ist im Telekom Router weitergeleitet.



    [Interface]

    PrivateKey = xxxxx

    Address = 192.168.4.2/32

    DNS = 192.168.1.17


    [Peer]

    PublicKey = xxxxx

    AllowedIPs = 192.168.4.1/32,192.168.4.2/32,0.0.0.0/0

    Endpoint = mydomain.de:51820


    OS und Network App sind auf der aktuellsten Version.


    Gruß

    René

    Moin Renek83

    Ich weiss hört sich erstmal Blöd an, weil die IP des GATEWAY ist meist dieselbe wie die für den DNS. Aber DNS wird ja nur zur Adressaulösung gebraucht und ist ein anderes Protokoll. Dieses funktioniert trotzdem obwohl das Gatway selber nicht erreichbar ist oder sein soll.

    Eine DNS Adresse kann aber auch eine ganz andere sein, wie die von einem Pihole oder so.

    Hi, dazu habe ich mal eine Frage. Die Regel besagt ja konkret Port = ANY, das heißt für mich auch Port 53 und damit auch DNS. Ich sehe an der Regel nicht das diese nur ein bestimmtes Protokoll umfasst. Einen PiHole habe ich auch laufen als Gateway, allerdings nur im Haupt Netz und nicht im IOT und Gäste Netz. Daher habe ich dafür keine Regel angelegt.


    Mein Problem ist letztendlich auch das scheinbar bestimmte Blocks nicht im Firewall Log (ich nehme an das ist das unter "Triggers") auftauchen, sonst könnte ich explizite Regeln dafür anlegen. Am Beispiel vom Local Tuya Add-on im Home Assistant scheint es ja so zu sein das "Vlan to Vlan" Traffic blockiert, der notwendig ist um die Devices zu finden. Ich könnte jetzt testen ob es noch eine Regel für Home Assistant -> IOT bedarf, was aber eigentlich nicht notwendig sein sollte, wenn der Home Assistant selbst in dem Vlan ist. Wäre halt alles Try&Error.