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.

Dit artikel beschrijft VoIP-probleemoplossing op Sophos Firewall als een gestructureerd proces. Bekende snelle oplossingen, zoals SIP Helper uitschakelen of een UDP-time-out verhogen, zijn slechts gecontroleerde tests. Bepaal eerst het pakketpad, de daadwerkelijk gebruikte firewall- en NAT-regels en analyseer SIP en RTP afzonderlijk.

SIP, RTP en symptomen begrijpen

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.

De uitgangssituatie vastleggen vóór wijzigingen

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 de regelanalyse. Voor de werkelijke pakketstroom is Packet Capture in WebAdmin meestal informatiever dan alleen een Policy Test. Wijzig globale CLI-waarden pas wanneer deze baseline en een reproduceerbare testoproep beschikbaar zijn.

Pakketpad, routing en kwaliteit controleren

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

Of een inkomende SIP-trunk DNAT nodig heeft, hangt af van het ontwerp van de provider. Op registratie gebaseerde trunks kunnen de bestaande uitgaande sessie gebruiken. Trunks die rechtstreeks op een openbaar adres worden afgeleverd, of gepubliceerde telefoonsystemen, hebben doorgaans een nauw afgebakende DNAT-regel nodig. De eisen van de provider of SBC-beheerder zijn bepalend.

Als DNAT nodig is, controleer dan ook deze punten:

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. Als een PBX via internet bereikbaar moet zijn, is Publiceerserver via DNAT 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:

Let op het RTP-poortbereik van de provider of de PBX.
Start Packet Capture met bron-IP van de PBX of telefoon en RTP-poortbereik.
Voer een testoproep uit.
Controleer of UDP-pakketten van het interne apparaat naar de provider zichtbaar zijn.
Controleer of UDP-pakketten terugkeren van de provider.
Vergelijk NAT ID, Rule ID, In interface en Out interface.

Als RTP alleen uitgaand zichtbaar is en niets terugkomt, kan het probleem bij de provider, het retourpad, NAT of een upstream-apparaat liggen. Als RTP terugkomt maar niet naar de PBX wordt doorgestuurd, zijn de firewallregel, DNAT, routing of zonetoewijzing 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.

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. 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. Voor VoIP moet u niet alleen na de implementatie snelheidstests controleren, maar ook echte testoproepen uitvoeren bij gelijktijdige belasting.

SIP Helper en UDP Timeout gecontroleerd testen

De volgende instellingen zijn niet beperkt tot één VoIP-regel. Test ze daarom pas nadat de oorzaak is afgebakend, met een gedocumenteerde baseline, een onderhoudsvenster en een duidelijk rollback-plan.

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 SIP Helper een nuttig testpunt, maar geen algemene permanente oplossing. Sophos documenteert dat systeemmodules standaard zijn geladen.

De opdrachten worden via SSH op Sophos Firewall uitgevoerd in 4. Device Console. Sta SSH-toegang alleen toe vanaf vertrouwde netwerken. De basis staat in Via SSH verbinden met Sophos Firewall.

De SFOS 22 CLI-help documenteert load en unload voor de SIP-module, maar geen algemene opdracht system system_modules show. Leg daarom de bekende beginsituatie en elke uitgevoerde opdracht vast in het onderhoudslogboek in plaats van op een veronderstelde statusopdracht te vertrouwen.

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.

Sophos onderscheidt twee globale waarden:

udp-timeout geldt voor UDP-verbindingen die nog niet als bidirectionele stream zijn herkend.
udp-timeout-stream geldt voor gevestigde UDP-streams waarbij beide eindpunten verkeer via dezelfde poort tussen netwerksegmenten hebben verzonden.

In SFOS 22 accepteren beide waarden 30 tot 3600 seconden. Toon de huidige Advanced Firewall-waarden 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.

180 seconden is een veelgebruikt voorbeeld voor probleemoplossing, geen algemene Sophos-aanbeveling. Als Packet Capture en het afbreekmoment wijzen op een te korte stream-time-out, test de waarde dan gecontroleerd:

set advanced-firewall udp-timeout-stream 180

⚠️ udp-timeout-stream is geen optie van één VoIP-regel. De instelling beïnvloedt alle overeenkomende UDP-streams. Verhoog de waarde niet op goed geluk of willekeurig. Noteer vóór de test de oude waarde uit show advanced-firewall en herstel die met dezelfde set-opdracht als de test niet helpt.

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.

Probleemoplossing en bewijsmateriaal

Praktische probleemoplossingsstroom

Documentsymptomen: registratie, oproepconfiguratie, audio, afbreektijd, richting.
Verzamel providergegevens: SIP-server, transport, RTP-poortbereik, NAT-vereisten.
Identificeer de firewallregel en NAT-regel.
Activeer het inloggen op de betreffende firewallregel.
Open Log Viewer en Packet Capture tijdens een testoproep.
Controleer of de SIP-signalering in beide richtingen loopt.
Controleer of RTP in beide richtingen werkt.
Als er meerdere WAN-lijnen zijn, controleer dan SD-WAN en retourpad.
Test SIP Helper specifiek en documenteer de resultaten.
Pas een UDP-time-out alleen bewust aan nadat de oude waarde is gedocumenteerd.
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. Welk logbestand bij welke dienst hoort, staat beschreven in Sophos Firewall Troubleshooting: services en 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.

Wijzigingen gecontroleerd terugdraaien

Bij VoIP-wijzigingen moet altijd duidelijk zijn hoe ze worden teruggedraaid:

oude waarden van udp-timeout en udp-timeout-stream gedocumenteerd als ze worden gewijzigd
SIP-test met load of unload en de gewenste eindstatus gedocumenteerd
gewijzigde firewall- en NAT-regels vastgelegd met datum en reden
testoproepen geregistreerd met richting en tijd
Packet Capture of relevante logboeken bewaard voor supportcases

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 de heen- en terugrichting.
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.