Es ist nun eine Woche her das mir folgendes passiert ist:

Bei einem Kunden wurde ein LANCOM-Router der durch die Deutsche Telekom gestellt wurde durch eine Securepoint UTM RC300 ersetzt. Kurz nach dem Tausch kam dann das erste Feedback, dass das Telefon nicht mehr funktionieren würde. Dieser Kunde hat eine Avaya IP Office-PBX im Einsatz (nicht von aus, ich kenne mich damit nicht aus und habe mit dieser Anlage auch nichts zu tun).

Der erste Gedanke war natürlich das es am Portfilter liegen könnte, allerdings war zu diesem Zeitpunkt alles quasi noch auf Durchzug (Any-Regeln) gestellt, da im ersten Schritt der Kunde zunächst wieder online und erst im Nachgang Schritt-für-Schritt die Sicherheit hochgeschraubt werden sollte.

Dem Avaya-Admin fiel zunächst auf, das der SIP-Trunk bei der Deutschen Telekom nicht mehr registriert. Um der Sache auf den Grund zu gehen hatte ich mich mittlerweile per ssh als root mit der Securepoint UTM verbunden um mir mittels tcpdump anzusehen was da verkehrstechnisch passiert, nachdem im Log nichts zu finden war.

Hier zeigte sich schnell, das die Telefonanlage lediglich DNS-Abfragen gegenüber der UTM tätigte, sonst passierte nichts weiter:

tcpdump -i eth1 host 192.168.2.18
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:45:41.053710 IP 192.168.2.18.domain > 192.168.2.1.domain: 13705+ SRV? _sip._tcp.reg.sip-trunk.telekom.de. (52)
11:45:41.053843 IP 192.168.2.1.domain > 192.168.2.18.domain: 13705 3/4/6 SRV n-ipr-a01.edns.t-ipnet.de.:5060 20 0, SRV d-ipr-a02.edns.t-ipnet.de.:5060 30 0, SRV n-ipr-a02.edns.t-ipnet.de.:5060 10 0 (403)
11:46:11.073928 IP 192.168.2.18.domain > 192.168.2.1.domain: 13706+ SRV? _sip._tcp.reg.sip-trunk.telekom.de. (52)
11:46:11.074070 IP 192.168.2.1.domain > 192.168.2.18.domain: 13706 3/4/6 SRV d-ipr-a02.edns.t-ipnet.de.:5060 30 0, SRV n-ipr-a02.edns.t-ipnet.de.:5060 10 0, SRV n-ipr-a01.edns.t-ipnet.de.:5060 20 0 (403)

Wie man sieht fragt die Avaya nach den Service Records für den SIP-Trunk und bekommt sogar eine Antwort, das Ganze wiederholt sich dann endlos, es finden keine weiteren Anfragen statt. Man kann das Ganze zudem mit mehr Details beobachten, das Ergebnis sieht dann wie folgt aus:

tcpdump -i eth1 host 192.168.2.18 -vv

17:07:00.233245 IP (tos 0x0, ttl 99, id 26991, offset 0, flags [none], proto UDP (17), length 80)
192.168.2.18.domain > 192.168.2.1.domain: [udp sum ok] 13731+ SRV? _sip._tcp.reg.sip-trunk.telekom.de. (52)

17:07:00.233372 IP (tos 0x0, ttl 64, id 11121, offset 0, flags [none], proto UDP (17), length 431)
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.
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
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.
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.

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

Soweit wie ich es beurteilen kann ist alles da. Um sicher zu gehen, das in Sachen VoIP einem nichts durch die Lappen geht zusätzlich noch mit

tcpdump -i wan0 port 5060

geschaut. Das Ganze zusätzlich zudem mit dem eth1-Internface (LAN) wiederholt, bei beiden gähnende Leere. Die Avaya versucht noch nicht mal irgendetwas zu registrieren.

Per Zufall bzw. weil dies Teils des Projekts war fiel dann von einem neuen entfernten Standort (S2S) auf, das die Telefonanlage zudem nicht auf Ping-Anfragen (icmp-echo-request) reagiert. Im lokalen Netz klappt das noch, aber sobald irgendwie Routing ins Spiel kommt ist Feierabend.

Auch das lies sich wunderbar per tcpdump beobachten:

Ping-Test via VPN (keine Antwort von der PBX):

13:22:17.219406 IP 10.1.1.250 > 192.168.2.18: ICMP echo request, id 1, seq 150, length 40
13:22:22.173170 IP 10.1.1.250 > 192.168.2.18: ICMP echo request, id 1, seq 151, length 40
13:22:27.162525 IP 10.1.1.250 > 192.168.2.18: ICMP echo request, id 1, seq 152, length 40
13:22:32.166314 IP 10.1.1.250 > 192.168.2.18: ICMP echo request, id 1, seq 153, length 40

Ping-Test Lokal/LAN:

13:24:29.670160 IP 192.168.2.1 > 192.168.2.18: ICMP echo request, id 48401, seq 0, length 64
13:24:29.673185 IP 192.168.2.18 > 192.168.2.1: ICMP echo reply, id 48401, seq 0, length 64
13:24:30.670179 IP 192.168.2.1 > 192.168.2.18: ICMP echo request, id 48401, seq 1, length 64
13:24:30.673078 IP 192.168.2.18 > 192.168.2.1: ICMP echo reply, id 48401, seq 1, length 64
13:24:31.670202 IP 192.168.2.1 > 192.168.2.18: ICMP echo request, id 48401, seq 2, length 64
13:24:31.672980 IP 192.168.2.18 > 192.168.2.1: ICMP echo reply, id 48401, seq 2, length 64
13:24:32.670227 IP 192.168.2.1 > 192.168.2.18: ICMP echo request, id 48401, seq 3, length 64
13:24:32.671892 IP 192.168.2.18 > 192.168.2.1: ICMP echo reply, id 48401, seq 3, length 64
13:24:33.670250 IP 192.168.2.1 > 192.168.2.18: ICMP echo request, id 48401, seq 4, length 64
13:24:33.672798 IP 192.168.2.18 > 192.168.2.1: ICMP echo reply, id 48401, seq 4, length 64

Da machte sich dann Ratlosigkeit breit. Also mit dem Securepoint-Support in Verbindung gesetzt, dieser bestätigte dann den Verdacht bis hierhin das die Avaya

• a) nur DNS-Abfragen vornimmt und
• b) kein Routing mehr macht bzw. nicht mit dem Gateway kommuniziert.

Der Vollständigkeit halber sei erwähnt, das wir in der Zwischenzeit schon mehrfach alles neu gestartet hatten, ohne das sich irgendetwas geändert hat. Dem Avaya-Admin fiel zudem auf, das die Anlage versuchte den Trunk gegenüber “pns.dtag.de” also der IP-Adresse “194.25.0.125” und weiteren zu registrieren, also quasi alle möglichen Telekom-Server abklapperte außer die eigentlichen für den SIP-Trunk zuständigen. Interessanterweise sah man davon nichts via tcpdump. Das Klang dann danach, das diese Anfragen die Anlage schon gar nicht verlassen haben, folglich irgendetwas intern schon falsch abbiegt.

Ein Vorschlag von mir an den Avaya-Admin war dann, doch mal die IP-Konfiguration in der PBX neu einzutragen, in der Hoffnung das dies den wie auch immer gearteten Knoten löst. Durchgeführt wurde dies leider nicht. An dieser Stelle war ich dann zunächst raus, da wie bereits erwähnt ich mit Avaya nichts zu tun habe.

Gute 24 Stunden später meldete sich dann vom Telefonanlagen-Lieferanten der Support beim Kunden-eigenen Avaya-Admin. Der Erzählung nach schaute man sich das Ganze an und änderte letztlich den DNS-Eintrag in der Telefonanlage von der IP-Adresse der UTM auf den Google-DNS-Server “8.8.8.8”. Daraufhin registrierte die Anlage den SIP-Trunk und sie reagiert auch wieder auf Pings von außerhalb des LANs. Kurzum: Es läuft wieder.

Via tcpdump kann man zudem, wenn gerade ein Gespräch geführt wird, ebenfalls mehr “Leben” sehen:

...
13:39:20.472452 IP <Hostname>.dip0.t-ipconnect.de.12892 > 192.168.2.18.46750: UDP, length 172
13:39:20.479478 IP 192.168.2.18.46750 > <Hostname>.dip0.t-ipconnect.de.12892: UDP, length 172
...

Für mich sieht das danach aus das die Änderung des DNS-Servers in der Avaya den IP-Stack wieder in die Spur gebracht hat, im Grunde also der Effekt den ich mit dem Vorschlag die IP-Konfiguration nochmal einzutragen erzielen wollte. Ich glaube nicht, das es an den DNS-Daten liegt. Da der jetzige Zustand, sprich DNS-Abfragen am Domänencontroller und der UTM vorbei, nicht bleiben soll haben wir vereinbart das wir dieses Thema nochmal in Ruhe angehen.

Ich habe ja schon so einige Router in meinem IT-Leben ausgetauscht, aber sowas ist mir bis dato noch nicht begegnet. Das man ggf. am Regelwerk etwas nachstellen muss ist klar, aber das ein Netzwerk-Gerät quasi ganz aussteigt und das über Neustarts hinweg ist mir neu.

Vielleicht gibt es ja hier Avaya-kundige Kollege*innen mit einer Idee dazu, was da passiert sein könnte.

Links:

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

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.