Sophos Firewall VoIP-Probleme mit SIP und RTP beheben

VoIP-Probleme hinter einer Sophos Firewall wirken oft diffus: Telefone registrieren sich nicht, Anrufe brechen ab, es klingelt ohne Audio oder Sprache ist nur in eine Richtung hörbar. In der Praxis liegt die Ursache selten an einem einzelnen Schalter. Meist spielen SIP-Signalisierung, RTP-Medienstrom, NAT, Firewall-Regeln, UDP-Timeouts oder Routing zusammen.

Der Artikel ordnet VoIP-Troubleshooting auf der Sophos Firewall als strukturierten Ablauf ein. Bekannte Sofortmassnahmen wie SIP Helper deaktivieren oder UDP Timeout erhöhen bleiben wichtig. Solche Änderungen sollten aber nicht blind gesetzt werden, sondern als Teil eines sauberen Troubleshooting-Ablaufs.

Was bei VoIP durch die Firewall läuft

VoIP besteht grob aus zwei Teilen:

• SIP: steuert Registrierung, Rufaufbau, Rufabbau und Aushandlung der Medienparameter. Typische Fehler sind fehlgeschlagene Registrierung, nicht aufgebaute Anrufe oder vom Provider abgelehnte SIP-Dialoge.
• RTP: transportiert die Sprachdaten während des Gesprächs. Typische Fehler sind fehlendes Audio, einseitiges Audio oder Audioabbrüche nach kurzer Zeit.

SIP läuft häufig über UDP oder TCP 5060, bei verschlüsseltem SIP oft über 5061. Das ist aber kein Gesetz. Viele Provider verwenden eigene Ports, eigene Proxy-Server oder zusätzliche Anforderungen an NAT Keepalives.

RTP nutzt meistens UDP-Portbereiche, die vom Provider, der Telefonanlage oder den Endgeräten vorgegeben werden. Für eine saubere Analyse braucht man deshalb die konkreten SIP-Server, RTP-Portbereiche und Transportprotokolle des Providers oder der PBX-Dokumentation.

Symptome richtig einordnen

Vor Änderungen sollte man das Symptom möglichst genau einordnen.

• Registrierung schlägt fehl: DNS, Routing, Firewall-Regel, NAT, Provider-Zugangsdaten oder SIP Transport prüfen.
• Anruf baut nicht auf: SIP-Signalisierung, Firewall-Regel, Application Control und mögliche Provider-Sperren prüfen.
• Anruf funktioniert, aber ohne Audio: RTP-Portbereich, NAT, Rückroute, SD-WAN und SIP Helper prüfen.
• Audio ist nur in eine Richtung hörbar: RTP-Rückweg, NAT, Routing, VPN und SD-WAN prüfen.
• Gespräch bricht nach 30, 60 oder 120 Sekunden ab: UDP Timeout, NAT Keepalive, Session Refresh und Provider-Erwartungen prüfen.
• Nur eingehende Anrufe funktionieren nicht: DNAT, Firewall-Regel, Provider-Quellnetze und PBX-Portfreigaben prüfen.
• Nur eine WAN-Leitung macht Probleme: SD-WAN Route, Reply Path, Gateway und Provider-IP-Bindung prüfen.

Diese Einordnung verhindert, dass man SIP-Einstellungen verändert, obwohl das eigentliche Problem im RTP-Rückweg oder in einer SD-WAN-Route liegt.

Vor Änderungen prüfen

Vor CLI-Änderungen sollte man den aktuellen Zustand dokumentieren:

• Welche Telefone, PBX oder SBC sind betroffen?
• Registrieren sich Endgeräte direkt beim Provider oder läuft alles über eine interne Telefonanlage?
• Welche SIP-Server und RTP-Portbereiche nennt der Provider?
• Welche Firewall-Regel verarbeitet den VoIP-Traffic?
• Ist in dieser Regel Log firewall traffic aktiviert?
• Welche NAT-Regel greift für ausgehenden und eingehenden VoIP-Traffic?
• Gibt es mehrere WAN-Leitungen, SD-WAN Routes oder route-based VPNs?
• Wurde das Problem nach einem Firmware-Upgrade, Provider-Wechsel oder PBX-Update sichtbar?

Für die Regelanalyse hilft Firewall-Regeln auf Sophos Firewall testen. Für den tatsächlichen Paketfluss ist Packet Capture im WebAdmin meist aussagekräftiger als ein reiner Policy-Test.

SIP Helper prüfen

Der SIP Helper, oft auch SIP ALG genannt, versucht SIP-Pakete zu erkennen und NAT-relevante SIP-Informationen anzupassen. Das kann in einfachen Umgebungen helfen. In vielen modernen VoIP-Setups mit Provider-SBC, eigener PBX, TLS, sauberem NAT Keepalive oder komplexeren RTP-Portbereichen kann es aber auch stören.

Deshalb ist der SIP Helper ein sinnvoller Testpunkt, aber keine pauschale Dauerlösung für jedes Problem.

Die Befehle werden über SSH auf der Sophos Firewall ausgeführt. Dafür verbindet man sich mit der Firewall und wählt 4. Device Console. Der SSH-Zugriff sollte nur aus vertrauenswürdigen Netzen erlaubt sein. Die Grundlagen stehen in Per SSH mit Sophos Firewall verbinden.

Aktuellen Modulstatus anzeigen:

system system_modules show

SIP Modul deaktivieren:

system system_modules sip unload

SIP Modul wieder aktivieren:

system system_modules sip load

⚠️ Diese Änderung sollte in einem Wartungsfenster oder mit klar eingegrenztem Test erfolgen. Nach dem Deaktivieren oder Aktivieren müssen Registrierung, ausgehende Anrufe, eingehende Anrufe und Audio in beide Richtungen geprüft werden.

Wenn die Änderung nicht hilft, sollte man sie wieder zurücknehmen. Wichtig ist, den Zustand vor und nach dem Test zu dokumentieren.

UDP Timeout prüfen und anpassen

VoIP nutzt häufig UDP. Wenn NAT- oder Session-Einträge zu früh ablaufen, kann eine Registrierung scheinbar funktionieren, aber Gespräche brechen ab oder eingehende Anrufe erreichen die PBX nicht zuverlässig.

Den aktuellen Advanced-Firewall-Status zeigt man in der Device Console an:

show advanced-firewall

Ein häufiger Testwert ist 180 Sekunden:

set advanced-firewall udp-timeout-stream 180

⚠️ udp-timeout-stream ist keine reine VoIP-Regeloption, sondern wirkt breiter auf UDP-Sessions. Der Wert sollte nicht beliebig hoch gesetzt werden. Besser ist ein definierter Test mit Dokumentation des alten Werts, Provider-Anforderungen und anschliessender Kontrolle der Session- und Sprachqualität.

Wenn der Provider oder die Telefonanlage NAT Keepalive unterstützt, sollte diese Einstellung ebenfalls geprüft werden. Ein sauberer Keepalive auf PBX- oder Provider-Seite ist oft besser als ein sehr hoher globaler Timeout-Wert.

Firewall-Regeln und NAT prüfen

Bei VoIP-Problemen ist NAT häufig beteiligt. Die Sophos Firewall muss nicht nur SIP erlauben, sondern auch die dazugehörigen RTP-Ströme in beide Richtungen korrekt übersetzen und zurückführen.

Für ausgehende Telefone oder eine interne PBX sind meist diese Punkte relevant:

• passende Firewall-Regel von der VoIP-Zone oder PBX-Zone nach WAN
• passende SNAT- oder MASQ-Regel
• Logging in der Firewall-Regel
• keine zu breite oder falsch positionierte Regel oberhalb der VoIP-Regel
• kein unerwartetes Application Control, IPS oder Web-Filtering auf diesem Traffic

Für eingehende SIP-Trunks oder veröffentlichte Telefonanlagen kommen weitere Punkte dazu:

• DNAT auf die interne PBX oder den SBC
• Firewall-Regel mit passender Zielzone und Zielnetz
• Einschränkung auf Provider-Quellnetze, wenn möglich
• nur benötigte SIP- und RTP-Ports
• Logging und Packet Capture für Tests

Eine NAT-Regel erlaubt keinen Traffic, sondern übersetzt nur Adressen oder Ports. Die Zusammenhänge sind in NAT auf Sophos Firewall verstehen erklärt. Wenn eine PBX aus dem Internet erreichbar sein muss, ist Server per DNAT veröffentlichen die bessere Grundlage für die eigentliche Veröffentlichung.

RTP und Sprachrichtung analysieren

Wenn der Anruf aufgebaut wird, aber Audio fehlt, ist SIP meistens nicht mehr die Hauptfrage. Dann muss man prüfen, ob RTP in beide Richtungen fliesst.

Typischer Ablauf:

1. Provider- oder PBX-RTP-Portbereich notieren.
2. Packet Capture mit Source IP der PBX oder des Telefons und RTP-Portbereich starten.
3. Testanruf ausführen.
4. Prüfen, ob UDP-Pakete vom internen Gerät zum Provider sichtbar sind.
5. Prüfen, ob UDP-Pakete vom Provider zurückkommen.
6. NAT ID, Rule ID, In interface und Out interface vergleichen.

Wenn RTP nur ausgehend sichtbar ist, aber nichts zurückkommt, kann das Problem beim Provider, beim Rückweg, bei NAT oder bei einer vorgeschalteten Gegenstelle liegen. Wenn RTP zurückkommt, aber nicht zur PBX weitergeleitet wird, sind Firewall-Regel, DNAT, Routing oder Zone-Zuordnung wahrscheinlicher.

Für genauere Mitschnitte oder PCAP-Export kann tcpdump über SSH sinnvoll sein. Der Ablauf ist in Sophos Firewall tcpdump für Logs und Analyse verwenden beschrieben.

SD-WAN, VPN und mehrere WAN-Leitungen

VoIP reagiert empfindlich auf asymmetrische Pfade. Wenn SIP über eine WAN-Leitung läuft, RTP aber über eine andere Leitung zurückkommt oder ein route-based VPN anders geroutet wird, entstehen typische Fehler wie einseitiges Audio.

Ein in SFOS 22.0 MR1 behobener Fehler zeigt den typischen Zusammenhang: Nach einem Upgrade auf SFOS 22.0 GA konnte VoIP-Audio über route-based VPN mit SD-WAN Routing nur einseitig funktionieren. Für die Praxis heisst das: Bei VoIP über VPN oder mehrere WAN-Pfade sollte SD-WAN immer mitgeprüft werden.

Wichtige Prüfpunkte:

• Greift eine SD-WAN Route auf den VoIP-Traffic?
• Wird SIP und RTP über dieselbe erwartete WAN-Leitung geführt?
• Gibt es Provider-Vorgaben zu Source-IP oder öffentlicher Absenderadresse?
• Wird eine route-based VPN-Strecke mit XFRM-Interface verwendet?
• Stimmen Rückrouten und NAT mit dem gewählten Pfad überein?
• Zeigt Packet Capture unterschiedliche Gateways oder Interfaces für Hin- und Rückrichtung?

Für Sophos-spezifische SD-WAN-Optionen passt SD-WAN Routing Reply-Packet und System Traffic. Bei IPsec-Zusammenhängen hilft zusätzlich Sophos Firewall IPsec Troubleshooting.

Traffic Shaping für VoIP

Traffic Shaping kann VoIP stabilisieren, wenn die Leitung knapp ist oder grosse Uploads Sprachpakete verdrängen. Es löst aber keine falschen NAT-Regeln, keine fehlenden RTP-Ports und keine falschen Rückrouten.

Sinnvoll ist Traffic Shaping vor allem, wenn:

• VoIP bei Last auf der Internetleitung schlechter wird,
• Uploads oder Backups Gespräche stören,
• mehrere Anwendungen dieselbe Leitung nutzen,
• VoIP gezielt priorisiert werden soll.

Die Konfiguration ist in Application Traffic Shaping auf Sophos Firewall beschrieben. Für VoIP sollte man nach der Umsetzung nicht nur Speedtests prüfen, sondern echte Testanrufe mit gleichzeitiger Last durchführen.

Praktischer Troubleshooting-Ablauf

1. Symptom dokumentieren: Registrierung, Rufaufbau, Audio, Abbruchzeit, Richtung.
2. Providerdaten sammeln: SIP-Server, Transport, RTP-Portbereich, NAT-Anforderungen.
3. Firewall-Regel und NAT-Regel identifizieren.
4. Logging in der betroffenen Firewall-Regel aktivieren.
5. Log Viewer und Packet Capture während eines Testanrufs öffnen.
6. Prüfen, ob SIP-Signalisierung in beide Richtungen läuft.
7. Prüfen, ob RTP in beide Richtungen läuft.
8. Bei mehreren WAN-Leitungen SD-WAN und Rückweg prüfen.
9. SIP Helper gezielt testen und Ergebnis dokumentieren.
10. UDP Timeout nur bewusst und mit altem Wert dokumentiert anpassen.
11. Nach jeder Änderung Registrierung, ausgehende Anrufe, eingehende Anrufe und Audio in beide Richtungen testen.

Wenn mehrere Änderungen gleichzeitig gemacht werden, ist die spätere Ursache kaum noch nachvollziehbar. Besser ist ein Test pro Änderung.

Nachweise während eines Testanrufs sammeln

Ein VoIP-Test ist nur dann hilfreich, wenn Uhrzeit, Richtung und Paketfluss zusammenpassen. Gerade bei Providerfällen reicht die Aussage “Audio geht nicht” nicht aus. Man braucht einen kleinen, reproduzierbaren Testfall.

• Genaue Uhrzeit mit Zeitzone: Log Viewer, Packet Capture und Provider-Logs lassen sich später sauber vergleichen.
• Rufrichtung: eingehende Anrufe, ausgehende Anrufe und interne Weiterleitungen werden nicht vermischt.
• Rufnummern oder Nebenstellen: Provider und PBX finden den konkreten Call schneller.
• Interne IP der PBX oder des Telefons: Packet Capture kann eng gefiltert werden.
• Provider-SIP-Server und RTP-Portbereich: SIP- und RTP-Analyse bleiben getrennt.
• Rule ID, NAT ID, In interface und Out interface: man sieht, welche Regel und welcher Pfad wirklich verwendet wurden.
• Ergebnis pro Test: Registrierung, Klingeln, Gesprächsaufbau, Audio links/rechts und Abbruchzeit bleiben nachvollziehbar.

Bei sporadischen Fehlern sollte man zusätzlich die relevanten Logs sichern, bevor sie überschrieben werden. Für ein sauberes Logpaket passt Sophos Firewall Logs für Support und Analyse sichern. Welche Logdatei zu welchem Dienst gehört, ist in Sophos Firewall Troubleshooting: Services und Logs beschrieben.

Häufige Fehler

• Nur SIP-Port freigegeben, RTP-Portbereich vergessen: Der Anruf baut auf, aber Audio fehlt.
• NAT-Regel vorhanden, aber keine passende Firewall-Regel: Traffic wird übersetzt, aber nicht erlaubt.
• Firewall-Regel ohne Logging: Troubleshooting im Log Viewer bleibt blind.
• SIP Helper pauschal deaktiviert oder aktiviert: Das Problem wird zufällig verschoben statt analysiert.
• UDP Timeout sehr hoch gesetzt: Globale UDP-Sessions bleiben unnötig lange offen.
• Mehrere WAN-Pfade ohne klare SD-WAN-Regel: Einseitiges Audio oder vom Provider abgelehnter Traffic wird wahrscheinlicher.
• Provider-Quellnetze nicht eingeschränkt: Der SIP-Dienst ist unnötig breit aus dem Internet erreichbar.
• Traffic Shaping als Ersatz für NAT/Routing verstanden: Die Sprachqualität bleibt schlecht, weil die Ursache woanders liegt.

Rollback und Dokumentation

Bei VoIP-Änderungen sollte immer klar sein, wie man zurückkommt:

• alter udp-timeout-stream Wert dokumentiert
• SIP Modulstatus vor dem Test dokumentiert
• geänderte Firewall- und NAT-Regeln mit Datum und Grund notiert
• Testanrufe mit Richtung und Uhrzeit protokolliert
• Packet Capture oder relevante Logs für Supportfälle gesichert

Wenn die Änderung nicht hilft, sollte sie nicht als zufällige Altlast stehen bleiben. Gerade VoIP-Workarounds werden sonst später schwer verständlich.

Checkliste

• Provider-SIP- und RTP-Informationen liegen vor.
• Firewall-Regel für VoIP ist identifiziert und Logging ist aktiv.
• NAT-Regel passt zur Richtung des Traffics.
• SIP und RTP wurden getrennt geprüft.
• Packet Capture zeigt Hin- und Rückrichtung.
• SIP Helper wurde nur gezielt getestet.
• UDP Timeout wurde nur mit dokumentiertem Ausgangswert geändert.
• SD-WAN, VPN und mehrere WAN-Leitungen wurden geprüft.
• Traffic Shaping wird nur für Qualitätssteuerung verwendet, nicht als Ersatz für Routing- oder NAT-Korrekturen.

Häufige Fragen