Sophos Firewall VoIP-problemen met SIP en RTP oplossen

VoIP-problemen achter een Sophos Firewall hebben vaak een diffuus effect: telefoons melden zich niet aan, gesprekken worden afgebroken, er gaat over zonder geluid of spraak is maar in één richting te horen. In de praktijk ligt de oorzaak zelden bij een enkele schakelaar. SIP-signalering, RTP-mediastream, NAT, firewallregels, UDP-time-outs of routing werken meestal samen.

Het artikel classificeert VoIP-probleemoplossing op de Sophos Firewall als een gestructureerd proces. Bekende onmiddellijke maatregelen zoals het deactiveren van SIP Helper of het verhogen van de UDP-time-out blijven belangrijk. Dergelijke wijzigingen mogen echter niet blindelings worden doorgevoerd, maar eerder als onderdeel van een schoon probleemoplossingsproces.

Wat er door de firewall loopt bij VoIP

VoIP bestaat grofweg uit twee delen:

SIP: regelt de registratie, het opzetten van gesprekken, het wissen van gesprekken en het onderhandelen over mediaparameters. Typische fouten zijn onder meer een mislukte registratie, het niet tot stand komen van oproepen of het weigeren van SIP-dialogen door de provider.
RTP: transporteert de spraakgegevens tijdens het gesprek. Typische fouten zijn onder meer ontbrekende audio, eenzijdige audio of audio die na korte tijd afbreekt.

SIP loopt vaak via UDP of TCP 5060, terwijl gecodeerde SIP vaak over 5061 loopt. Maar dat is geen wet. Veel providers gebruiken hun eigen poorten, hun eigen proxyservers of aanvullende vereisten voor NAT-keepalives.

RTP maakt doorgaans gebruik van UDP-poortbereiken die zijn gespecificeerd door de provider, het telefoonsysteem of de eindapparaten. Voor een zuivere analyse heeft u de specifieke SIP-servers, RTP-poortbereiken en transportprotocollen van de provider of de PBX-documentatie nodig.

Classificeer de symptomen correct

Voordat u wijzigingen aanbrengt, moet u het symptoom zo nauwkeurig mogelijk classificeren.

Registratie mislukt: Controleer DNS, routing, firewallregel, NAT, providerreferenties of SIP-transport.
Gesprek maakt geen verbinding: Controleer SIP-signalering, firewallregel, Application Control en mogelijke providerblokkeringen.
Oproep werkt maar geen audio: Controleer RTP-poortbereik, NAT, retourroute, SD-WAN en SIP Helper.
Audio is slechts in één richting hoorbaar: Controleer RTP-retourpad, NAT, routing, VPN en SD-WAN.
Het gesprek wordt na 30, 60 of 120 seconden afgebroken: Controleer de UDP-time-out, NAT keepalive, sessievernieuwing en verwachtingen van de provider.
Alleen inkomende oproepen werken niet: Controleer DNAT, firewallregel, bronnetwerken van de provider en delen van PBX-poorten.
Slechts één WAN-lijn veroorzaakt problemen: Controleer de SD-WAN-route, het antwoordpad, de gateway en de IP-binding van de provider.

Deze classificatie voorkomt dat u de SIP-instellingen wijzigt, ook al ligt het werkelijke probleem in het RTP-retourpad of een SD-WAN-route.

Controleer voordat u wijzigingen aanbrengt

Voordat u CLI-wijzigingen aanbrengt, moet u de huidige status documenteren:

Om welke telefoons, PBX of SBC gaat het?
Melden eindapparaten zich rechtstreeks aan bij de provider of verloopt alles via een interne telefooncentrale?
Welke SIP-servers en RTP-poortbereiken noemt de provider?
Welke firewallregel verwerkt het VoIP-verkeer?
Is Log firewall traffic ingeschakeld in deze regel?
Welke NAT-regel is van toepassing op uitgaand en inkomend VoIP-verkeer?
Zijn er meerdere WAN-lijnen, SD-WAN-routes of routegebaseerde VPN’s?
Is het probleem zichtbaar geworden na een firmware-upgrade, providerwissel of PBX-update?

Firewallregels op Sophos Firewall testen helpt bij regelanalyse. Voor de daadwerkelijke pakketstroom is Packet Capture in WebAdmin doorgaans betekenisvoller dan een pure beleidstest.

Controleer SIP-helper

De SIP Helper, vaak ook SIP ALG genoemd, probeert SIP-pakketten te herkennen en NAT-relevante SIP-informatie aan te passen. Dit kan helpen in eenvoudige omgevingen. Het kan echter ook storend zijn in veel moderne VoIP-opstellingen met provider SBC, eigen PBX, TLS, schone NAT keepalive of complexere RTP-poortbereiken.

Daarom is de SIP Helper een nuttig testpunt, maar geen algemene permanente oplossing voor elk probleem.

De opdrachten worden uitgevoerd via SSH op de Sophos Firewall. Maak hiervoor verbinding met de firewall en selecteer 4. Device Console. SSH-toegang mag alleen worden toegestaan vanaf vertrouwde netwerken. De basis staat in Via SSH verbinden met Sophos Firewall.

Toon huidige modulestatus:

system system_modules show

SIP-module deactiveren:

Huidige modulestatus weergeven:

system system_modules show

SIP-module opnieuw activeren:

SIP-module uitschakelen:

system system_modules sip unload

SIP-module weer inschakelen:

system system_modules sip load

⚠️ Deze wijziging moet worden doorgevoerd in een onderhoudsvenster of met duidelijk gedefinieerde tests. Na het uit- of inschakelen moeten de aanmelding, uitgaande oproepen, inkomende oproepen en audio in beide richtingen worden gecontroleerd.

Als de wijziging niet helpt, moet u deze terugnemen. Het is belangrijk om de toestand voor en na de test te documenteren.

Controleer en pas de UDP-time-out aan

VoIP maakt vaak gebruik van UDP. Als NAT- of sessie-items te vroeg verlopen, kan het lijken alsof een registratie werkt, maar gesprekken vallen weg of inkomende oproepen bereiken de PBX niet betrouwbaar.

De huidige geavanceerde firewallstatus wordt weergegeven in Device Console:

show advanced-firewall

UDP Timeout Stream-waarde op Sophos Firewall — De UDP Timeout Stream-waarde moet vóór elke wijziging worden gedocumenteerd.

Een veel voorkomende testwaarde is 180 seconden:```shell set advanced-firewall udp-timeout-stream 180


> ⚠️`udp-timeout-stream` is geen pure VoIP-controleoptie, maar heeft een breder effect op UDP-sessies. De waarde mag niet willekeurig hoog worden ingesteld. Het is beter om een gedefinieerde test te hebben met documentatie van de oude waarde, providervereisten en daaropvolgende controle van de sessie- en stemkwaliteit.

Als de provider of het telefoonsysteem NAT keepalive ondersteunt, moet deze instelling ook worden gecontroleerd. Een schone keepalive aan de PBX- of providerzijde is vaak beter dan een zeer hoge globale time-outwaarde.

## Controleer firewallregels en NAT

NAT is vaak betrokken bij VoIP-problemen. De Sophos Firewall moet niet alleen SIP toestaan, maar ook de bijbehorende RTP-streams in beide richtingen correct vertalen en retourneren.

Deze punten zijn meestal relevant voor uitgaande telefoons of een interne PBX:

- passende firewallregel van de VoIP-zone of PBX-zone naar WAN
- passende SNAT- of MASQ-regel
- Inloggen op de firewallregel
- geen regel die te breed is of verkeerd gepositioneerd boven de VoIP-regel
- geen onverwachte Application Control-, IPS- of webfiltering op dit verkeer

Er worden extra punten toegevoegd voor inkomende SIP-trunks of gepubliceerde telefoonsystemen:

- DNAT naar de interne PBX of SBC
- Firewallregel met geschikte doelzone en doelnetwerk
- Beperking tot bronnetwerken van providers, indien mogelijk
- alleen vereiste SIP- en RTP-poorten
- Logging en Packet Capture voor testen

Een NAT-regel staat geen verkeer toe, maar vertaalt alleen adressen of poorten. De aansluitingen worden uitgelegd in [NAT op Sophos Firewall begrijpen](/nl/kb/sophos-firewall-nat-basics/). Als een PBX via internet bereikbaar moet zijn, is [Publiceerserver via DNAT](/nl/kb/sophos-firewall-server-dnat-publiceren/) de betere basis voor de daadwerkelijke publicatie.

## Analyseer RTP en taalrichting

Als de oproep tot stand is gebracht maar er geen audio is, is SIP meestal niet langer het grootste probleem. Dan moet je controleren of RTP in beide richtingen stroomt.

Typisch proces:

1. Let op het RTP-poortbereik van de provider of de PBX.
2. Start Packet Capture met bron-IP van de PBX of telefoon en RTP-poortbereik.
3. Voer een testoproep uit.
4. Controleer of UDP-pakketten van het interne apparaat naar de provider zichtbaar zijn.
5. Controleer of UDP-pakketten terugkeren van de provider.
6. Vergelijk NAT ID, Rule ID, In interface en Out interface.Als RTP alleen uitgaand zichtbaar is, maar er komt niets terug, kan het probleem liggen bij de provider, het retourpad, NAT of een stroomopwaarts extern station. Als RTP terugkomt maar niet wordt doorgestuurd naar de PBX, zijn firewallregel, DNAT, routing of zone mapping waarschijnlijker.

Voor nauwkeurigere opnames of PCAP-export kan `tcpdump` via SSH nuttig zijn. Het proces wordt beschreven in [Sophos Firewall tcpdump gebruiken voor logs en analyse](/nl/kb/sophos-firewall-logs-met-tcpdump-verzamelen/).

## SD-WAN, VPN en meerdere WAN-lijnen

VoIP is gevoelig voor asymmetrische paden. Als SIP over een WAN-lijn loopt, maar RTP over een andere lijn terugkeert of een op route gebaseerde VPN anders wordt gerouteerd, ontstaan typische fouten zoals eenzijdige audio.

Een bug die is opgelost in SFOS 22.0 MR1 toont de typische verbinding: na een upgrade naar SFOS 22.0 GA kon VoIP-audio slechts in één richting werken via routegebaseerde VPN met SD-WAN-routering. In de praktijk betekent dit: SD-WAN moet altijd worden aangevinkt bij gebruik van VoIP via VPN of meerdere WAN-paden.

Belangrijke controlepunten:

- Heeft een SD-WAN-route toegang tot VoIP-verkeer?
- Worden SIP en RTP over dezelfde verwachte WAN-lijn gerouteerd?
- Zijn er specificaties van de provider met betrekking tot het bron-IP-adres of het openbare afzenderadres?
- Wordt er een routegebaseerde VPN-route met een XFRM-interface gebruikt?
- Komen retourroutes en NAT overeen met het gekozen pad?
- Toont Packet Capture verschillende gateways of interfaces voor heen- en teruggaande richtingen?

Voor Sophos-specifieke SD-WAN-opties past [SD-WAN-routering van antwoordpakketten en systeemverkeer](/nl/kb/sophos-firewall-sd-wan-routing-reply-packet-system-traffic/). [Sophos Firewall IPsec Troubleshooting](/nl/kb/sophos-firewall-ipsec-troubleshooting/) helpt ook bij IPsec-verbindingen.

## Verkeersvorming voor VoIP

Traffic shaping kan VoIP stabiliseren wanneer lijnen krap zijn of grote uploads spraakpakketten verdringen. Het lost echter geen onjuiste NAT-regels, ontbrekende RTP-poorten en onjuiste retourroutes op.

Traffic shaping is vooral nuttig als:

- VoIP wordt slechter als de internetlijn onder belasting staat,
- Uploads of back-ups verstoren gesprekken,
- meerdere applicaties gebruiken dezelfde lijn,
- VoIP moet specifiek prioriteit krijgen.

De configuratie wordt beschreven in [Application Traffic Shaping op Sophos Firewall](/nl/kb/sophos-firewall-application-traffic-shaping/). Voor VoIP moet u niet alleen na de implementatie snelheidstests controleren, maar ook echte testoproepen uitvoeren bij gelijktijdige belasting.

## Praktische probleemoplossingsstroom

1. Documentsymptomen: registratie, oproepconfiguratie, audio, afbreektijd, richting.
2. Verzamel providergegevens: SIP-server, transport, RTP-poortbereik, NAT-vereisten.
3. Identificeer de firewallregel en NAT-regel.
4. Activeer het inloggen op de betreffende firewallregel.
5. Open Log Viewer en Packet Capture tijdens een testoproep.
6. Controleer of de SIP-signalering in beide richtingen loopt.
7. Controleer of RTP in beide richtingen werkt.
8. Als er meerdere WAN-lijnen zijn, controleer dan SD-WAN en retourpad.
9. Test SIP Helper specifiek en documenteer de resultaten.
1
0. Pas de UDP-time-out alleen bewust en gedocumenteerd aan met de oude waarde.
1
1. Test na elke wijziging de registratie, uitgaande oproepen, inkomende oproepen en audio in beide richtingen.

Als er meerdere wijzigingen tegelijkertijd worden aangebracht, is de daaropvolgende oorzaak moeilijk te begrijpen. Eén test per wijziging is beter.

## Verzamel bewijsmateriaal tijdens een testoproep

Een VoIP-test heeft alleen zin als de tijd, richting en pakketstroom overeenkomen. Vooral in providergevallen is de verklaring “Audio werkt niet” niet voldoende. Je hebt een kleine, reproduceerbare testcase nodig.
- **Exacte tijd met tijdzone:** Log Viewer, Packet Capture en providerlogboeken kunnen later eenvoudig worden vergeleken.
- **Oproeprichting:** inkomende oproepen, uitgaande oproepen en interne doorschakeling worden niet gemengd.
- **Telefoonnummers of toestelnummers:** Providers en PBX's vinden het specifieke gesprek sneller.
- **Intern IP-adres van PBX of telefoon:** Packet Capture kan nauwkeurig worden gefilterd.
- **Provider SIP-server en RTP-poortbereik:** SIP- en RTP-analyse blijven gescheiden.
- **Rule ID, NAT ID, In interface en Out interface:** u kunt zien welke regel en welk pad daadwerkelijk zijn gebruikt.
- **Resultaat per test:** Registratie, belsignaal, oproepopbouw, audio links/rechts en beëindigingstijd blijven traceerbaar.

In het geval van sporadische fouten moet u ook een back-up maken van de relevante logs voordat deze worden overschreven. Voor een schoon houtpakket past [Sophos Firewall logs voor support en analyse veiligstellen](/nl/kb/sophos-firewall-logs-support-analyse/). Welk logbestand bij welke dienst hoort, staat beschreven in [Sophos Firewall Troubleshooting: services en logs](/nl/kb/sophos-firewall-services-logs/).

## Veelvoorkomende fouten
- **Alleen SIP-poort ingeschakeld, RTP-poortbereik vergeten:** Het gesprek wordt opgezet, maar er ontbreekt audio.
- **NAT-regel bestaat, maar geen overeenkomende firewallregel:** Verkeer wordt vertaald maar niet toegestaan.
- **Firewallregel zonder loggen:** Probleemoplossing in Log Viewer blijft blind.
- **SIP Helper gedeactiveerd of geactiveerd over de hele linie:** Het probleem wordt willekeurig verplaatst in plaats van geanalyseerd.
- **UDP-time-out zeer hoog ingesteld:** Globale UDP-sessies blijven onnodig lang open.
- **Meerdere WAN-paden zonder een duidelijke SD-WAN-regel:** Eenrichtingsaudio of afgewezen verkeer door de provider wordt waarschijnlijker.
- **Bronnetwerken van providers niet beperkt:** De SIP-service is onnodig breed toegankelijk vanaf internet.
- **Traffic shaping opgevat als vervanging voor NAT/routing:** De spraakkwaliteit blijft slecht omdat de oorzaak elders ligt.

## Terugdraaien en documentatie

Wanneer u VoIP-wijzigingen doorvoert, moet het altijd duidelijk zijn hoe u terug kunt komen:- oude `udp-timeout-stream`-waarde gedocumenteerd
- SIP-modulestatus gedocumenteerd vóór het testen
- Gewijzigde firewall- en NAT-regels genoteerd met datum en reden
- Testoproepen geregistreerd met richting en tijd
- Packet Capture of relevante logboeken beveiligd voor ondersteuningsgevallen

Als de verandering niet helpt, mag deze niet als een toevallige erfenis worden achtergelaten. Vooral VoIP-oplossingen worden anders later moeilijk te begrijpen.

## Controlelijst

- Provider SIP- en RTP-informatie is beschikbaar.
- Firewallregel voor VoIP is geïdentificeerd en loggen is actief.
- NAT-regel komt overeen met de richting van het verkeer.
- SIP en RTP werden afzonderlijk gecontroleerd.
-Packet Capture toont heen en weer richting.
- SIP Helper is alleen specifiek getest.
- UDP-time-out is alleen gewijzigd met een gedocumenteerde beginwaarde.
- SD-WAN, VPN en meerdere WAN-lijnen zijn gecontroleerd.
- Traffic shaping wordt alleen gebruikt voor kwaliteitscontrole, niet als vervanging voor routing of NAT-correcties.

## Veelgestelde vragen







  
    Moet je de SIP Helper op Sophos Firewall altijd uitschakelen?
    
      Nee. Afhankelijk van de provider en het telefoonsysteem kan de SIP Helper helpen of hinderen. Het moet specifiek worden getest. Als deactivering geen verbetering oplevert, moet u de vorige status herstellen.
    
  









  
    Waarom werkt de oproep wel, maar hoor je niets?
    
      Dan werkt de SIP-signalering tenminste gedeeltelijk, maar loopt de RTP-mediastream niet correct. Je controleert het RTP-poortbereik, NAT, firewallregel, retourroute en, als er meerdere WAN-paden zijn, SD-WAN.
    
  









  
    Helpt een hogere UDP-time-out bij VoIP-problemen?
    
      Soms wel, vooral bij afgebroken oproepen of onstabiele registraties. De waarde heeft echter een bredere impact op UDP-sessies en moet daarom bewust, gedocumenteerd en niet onnodig hoog worden ingesteld.
    
  









  
    Wat is belangrijk aan VoIP via SD-WAN?
    
      SIP en RTP moeten via het verwachte pad lopen. Als retourvluchten verschillende WAN-lijnen of VPN-paden gebruiken, kunnen er eenzijdige audio of geweigerde verbindingen optreden.