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.

Sophos Firewall ondersteunt naast SIP ook H.323. Dit runbook richt zich op SIP-signalering en RTP. Als het telefoonsysteem daadwerkelijk H.323 gebruikt, moeten de H.323-service en de H.323 Helper afzonderlijk worden gecontroleerd; SIP Helper-instellingen zijn dan niet automatisch het juiste aangrijpingspunt.

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:

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 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, UDP Timeout en DoS 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 de SIP-module als standaard ingeschakeld. Wijzigingen met load of unload blijven ook na een herstart behouden.

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.

Toon de actuele status voor en na elke wijziging met een alleen-lezen opdracht:

system system_modules show

Documenteer de uitvoer voor de vermelding sip. Zo blijft duidelijk of de Helper vóór de test was geladen en welke status na de rollback wordt verwacht.

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.

Als de provider een aangepaste SIP-signaleringspoort gebruikt in plaats van UDP 5060, kan de Helper met precies die poort worden geladen:

system system_modules sip load ports <custom_port>

Vervang <custom_port> door de SIP-poort die de provider of PBX-fabrikant opgeeft, niet door een volledig RTP-poortbereik. De SIP Helper ondersteunt mediapoorten van 1024 tot 65535. Ligt een gebruikte mediapoort buiten dit bereik, dan kan de firewall het verkeer weggooien en verschijnt Invalid Traffic in het eventlogboek.

SIP via TCP heeft nog een beperking: de Helper ondersteunt geen SIP- of SDP-bericht dat over meerdere pakketten is verdeeld. Als Packet Capture precies dit patroon toont, moet het transport met de provider en PBX-fabrikant worden afgestemd. Overschakelen op SIP via UDP is alleen zinvol als beide kanten dit ondersteunen.

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

De actuele SFOS 22-help noemt 60 seconden als standaardwaarde voor UDP Timeout Stream en beveelt voor VoIP 150 seconden aan. De werkelijk weergegeven waarde en de specificatie van de provider blijven echter bepalend. Als Packet Capture en het afbreekmoment wijzen op een te korte stream-time-out, kan de gedocumenteerde waarde gecontroleerd worden getest:

set advanced-firewall udp-timeout-stream 150

⚠️ 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.

Drempelwaarden voor UDP flood controleren

VoIP genereert veel UDP-pakketten. Als de drempelwaarden onder Intrusion prevention > DoS & spoof protection > DoS settings te laag zijn, kan de firewall legitiem SIP- of RTP-verkeer als UDP flood weggooien. Documenteer vóór een wijziging de actuele waarden voor Packet rate, Burst rate en Apply flag, evenals de drop counters.

Sophos noemt het tijdelijk verwijderen van de Apply flag voor UDP flood als diagnostische test. Dit verlaagt tijdens de test de DoS-bescherming en hoort daarom thuis in een onderhoudsvenster met een nauw afgebakende testcase. Als VoIP hierdoor verbetert, worden Packet rate en Burst rate aangepast aan de gemeten legitieme belasting en wordt Apply flag opnieuw ingesteld. Blijft het probleem ongewijzigd, herstel dan onmiddellijk de uitgangssituatie.

Een gerichte uitzondering voor bekende hosts of poorten kan veiliger zijn dan een globale uitschakeling. Spoof Protection en DoS-bescherming op Sophos Firewall legt uit hoe drempelwaarden en DoS bypass rules samenwerken. De bescherming mag na de test niet uitgeschakeld blijven.

Probleemoplossing en bewijsmateriaal

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. Controleer de status van SIP Helper, test wijzigingen gericht en documenteer de resultaten.
10. Pas een UDP-time-out alleen bewust aan nadat de oude waarde is gedocumenteerd.
11. Controleer bij UDP-drops of kwaliteitsproblemen onder belasting de drempelwaarden voor UDP flood op een gecontroleerde manier.
12. 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.
• Eventlogboek en DoS-counters: Invalid Traffic of oplopende UDP-flood-drops helpen het Helper-poortbereik en de DoS-drempelwaarden af te bakenen.
• 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.
• Aangepaste SIP-poort verward met het RTP-poortbereik: De Helper wordt op de verkeerde signaleringspoort geladen.
• UDP-time-out zeer hoog ingesteld: Globale UDP-sessies blijven onnodig lang open.
• UDP-flood-bescherming te streng of permanent uitgeschakeld: Legitieme spraakpakketten worden weggegooid of de bescherming blijft na de test onnodig beperkt.
• 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, unload of een aangepaste poort en de gewenste eindstatus gedocumenteerd
• oorspronkelijke UDP-flood-drempelwaarden en Apply flags gedocumenteerd en na de test hersteld
• 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.
• De status van SIP Helper is vóór en na de gerichte test gecontroleerd.
• Een aangepaste SIP-poort komt overeen met de specificatie van de provider of PBX en wordt niet verward met het RTP-poortbereik.
• UDP-time-out is alleen gewijzigd met een gedocumenteerde beginwaarde.
• De drempelwaarden voor UDP flood en de DoS-bescherming zijn na de test in een veilige eindtoestand gebracht.
• 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