Avaya IP Office-Telefonanlage: Kein Routing und kein DNS mehr nach Router-Tausch

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)

3 Kommentare

  • Hi Andy,

    du musst aufpassen bei Telekom und anderen DNS Server als die von der Telekom. Wenn bei bei einem Telekomanschluss einen anderen DNS Server verwendest brechen manchmal die Gespräche ab. Es werden bei dem Telekom SIP Trunk die SRV Einträge abgefragt und die Telekom ändert diese doch öfters als vermutet. Dann gibt es bei anderen DNS Server Probleme mit der Telefonie.
    Seit wir bei Telekomanschlüssen nur die Telekom DNS Server benutzen, haben wir aktuell keine Probleme mehr.

    Gruss

    Flo

  • Hallo Flo,

    wir nutzen keine anderen DNS-Server als die des Providers. Den Google DNS hat wiederum der Avaya-Lieferant-Support eingetragen.
    Glücklich bin ich mit dieser Situation nicht, habe allerdings auch noch kein Zeitfenster für einen weiteren Versuch bekommen.

  • Ein kleiner Nachtrag:

    Gleicher Kunde. Ein freier Mitarbeiter konnte nicht mehr auf den Mailserver und weiteres im LAN zugreifen. Surfen funktionierte hingegen schon. Nach etwas suchen stellte sich dann heraus, das es an einer Funktion im VPN-Client (ich glaube NordVPN o.ä.) lag. Es gibt dort sowas wie “Unsichtbar im Netzwerk”, das zwar Traffic zum Gateway zulässt, aber nicht zu anderen Geräten im LAN.

    Durch den Firewall-Router-Tausch und der damit einhergehenden MAC-Adressänderung war diese Funktion dann der Meinung in einem anderem Netzwerk zu sein und blockierte dann alles außer Internet. Das kann man wohl Vergleichen mit den Netzwerkkategorien von Windows, nur in strikter da es beide Richtungen betrifft.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.