Wenn bei VoIP-Telefongespräche manchmal die Gegenseite nicht zu hören ist, kann das an einem zu aggressiven IDS liegen.

VoIP-Gesprächen werden durch das SIP-Protokoll der jeweiligen Gegenseite signalisiert. Hier werden per SIP/SDP die jeweiligen RTP-Ports der Gegenstelle mitgeteilt. Über RTP laufen die eigentlichen Sprachdaten, leider ist die RTP-Portrange nicht klar definiert und jeder Hersteller hat eine eigene Range die zudem noch oftmals administrativ konfigurierbar ist. RTP entspricht somit der gesamten High-Portrange.

 

 

 

---

 

von wo kommt das initiale RTP-Frame?

Die eigentlichen Sprachdaten werden wie eingangs erwähnt per RTP übertragen. Es ist jedoch nicht definiert, welche Seite das erste RTP-Frame überträgt. So kann es vorkommen, dass ein RTP-Frame der Gegenseite als erstes an unserem (Edge/WAN)-Router ankommt. Dieses Frame bekommt folglich und korrekterweise den Connection-State „New“. Aus Sicht des IDS kommt ein unangefordertes Frame an der WAN-Seite an. Folglich wird die Quell-IP dieses Frames geblacklistet! Weiter erhält die Gegenseite aber unsere RTP-Frames (Sprachdateien), da LAN-zu-WAN i. d. R. erlaubt ist – die Gegenseite hört uns. Wir hören die Gegenseite aber nicht, da durch das IPS die RTP-Frames schon in der Prerouting-Chain gedropt werden (Quell-IP geblacklistet) und nie zu einer Established/Related-Regel in der Forward-Chain kommen.

 

Der unschöne Fehler, dass es manchmal geht und manchmal nicht, liegt daran, wenn das initiale RTP-Frame vom LAN ins WAN geht. Diese Verbindung ist einerseits erlaubt und wird andererseits getrackt. Zurückkommende Frames (Gegenseite zu uns) werden zu der initial (durch das LAN-seitig Frame) gehörenden Verbindung (Connection-State „Established“) gesehen und sind folglich zulässig. Die jeweiligen (RTP)-Ports wurde zu Beginn per SIP/SDP signalisiert – in diesem Fall hören sich beide Gesprächspartner.

 

Ist das erste Frame aber initial WAN-seitig am Router ankommend und ein entsprechendes IDS zu aggressiv konfiguriert – z. B. Match auf alle Frames mit einem Destination-Port in der High-Port-Range bei gleichzeitigem Connection-State „New“ – werden alle eingehenden RTP-Frames sofort verworfen. Wir hören die Gegenseite nicht, die Gegenseite hört aber uns.

 

---

 

die Lösung

Abhilfe schafft das IDS nicht auf alle High-Ports matchen zu lassen!

Hier ist ein guter Kompromiss, nur ausgewählte „attraktive Ports“ wie z. B. 3306, 3389, 5900, 8080, 8291… matchen zu lassen. Die Wahrscheinlichkeit, dass RTP genau einen dieser Ports wählt, ist verschwindend gering.

Wenn nun das initiale RTP-Frame von der Gegenstelle kommt, wird Dieses zwar nach wie vor verworfen (globaler Drop auf der Forward-Chain). Es findet aber keine Klassifizierung der Quell-IP in eine Blacklist mehr statt. Ab dem ersten extern eingehenden RTP-Frame, welches nach dem ersten ausgehenden RTP-Frame eintrifft, wird nichts mehr verworfen. Ein verworfenes RTP-Frame entspricht normalerweise 20ms an verlorenen Sprachdaten (ptime-Wert in den SIP/SDP-Frames). Dies ist absolut hinnehmbar, da keine hörbaren Sprachdaten betroffen sind.