Sophos Firewall Åtgärda VoIP-problem med SIP och RTP

VoIP-problem bakom en Sophos Firewall har ofta en diffus effekt: telefoner registreras inte, samtal avbryts, den ringer utan ljud eller tal kan bara höras i en riktning. I praktiken beror orsaken sällan på en enda switch. SIP-signalering, RTP-mediaström, NAT, brandväggsregler, UDP-timeouts eller routing fungerar vanligtvis tillsammans.

Artikeln beskriver VoIP-felsökning på Sophos Firewall som en strukturerad process. Vanliga snabbåtgärder som att inaktivera SIP Helper eller öka UDP-timeout är endast kontrollerade tester. Börja med att kontrollera den berörda paketvägen, de brandväggs- och NAT-regler som faktiskt används samt SIP och RTP var för sig.

Förstå SIP, RTP och symtomen

Det som går genom brandväggen med VoIP

VoIP består ungefär av två delar:

• SIP: styr registrering, samtalsinställningar, samtalsrensning och förhandling av mediaparametrar. Typiska fel inkluderar misslyckad registrering, samtal som inte upprättas eller SIP-dialoger som avvisats av leverantören.
• RTP: transporterar röstdata under samtalet. Typiska fel är att ljud saknas, bara hörs i en riktning eller bryts efter en kort stund.

SIP körs ofta över UDP eller TCP 5060, och krypterad SIP ofta över 5061. Det är dock ingen fast regel. Många leverantörer använder egna portar, proxyservrar eller ytterligare krav på NAT Keepalive.

RTP använder vanligtvis UDP-portintervall som anges av leverantören, telefonsystemet eller slutenheterna. För en ren analys behöver du specifika SIP-servrar, RTP-portintervall och transportprotokoll från leverantören eller PBX-dokumentationen.

Klassificera symtomen korrekt

Innan du gör några ändringar bör du klassificera symtomen så noggrant som möjligt.

• Registrering misslyckas: Kontrollera DNS, routing, brandväggsregel, NAT, leverantörsuppgifter eller SIP-transport.
• Samtalet ansluter inte: Kontrollera SIP-signalering, brandväggsregel, Application Control och eventuella leverantörsblockeringar.
• Samtalet fungerar men inget ljud: Kontrollera RTP-portintervall, NAT, returväg, SD-WAN och SIP Helper.
• Ljud är bara hörbart i en riktning: Kontrollera RTP-returväg, NAT, routing, VPN och SD-WAN.
• Konversationen avbryts efter 30, 60 eller 120 sekunder: Kontrollera UDP-timeout, NAT Keepalive, sessionsuppdatering och leverantörens förväntningar.
• Endast inkommande samtal fungerar inte: Kontrollera DNAT, brandväggsregel, leverantörens källnät och PBX-portdelning.
• Endast en WAN-linje orsakar problem: Kontrollera SD-WAN-rutt, svarsväg, gateway och leverantörs IP-bindning.

Denna klassificering hindrar dig från att ändra SIP-inställningar även om det faktiska problemet ligger i RTP-returvägen eller en SD-WAN-rutt.

Dokumentera utgångsläget före ändringar

Innan du gör CLI-ändringar bör du dokumentera aktuell status:

• Vilka telefoner, PBX eller SBC påverkas?
• Registrerar slutenheterna direkt hos leverantören eller går allt via ett internt telefonsystem?
• Vilka SIP-servrar och RTP-portintervall namnger leverantören?
• Vilken brandväggsregel behandlar VoIP-trafiken?
• Är Log firewall traffic aktiverat i den här regeln?
• Vilken NAT-regel gäller för utgående och inkommande VoIP-trafik?
• Finns det flera WAN-linjer, SD-WAN-rutter eller ruttbaserade VPN:er?
• Blev problemet synligt efter en firmwareuppgradering, leverantörsbyte eller PBX-uppdatering?

Testa brandväggsregler på Sophos Firewall hjälper till med regelanalys. För det faktiska paketflödet är Packet Capture i WebAdmin vanligtvis mer informativt än ett rent policytest. Ändra globala CLI-värden först när det finns ett reproducerbart testsamtal och denna baslinje är dokumenterad.

Kontrollera paketflöde, routing och kvalitet

Kontrollera brandväggsregler och NAT

NAT är ofta involverad i VoIP-problem. Sophos Firewall måste inte bara tillåta SIP, utan också korrekt översätta och returnera de associerade RTP-strömmarna i båda riktningarna.

Dessa punkter är vanligtvis relevanta för utgående telefoner eller en intern växel:

• lämplig brandväggsregel från VoIP-zonen eller PBX-zonen till WAN
• lämplig SNAT- eller MASQ-regel
• Logga in brandväggsregeln
• ingen regel som är för bred eller felaktigt placerad ovanför VoIP-regeln
• ingen oväntad Application Control, IPS eller webbfiltrering på denna trafik

Om en inkommande SIP-trunk verkligen behöver DNAT beror på leverantörens utformning. Registreringsbaserade trunkar kan använda den befintliga utgående sessionen. Trunkar som levereras direkt till en offentlig adress eller publicerade telefonsystem behöver däremot oftast en riktad DNAT-publicering. Leverantörens eller SBC-operatörens krav är avgörande.

Om DNAT behövs tillkommer följande punkter:

• DNAT till intern PBX eller SBC
• Brandväggsregel med lämplig målzon och målnätverk
• Begränsning till leverantörens källnät, om möjligt
• endast nödvändiga SIP- och RTP-portar
• Loggning och Packet Capture för testning

En NAT-regel tillåter inte trafik, utan översätter endast adresser eller portar. Anslutningarna förklaras i Förstå NAT på Sophos Firewall. Om en telefonväxel behöver vara tillgänglig från Internet är Publicera server via DNAT den bättre grunden för själva publiceringen.

Analysera RTP och språkriktning

Om samtalet upprättas men ljud saknas är SIP vanligtvis inte längre huvudfrågan. Sedan måste du kontrollera om RTP flyter åt båda hållen.

Typisk process:

1. Notera leverantörens eller PBX RTP-portintervall.
2. Starta Packet Capture med käll-IP för telefonväxeln eller telefonen och RTP-portområdet.
3. Ring ett testsamtal.
4. Kontrollera om UDP-paket från den interna enheten till leverantören är synliga.
5. Kontrollera om UDP-paket returneras från leverantören.
6. Jämför NAT ID, Rule ID, In interface och Out interface.

Om RTP endast är synlig utgående men ingenting kommer tillbaka, kan problemet ligga hos leverantören, returvägen, NAT eller en uppströms motpart. Om RTP kommer tillbaka men inte vidarebefordras till telefonväxeln är brandväggsregeln, DNAT, routing eller zontilldelningen mer sannolik.

För mer exakta inspelningar eller PCAP-export kan tcpdump via SSH vara användbart. Processen beskrivs i Sophos Firewall Använd tcpdump för loggar och analys.

SD-WAN, VPN och flera WAN-linjer

VoIP är känsligt för asymmetriska vägar. Om SIP körs över en WAN-linje men RTP återvänder över en annan linje eller om ett ruttbaserat VPN dirigeras annorlunda, uppstår typiska fel som ensidigt ljud.

En bugg fixad i SFOS 22.0 MR1 visar den typiska anslutningen: Efter en uppgradering till SFOS 22.0 GA kunde VoIP-ljud bara fungera envägs över ruttbaserad VPN med SD-WAN-routing. I praktiken betyder detta: SD-WAN bör alltid kontrolleras när du använder VoIP över VPN eller flera WAN-vägar.

Viktiga kontrollpunkter:

• Har en SD-WAN-rutt åtkomst till VoIP-trafik?
• Leds SIP och RTP över samma förväntade WAN-linje?
• Finns det leverantörsspecifikationer angående käll-IP eller offentlig avsändaradress?
• Används en ruttbaserad VPN-rutt med ett XFRM-gränssnitt?
• Matchar returrutter och NAT den valda vägen?
• Visar Packet Capture olika gateways eller gränssnitt för ut- och returriktningar?

För Sophos-specifika SD-WAN-alternativ passar SD-WAN-dirigering av svarspaket och systemtrafik. Sophos Firewall IPsec-felsökning hjälper också till med IPsec-anslutningar.

Trafikformning för VoIP

Trafikformning kan stabilisera VoIP när linjerna är trånga eller stora uppladdningar förskjuter röstpaket. Det löser dock inte felaktiga NAT-regler, saknade RTP-portar och felaktiga returvägar.

Trafikformning är särskilt användbar om:

• VoIP blir värre när internetlinjen är under belastning,
• Uppladdningar eller säkerhetskopior stör konversationer,
• flera applikationer använder samma linje,
• VoIP bör prioriteras specifikt.

Konfigurationen beskrivs i Application Traffic Shaping på Sophos Firewall. För VoIP bör du inte bara kontrollera hastighetstester efter implementering, utan också utföra riktiga testsamtal med samtidig belastning.

Testa SIP Helper och UDP Timeout kontrollerat

Följande inställningar påverkar inte bara en enskild VoIP-regel. Testa dem därför först efter en avgränsad analys och med dokumenterat utgångsvärde, underhållsfönster och tydlig återställningsplan.

Kontrollera SIP Helper

SIP Helper, ofta även kallad SIP ALG, försöker känna igen SIP-paket och anpassa NAT-relevant SIP-information. Detta kan hjälpa i enkla miljöer. Det kan dock också vara störande i många moderna VoIP-uppställningar med leverantörens SBC, egen PBX, TLS, clean NAT Keepalive eller mer komplexa RTP-portintervall.

SIP Helper är därför en relevant testpunkt, men ingen generell permanent lösning för alla problem. Sophos dokumenterar systemmodulerna som inlästa som standard.

Kommandona körs via SSH på Sophos Firewall. Anslut till brandväggen och välj 4. Device Console. SSH-åtkomst bör endast tillåtas från betrodda nätverk. Grunderna finns i Anslut till Sophos Firewall via SSH.

CLI-hjälpen för SFOS 22 dokumenterar load och unload för SIP-modulen, men inget allmänt kommando system system_modules show. Arbeta därför inte med ett förmodat statuskommando. Dokumentera i stället det kända utgångsläget och varje utförd ändring i underhållsprotokollet.

Inaktivera SIP-modul:

system system_modules sip unload

Återaktivera SIP-modulen:

system system_modules sip load

⚠️ Denna ändring bör göras i ett underhållsfönster eller med tydligt definierade tester. Efter inaktivering eller aktivering måste registrering, utgående samtal, inkommande samtal och ljud kontrolleras i båda riktningarna.

Om förändringen inte hjälper bör du ta tillbaka den. Det är viktigt att dokumentera tillståndet före och efter testet.

Kontrollera och justera UDP-timeout

VoIP använder ofta UDP. Om NAT- eller sessionsposter går ut för tidigt kan en registrering tyckas fungera, men samtal tappas eller inkommande samtal når inte växeln på ett tillförlitligt sätt.

Sophos skiljer mellan två globala värden:

• udp-timeout gäller UDP-anslutningar som ännu inte har identifierats som en dubbelriktad ström.
• udp-timeout-stream gäller etablerade UDP-strömmar där båda ändpunkterna har skickat trafik på samma port mellan nätverkssegment.

Båda värdena stöder intervallet 30 till 3600 sekunder i SFOS 22. Den aktuella avancerade brandväggsstatusen visas i Device Console:

show advanced-firewall

180 sekunder är ett vanligt felsökningsexempel, men ingen generell rekommendation från Sophos. Om paketinfångningen och avbrottstiden tyder på en för kort stream-timeout kan värdet testas kontrollerat:

set advanced-firewall udp-timeout-stream 180

⚠️ udp-timeout-stream är inte en ren VoIP-regelinställning utan påverkar alla matchande UDP-strömmar. Sätt inte värdet på misstanke eller godtyckligt högt. Notera det gamla värdet från show advanced-firewall före testet och återställ det med samma set-kommando om testet inte hjälper.

Om leverantören eller telefonsystemet stöder NAT Keepalive bör även denna inställning kontrolleras. En ren keepalive på PBX- eller leverantörssidan är ofta bättre än ett mycket högt globalt timeoutvärde.

Felsökning och underlag

Praktiskt felsökningsflöde

1. Dokumentsymptom: registrering, samtalsinställningar, ljud, avbrytningstid, riktning.
2. Samla leverantörsdata: SIP-server, transport, RTP-portintervall, NAT-krav.
3. Identifiera brandväggsregel och NAT-regel.
4. Aktivera inloggning i den berörda brandväggsregeln.
5. Öppna Log Viewer och Packet Capture under ett testsamtal.
6. Kontrollera om SIP-signalering går i båda riktningarna.
7. Kontrollera om RTP körs i båda riktningarna.
8. Om det finns flera WAN-linjer, kontrollera SD-WAN och returväg.
9. Testa SIP Helper specifikt och dokumentera resultaten.
10. Justera endast UDP-timeout medvetet och med det gamla värdet dokumenterat.
11. Testa registrering, utgående samtal, inkommande samtal och ljud i båda riktningarna efter varje ändring.

Om flera ändringar görs samtidigt är den efterföljande orsaken svår att förstå. Ett test per byte är bättre.

Samla bevis under ett testsamtal

Ett VoIP-test är bara användbart om tid, riktning och paketflöde matchar. Särskilt i leverantörsfall räcker inte uttalandet “Ljud fungerar inte”. Du behöver ett litet, reproducerbart testfall.

• Exakt tid med tidszon: Log Viewer, Packet Capture och leverantörsloggar kan enkelt jämföras senare.
• Samtalsriktning: Inkommande samtal, utgående samtal och intern vidarekoppling blandas inte.
• Telefonnummer eller anknytningar: Leverantörer och PBX:er hittar det specifika samtalet snabbare.
• Intern IP för PBX eller telefon: Packet Capture kan filtreras snävt.
• Leverans SIP-server och RTP-portintervall: SIP- och RTP-analys förblir separata.
• Rule ID, NAT ID, In interface och Out interface: du kan se vilken regel och vilken sökväg som faktiskt användes.
• Resultat per test: Registrering, ringsignal, samtalsinställningar, ljud vänster/höger och avslutningstid förblir spårbara.

Vid sporadiska fel bör du även säkerhetskopiera relevanta loggar innan de skrivs över. För ett rent stockpaket passar Sophos Firewall Säkerhetskopiera loggar för support och analys. Vilken loggfil som tillhör vilken tjänst beskrivs i Sophos Firewall Felsökning: tjänster och loggar.

Vanliga fel

• Endast SIP-port aktiverad, glömde RTP-portintervall: Samtalet ställs in men ljud saknas.
• NAT-regel finns, men ingen matchande brandväggsregel: Trafik är översatt men inte tillåten.
• Brandväggsregel utan loggning: Felsökning i Log Viewer förblir blind.
• SIP Helper inaktiverad eller aktiverad över hela linjen: Problemet flyttas slumpmässigt istället för att analyseras.
• UDP-timeout satt mycket högt: Globala UDP-sessioner förblir öppna onödigt länge.
• Flera WAN-vägar utan en tydlig SD-WAN-regel: Envägsljud eller trafik avvisad från leverantören blir mer sannolikt.
• Providerns källnät är inte begränsade: SIP-tjänsten är onödigt brett tillgänglig från Internet.
• Trafikformning förstås som en ersättning för NAT/routing: Röstkvaliteten förblir dålig eftersom orsaken ligger någon annanstans.

Återställ ändringar kontrollerat

När du gör VoIP-ändringar bör det alltid vara tydligt hur du återgår till utgångsläget:

• gamla värden för udp-timeout och udp-timeout-stream dokumenterade om de ändras
• utfört SIP-load- eller unload-test och önskat sluttillstånd dokumenterade
• Ändrade brandväggs- och NAT-regler noterade med datum och anledning
• Testsamtal loggade med riktning och tid
• Packet Capture eller relevanta loggar säkrade för supportärenden

Om förändringen inte hjälper bör den inte lämnas som ett oavsiktligt arv. Särskilt VoIP-lösningar kommer annars att bli svåra att förstå senare.

Checklista

• Leverantörs SIP- och RTP-information är tillgänglig.
• Brandväggsregeln för VoIP identifieras och loggning är aktiv.
• NAT-regeln matchar trafikriktningen.
• SIP och RTP kontrollerades separat.
• Packet Capture visar riktning fram och tillbaka.
• SIP Helper testades endast specifikt.
• UDP-timeout ändrades endast med ett dokumenterat initialvärde.
• SD-WAN, VPN och flera WAN-linjer kontrollerades.
• Trafikformning används endast för kvalitetskontroll, inte som ersättning för routing eller NAT-korrigeringar.

Vanliga frågor