Ein gutes Jahr nach dem bei einem anderem Kunden ein LANCOM-Router durch eine Securepoint UTM ersetzt wurde und anschließend gut zwei Tage lang die Telefonanlage streikte folgt nun eine weitere Geschichte zu gleicher Kombi, aber mit neuen Überraschungen.

Für alle die es interessiert kann hier der erwähnte Beitrag nachgelesen werden:

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

Wer keine Lust hat, die Vorgeschichte zu lesen, kann hier direkt zur Konfiguration springen.

Ausgangslage und Vorgeschichte

Dieses Mal eine ähnliche Ausgangslage, d.h. der Kunde hat von der Telekom einen LANCOM-Router, der mittlerweile veraltet ist und den Ansprüchen nicht mehr gerecht wird sowie ebenfalls zum Einsatz kommt eine Avaya Office IP-Telefonanlage. Diese ist sogar halbwegs auf dem aktuellen Stand, allerdings haben es sich vor ein paar Jahren zuerst die Telekom und später Avaya selbst es sich leicht gemacht, als der Wechsel von ISDN zu VoIP erfolgte, soll heißen: Der SIP-Trunk wurde im LANCOM-Router eingerichtet und die vier Sprachkanäle wurden über die S0-Anschlüsse mit der PBX verbunden. Später bei einem Umbau oder eher einer komplett neuen Telefonanlage wurde dies einfach so übernommen bzw. weitergeführt.

Diese Kombination stand nun einem einfachen Router-Tausch im Weg, da zunächst der SIP-Trunk vom LANCOM in die Avaya wandern musste. Nebenbei bemerkt: Beide Geräte werden bzw. wurden durch uns nicht verwaltet oder unterstützt. Der anstehende Router-Wechsel wurde entsprechend bei Avaya angefragt mit der Bitte mitzuteilen, was denn alles sonst noch hinsichtlich des Netzwerks, etwaiger Firewall-Regeln, etc. benötigt wird. Zurück kam lediglich ein Angebot das die Nutzung von SIP-Trunk direkt in der PBX einen zusätzlichen Obolus pro Monat kostet (die Anlage ist wohl gemietet) und für die Änderung ein Technikereinsatz (kompletter Tagessatz) benötigt wird.

Persönliche Bemerkung (bis hier hin): Bei dem Angebot der Avaya war ich durchaus erstaunt, der zusätzliche Betrag für die Nutzung des SIP-Trunks ist zwar nicht sonderlich hoch, aber das so etwas extra kostet war mir neu. Auch das ein Techniker einen Tag braucht um einen (!) SIP-Trunk mit ein paar Rufnummern, also echt überschaubar, benötigen soll erschien mir bis hierhin seltsam.

Es folgte leider ein kleines hin und her zur Terminabsprache, irgendwie kam dann wohl die letzte Terminbestätigung auch nicht bei uns an. Gut eine Woche vor dem eigentlichen Termin meldete sich dann ein Avaya-Techniker mit ein paar Fragen und was nun anstehen würde und warum man denn den LANCOM loswerden wolle (die Kombi würde doch gut funktionieren), usw. Er war wohl auch mal kurz unangemeldet vor Ort. Zudem lies er verlauten, das man ein Software-Update auf der Anlage installieren müsste und das macht man in der Mittagspause, da es “eine Weile” dauern würde.

An diesem Punkt fragte ich mich schon, warum das so ist, da es laut Kunde einen Wartungsvertrag gibt. Warum ist dann die Anlagensoftware nicht aktuell?!

Der Tag X

Die erste oder wenn man nach dem Angebot so möchte zweite Überraschung folgte am Tag der Umstellung. Als ich morgens in den Hof des Kunden fuhr, standen da bereits zwei Avaya-Fahrzeuge. Ja, wie, zwei Techniker vor Ort?! Nach dem Ausladen, kurzer Vorstellung dann wirklich die Erkenntnis, die machen das heute zu zweit, also wirklich zwei erfahrene Techniker, also keine Kombi mit Azubi oder Praktikant bzw. Neueinsteiger oder sowas. Nicht das wir uns falsch verstehen, das hier ist nichts persönliches! Mit den Kollegen gibt bzw. gab es keine Schwierigkeiten, Techniker untereinander verstehen sich ja meist. Unschön ist einfach der (weitere) Ablauf.

Also meinerseits Router samt Peripherie ausgetauscht, geprüft ob man wieder online ist (die UTM war vorkonfiguriert), alles tutti, die Telefonanlage war zudem per Ping erreichbar, aber leider fing es erst jetzt richtig an.

Die Telefonanlage konnte nicht wirklich erreicht werden, weder über den IP Office-Manager oder -Admin (oder wie auch immer deren Software heißt) noch über das Web-Interface. Kurz nochmal nach der Route (die wir aus dem LANCOM-Router ausgelesen hatten) geschaut, diese ist vorhanden und greift.

An diesem Punkt muss man Wissen, das die Avaya dort einen eigenen Switch samt eigenem Netz hat. Die LAN-IP ist dabei dem Switch zugeordnet, der wiederum ins PBX-Netz routet.

LAN (192.168.0.0/24) -> PBX-Switch (192.168.42.0/24) -> PBX (192.168.42.1/32)

Kurz darüber nachgedacht, ja klar, es fehlt ein Netzwerkobjekt samt Portfilter-Regel(n) für dieses “pbx-network”, also angelegt, konfiguriert, geht immer noch nicht. Alles doof.

Das geht soweit auf meine Kappe, dafür stehe ich gerade und war ja auch schnell geklärt, gemeint sind die fehlenden Portfilter-Regeln. Aber auch schön zu sehen, das eine Securepoint UTM in Sachen Firewall und interner Netze da schon strikter ist als der alte Router. Besser wäre natürlich gewesen, wenn wir den Netzaufbau von Avaya gekannt hätten, dann hätte man das in der Werkstatt vorab berücksichtigen können.

In der Zwischenzeit behalfen sich die Avaya-Techniker damit, über den Management Port ihres Switches auf die Anlage zuzugreifen um weiter machen zu können. Da ich nicht mehr weiter wusste, rief ich bei Securepoint an und bat um Support, der sich kurze Zeit später meldete und die Sache mit dem nicht funktionierenden Zugriff zwischen den Netzen schnell klärte. Kurzum: Es handelt sich bei diesem Netzaufbau um ein asymmetrisches Routing.

Nachfolgend (m)ein Erklärungsversuch:

Bei TCP wird ein Paket an ein Ziel geschickt, für den Status (Flag) lautet die Reihenfolge:

SYN, SYN-ACK, ACK (Stichwort: Three-Way-Handshake)

Beim asymmetrischen Routing ist das allerdings nicht der Fall, da das Paket die UTM verlässt und durch eine weitere Firewall/Router/etc. (in diesem Fall der Avaya-Switch) weitergereicht wird. Folglich bleibt SYN-ACK aus oder die Antwort passt nicht zum ursprünglichen SYN, folglich verwirft die UTM das Paket.

An alle Netzwerker: Wenn das hier nicht stimmt, bitte Bescheid geben.

Asymmetrisches Routing in der UTM einrichten

Um nun dennoch den Datenverkehr zuzulassen müssen lediglich drei Punkte beachtet werden:

• Es muss eine Route zum Ziel-Netzwerk gesetzt sein.
• Bei Portfilter-Regel(n) muss für Aktion “Stateless” konfiguriert sein:
  
• Im “IDS / IPS” muss auf der Registerkarte “UNGÜLTIGE TCP-FLAGS” “NewStateWithoutSyn” deaktiviert sein:

Weiteres

Nun war geklärt, warum zunächst die Netze nicht miteinander reden konnten. Die nächste Überraschung folgte dann gleich und zwar in der Form, das die Vorgabe bei Avaya wohl ist, das über den WAN2-Port der PBX SIP-Trunks laufen sollten, ergo wollte ein Techniker mit seinem Kabel direkt auf die UTM. Das aber war nicht mehr möglich, da alle vier Ports der RC100 belegt sind:

• A0 – VDSL-Modem, wan0
• A1 – LAN
• A2 – LTE-Fallback (externes LTE-Modem)
• A3 – Zweiter DSL-Anschluss (über einen Zyxel-Router)

Ich bot an, via VLAN und dem LAN-Switch was zu machen, aber es hieß das wäre kein Problem, man nutze dann halt WAN1. Das klappte nicht auf Anhieb, weil, ich zitiere: “Da haben wir uns die Karten selbst gelegt, da eine Route gefehlt hat. Für WAN2 macht der Assistent das von selbst.”

Irgendwann lief dann doch der SIP-Trunk und dann kam die angekündigte Aktualisierung. Das oder eher die Updates brauchten mehr als eine Stunde, zwischendurch stürzte zudem der LAN-Port der Anlage mal ab, das merkte man aber nicht gleich und wartete und wartete und wartete…

Die Kollegen haben zeitweise (imho) recht viel mit ihrem Support telefoniert. Es schien als war da noch einiges mehr zu machen an “Feintuning”. Am Ende des Tages war dann wohl alles gut.

Persönliche Bemerkung

Trotz aller Überraschungen hat man wieder etwas dazugelernt. Dennoch bin ich enttäuscht, das trotz Bitte und Nachfrage für die Vorbereitung, was benötigt wird, usw. nichts von Avaya diesbezüglich zurückkam. Ich frage mich an dieser Stelle, wie man denn wohl bei größeren Kunden bzw. Projekten agiert.

Vielleicht liegt es ja auch an mir und meiner Herangehensweise. Mir ist immer daran gelegen, soviel wie möglich in der Werkstatt vorzubereiten, damit man vor Ort idealerweise nur noch kurz umstecken bzw. umbauen braucht. Das minimiert Ausfallzeit und sorgt für weniger Stress bei allen Beteiligten.

Am Beispiel des Internet- und VPN-Zugangs hat das so auch funktioniert, nach gerade mal 45 Minuten war der LANCOM raus, die UTM samt VDSL-Modem drin und online, ein externes LTE-Modem als Fallback ebenfalls installiert und eingerichtet (ich hatte vorher die SIM-Karte nicht) und an einem zweiten vorhandenen DSL-Anschluss der dortige Router (keine UTM) ausgetauscht und auch wieder online.

Schneller wäre es nur möglich gewesen, wenn im Netzwerkschrank mehr Platz gewesen wäre, damit man parallel zum Bestand VDSL-Modem und UTM hätte aufbauen können. Überhaupt nicht nachvollziehbar ist für mich, das die Telefonanlagensoftware nicht auf dem aktuellen Stand ist, bei den von uns verwalteten 3CX ist das nicht so, diese werden immer zeitnah aktualisiert und die dortigen Updates brauchen nicht so viel Zeit und SIP-Trunks (gemeint ist die Funktion, nicht irgendwelche Provider-Tarife) kosten nichts extra.

Danksagung

Einmal mehr ein fettes Dankeschön an den fachkundigen und schnellen Support von Securepoint!

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.