Avaya PBX mit Telekom-SIP-Trunk registriert nicht (mehr)

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
andydld
Beiträge: 71
Registriert: Mi 26.09.2012, 10:10
Wohnort: Haibach
Kontaktdaten:

Avaya PBX mit Telekom-SIP-Trunk registriert nicht (mehr)

Beitrag von andydld »

Hallo Zusammen,

wir haben heute eine RC300 bei einem Kunden aufgestellt und prompt Probleme mit der Telefonanlage bekommen.
Zurvor kam ein LANCOM-Router zum Einsatz und da lief VoIP noch.
Es kommt irgendwas von Avaya zum Einsatz (nicht von uns, mit Avaya kennen wir uns nicht aus) und es wird ein SIP-Trunk von der Telekom verwendet.

Kurios ist, das zwischendurch die Registrierung mal geklappt hat und durchaus eine ganze Weile (gefühlt zwei Stunden) auch mal telefoniert werden konnte.

Meine "üblichen Verdächtigen" in Sachen VoIP und UTM (Module entladen, conntrack, Stateless-Regeln, etc.) habe ich bereits durch:

https://wiki.securepoint.de/UTM/FAQ-VoIP
https://www.andysblog.de/securepoint-utm-telekom-voip-gespraeche-brechen-nach-15-minuten-ab
https://www.andysblog.de/securepoint-utm-und-askoziapbx
https://www.andysblog.de/securepoint-utm-ein-paar-notizen-zu-voip-ueber-vpn-am-beispiel-einer-standortvernetzung

Das half allerdings alles nicht.
Im Moment gibt's wirklich nur eine Portfilter-Regel die alles von der PBX zum Internet zulässt und in der Gegenrichtung alles was sip (udp) und sip (tcp) Richtung PBX zulässt (reine Verzweiflungstat, soll so natürlich nicht bleiben).

Via ssh und als root habe ich dann mal auf der UTM beobachtet was da passiert.
Mit "tcdpdump -i eth1 host 192.168.2.18" sieht man seltsamerweise immer nur DNS-Abfragen der PBX bei der UTM und deren Antwort:

Code: Alles auswählen

15:10:02.492583 IP 192.168.2.18.domain > 192.168.2.1.domain: 13822+ SRV? _sip._tcp.reg.sip-trunk.telekom.de. (52)
15:10:02.492721 IP 192.168.2.1.domain > 192.168.2.18.domain: 13822 3/4/6 SRV d-ipr-a02.edns.t-ipnet.de.:5060 30 0, SRV n-ipr-a01.edns.t-ipnet.de.:5060 20 0, SRV n-ipr-a02.edns.t-ipnet.de.:5060 10 0 (403)
Mit "-vv" gibt's etwas mehr von der DNS-Abfrage:

Code: Alles auswählen

17:07:00.233245 IP (tos 0x0, ttl 99, id 26991, offset 0, flags [none], proto UDP (17), length 80)

Code: Alles auswählen

    192.168.2.18.domain > 192.168.2.1.domain: [udp sum ok] 13731+ SRV? _sip._tcp.reg.sip-trunk.telekom.de. (52)

Code: Alles auswählen

17:07:00.233372 IP (tos 0x0, ttl 64, id 11121, offset 0, flags [none], proto UDP (17), length 431)

Code: Alles auswählen

    192.168.2.1.domain > 192.168.2.18.domain: [bad udp cksum 0x8710 -> 0xe118!] 13731 q: SRV? _sip._tcp.reg.sip-trunk.telekom.de.

Code: Alles auswählen

	3/4/6 _sip._tcp.reg.sip-trunk.telekom.de. SRV d-ipr-a02.edns.t-ipnet.de.:5060 30 0, _sip._tcp.reg.sip-trunk.telekom.de. SRV n-ipr-a02.edns.t-ipnet.de.:5060 10 0, _sip._tcp.reg.sip-trunk.telekom.de. SRV n-ipr-a01.edns.t-ipnet.de.:5060 20 0

Code: Alles auswählen

	ns: telekom.de. NS dns1.telekom.de., telekom.de. NS dns2.telekom.de., telekom.de. NS secondary006.dtag.net., telekom.de. NS pns.dtag.de.

Code: Alles auswählen

	ar: pns.dtag.de. A 194.25.0.125, dns1.telekom.de. A 194.25.225.19, dns2.telekom.de. A 194.25.225.3, secondary006.dtag.net. A 195.244.245.25, pns.dtag.de.

Code: Alles auswählen

	AAAA 2003:40:8000::100, secondary006.dtag.net. AAAA 2a00:fa8:3:0:100:0:6:1 (403)

Scheint erstmal so als ob die PBX die Service Records abfragt (und auch erhält). Viel mehr passiert da irgendwie nicht. Sieht nach meinem aktuellen Kenntnisstand danach aus, als ob die PBX noch nicht mal versucht Richtung Internet geschweigedenn SIP zu gehen. Untermauert wird dieser Eindruck dadurch was ich zum einen mit

tcpdump -i wan0 port 5060

mal geschaut habe ob sich in Sachen SIP da irgendetwas tut (tut es nicht so ganz nebenbei).
PBX und UTM haben wir bereits mehrfach neu gestartet, leider keine Änderung.

Die oben gezeigten Hosts können via DNS aufgelöst werden.
Testweise hatte ich diese sogar mal im Portfilter angelegt und alles zugelassen, ebenfalls keine Änderung.

Als es zwischendurch warum auch immer mal funktioniert hat konnte man mittels tcpdump fleissig die Verbindungen bzw. Pakete sehen.

Der Avaya-Admin vom Kunden ist ratlos und will sich morgen mit seinem Avaya-Partner besprechen, wir haben wiederum ein Ticket beim Securepoint-Support eröffnet bzw. dieser hat mit mir zusammen die UTM mal durchgeschaut.
Es scheint in der Tat wirklich so zu sein, das von der Avaya schlichtweg nur die DNS-Abfragen kommen. Vielen Dank an dieser Stelle für den Support so kurz vor Feierabend!

Ich wollte jetzt einfach mal in die Runde Fragen

[ul]
[li]a) wie denn so die Erfahrungswerte mit Avaya und UTM sind und[/li]
[li]b) vielleicht noch Eine/r 'ne Idee hat woran das Avaya-seitig liegen könnte[/li]
[/ul]

Vielen Dank im Voraus.

Gruß

Andy

andydld
Beiträge: 71
Registriert: Mi 26.09.2012, 10:10
Wohnort: Haibach
Kontaktdaten:

Beitrag von andydld »

Hallo Zusammen,

mal ein kleines Update zu dieser Sache:

Die Avaya läuft jetzt wieder. Ein Supporter hat als DNS den von Google ("8.8.8.8") eingetragen.

Ich glaube nicht, das es am DNS liegt.
Vmtl. hat sich eher der IP-Stack der Avaya irgendwie "verabschiedet" und durch das Neueintragen ist dieser wieder in die Spur gebracht worden.
Untermauert wird dies dadurch, das bei Ping-Test die Avaya (bevor sie wieder lief) nur im LAN geantwortet hat, aber nicht via VPN.
Kaum war der Google-DNS drinnen, klappte auch der Ping vom VPN (Roadwarrior sowie S2S) aus wieder.

Wir gehen der Sacher weiter nach, da es ja so nicht bleiben soll.

Gruß

Andy

Antworten