SIP-Leitung / IPv6 / 10.80.0665-RU6

[SunSeb]

Liebes Forum,

ich habe ab der Version 10.80.0665-RU6 Probleme mit einer SIP-Leitung. Konkret geht es darum, dass einkommende INVITES geblockt werden, wenn die Kommunikation mit dem Registrar über IPv6 läuft (hier sipgate.de). Ausgehende Gespräche sind weiterhin möglich; auch die Registrierung läuft ohne Probleme. Aufgrund der o.g. Problematik sind eingehende Gespäche ca. 10min. nach reboot nicht mehr möglich.

Wurde etwas an der Firewall geändert bzw. hat jemand ähnliches beobachtet? Mit der 10.80.0594-RU5 läuft es ohne Probleme.
Gerät ist ein 1900EF.

Gruss und schönen Tag,
Sebastian

[Dr.Einstein]

Hallo Sebastian,

nutzt du unter SIP Leitungen / Sicherheit / SIP-Nachrichten nur vom Registrar erlauben? Wenn ja, probiere mal ohne diese Funktion. Auch wenn nichts in den Release Notes steht, probiere testweise die 10.80RU7 aus.

[SunSeb]

Hallo Dr.Einstein,

vielen Dank für den Hinweis. Mit der 10.80.0741-RU7 und deaktivierter Funktion SIP-Nachrichten nur vom Registrar erlauben funktioniert die eingehende Signalisierung wieder!
Da ist wohl noch ein kleines Problem

Schönen Tag und Gruss
Sebastian

[Dr.Einstein]

Oder seit der RU6 funktioniert der Punkt auch bei IPv6? Hast du das mal getract, ob sich die IP-Adresse des SIP Providers ändert?

[SunSeb]

Ich habe mir das nochmal etwas genauer angeschaut. Und du hast völlig recht. Sipgate ändert hier (loadbalancing etc.) die IP-Adresse. Nach einem REGISTER mit [2001:ab7::2] kommt das INVITE von der [2001:ab7::3] und schlägt dann fehl.
Ich muss noch mal schauen, wie das bei IPv4 geregelt ist. Ausserdem frage ich mich, ob die RU6 da weniger empfindlich ist...

[Dr.Einstein]

Ich empfehle dir, eine Anfrage an Sipgate zu stellen. Im Grunde ist das ein Sicherheitsproblem, da du nun ankommenden Anfragen von allen möglichen Quellen erlauben musst. Wenn Sipgate bei v4 alles die gleiche IP hat, solltest du überlegen, auf v4 aufgrund des Sicherheitsgewinns zu wechseln.

Schade aber, dass die Release Notes von Lancom wieder völlig unzureichend sind.

[tobiasr]

Ggf. könnte der Filter im Lancom konfigurierbar aber auch ein ganzes Netz erlauben? Gerade das ist ja ein großer Vorteil von IPv6, dass jetzt endlich jeder Host eine eigene IP haben kann.

[Dr.Einstein]

Da gebe ich dir Recht. Die Serverarchitektur hinter einer IPv6-Adresse zu verstecken macht keinen/wenig Sinn. Kann man nur hoffen, dass der VoIP Entwickler von Lancom hier mitließt und das ebenfalls so sieht und ggf. anpasst. Die Inbound IPv6 Firewall ist hier denke ich nicht zu gebrauchen, da man dort nicht die passenden Namen mit dem Präfix kombinieren kann.

[SunSeb]

Folgenden Trace-Schnipsel gibt es im Callmanager-Trace

Code: Alles auswählen

[Callmanager] 2024/08/29 14:53:58,900 [SIPGATE Registrar Transport]: (Re)Starting with domain name "sipgate.de"
[Callmanager] 2024/08/29 14:53:58,900 [SIPGATE Registrar Transport]: Build observer with m_DnsKey: <, Tag 0>, String in m_DnsKey is empty
[Callmanager] 2024/08/29 14:53:58,900 [SIPGATE Registrar Transport]: m_spDnsObserver is valid
[Callmanager] 2024/08/29 14:53:58,900 [SIPGATE Registrar Transport]: cSipLineTransport::Start  - m_DnsKey: <_sip._udp.sipgate.de, Tag 0>
[Callmanager] 2024/08/29 14:53:58,927 [SIPGATE Registrar Transport]: DnsUpdate - SipLineTransport(07fd8a50) - is_auto: 0, is_initial: 1, is_sp_cache: 1, is_fallback: 0, DnsIndex: 0
[Callmanager] 2024/08/29 14:53:58,927 [SIPGATE Registrar Transport]: IsValidNotification -  target_name: sipgate.de, dns_name: sipgate.de, line's routing tag: 0, event's routing tag: 0
[Callmanager] 2024/08/29 14:53:58,928 [SIPGATE Registrar Transport]: DnsUpdate - SipLineTransport(07fd8a50) - m_State: 3, Time since (Re)Start: 0 seconds, m_spTransport: 00000000
[Callmanager] 2024/08/29 14:53:58,928 [SIPGATE Registrar Transport]: Got valid IP address from DNS cache
[Callmanager] 2024/08/29 14:53:58,928 [SIPGATE Registrar Transport]: remote port from dns: 5060, set remote port: 0
[Callmanager] 2024/08/29 14:53:58,928 [SIPGATE Registrar Transport]: New transport endpoint is [2001:ab7::1]:5060, transport state is "Disconnected"
[Callmanager] 2024/08/29 14:53:58,928 [SIPGATE Registrar Transport]: MakeRegistrarTransport with type 0
[Callmanager] 2024/08/29 14:53:58,928 [SIPGATE Registrar Transport]: SipLineTransport(07fd8a50) - IP Transport ready

Hier scheint auch noch eine DNS-Auflösung eine Rolle zu spielen. Ist die DNS-aufgelöste Adresse denn nun die vertrauenswürdige oder die, die bei der REGISTRierung zum Einsatz kam. Beide müssen ja bei zeitlichem Unterschied nicht gleich sein...

[SunSeb]

noch ein Nachtrag:
man könnte als vertrauenswürdige Registrare alle Adressen nehmen, die in dem AAAA-record der DNS-Anfrage zurückgeben werden. Dann bräuchte man kein ganzes Netz freigeben und wäre trotzdem flexibler...

[Dr.Einstein]

Du meinst den SIP DNS SRV Record, aber auch das wäre nicht 100%. Das Invite kann ja trotzdem von einer anderen Adresse aus kommen. Das sind ja nur die Register IPs.

[awi]

Hallo zusammen,

ist es tatsächlich so, dass das INVITE von einer Adresse kam, die nicht bei der SRV/AAAA Auflösung dabei war?
Eigentlich sollte es so sein, dass SIP Requests von allen aufgelösten Adressen akzeptiert werden.
Falls dem nicht (mehr) so ist, dann ist da möglicherweise etwas kaputt gegangen.
Ist denn ein Trace mit der kompletten SRV- und AAAA-Auflösung vorhanden und auch mit dem eingehenden INVITE?

Falls nicht, kann das ggf. nochmal getraced werden? (Sip-Packet, Callmanager, Sip-Connection, VCM-DNS, Dns)

Gruß
Awi

[SunSeb]

Hallo Awi,

ich hatte später auch mit der Einstellung

Code: Alles auswählen

Strict-Mode: Nein

Probleme mit der Erreichbarkeit. Aus Zeitmangel hatte ich die Leitung dann einfach auf Ipv4?4 gelegt. Ich habe jetzt noch einmal auf IPv6 umgestellt und werde im Fehlerfall einen Trace erstellen. Leider dauert es manchmal 2-3 Tage, bis sich das Fehlerbild zeigt.

Gruss und Danke
Sebastian