Sophos Firewall Résoudre les problèmes de VoIP avec SIP et RTP

Les problèmes VoIP derrière un Sophos Firewall ont souvent un effet diffus : les téléphones ne s’enregistrent pas, les appels sont interrompus, il sonne sans son ou la parole ne peut être entendue que dans une seule direction. En pratique, la cause est rarement due à un seul interrupteur. La signalisation SIP, le flux multimédia RTP, le NAT, les règles de pare-feu, les délais d’attente UDP ou le routage fonctionnent généralement ensemble.

Cet article présente le dépannage VoIP sur Sophos Firewall sous la forme d’un processus structuré. Les solutions rapides courantes, comme désactiver SIP Helper ou augmenter un délai UDP, ne sont que des tests contrôlés. Il faut d’abord identifier le chemin des paquets, les règles de pare-feu et NAT réellement utilisées, puis analyser SIP et RTP séparément.

Comprendre SIP, RTP et les symptômes

Qu’est-ce qui traverse le pare-feu avec la VoIP

La VoIP se compose grosso modo de deux parties :

• SIP : contrôle l’enregistrement, l’établissement des appels, la libération des appels et la négociation des paramètres multimédias. Les erreurs typiques incluent l’échec de l’enregistrement, les appels non établis ou les boîtes de dialogue SIP rejetées par le fournisseur.
• RTP : transporte les données vocales pendant la conversation. Les erreurs typiques sont l’absence de son, le son unidirectionnel ou une coupure après un court délai.

SIP utilise souvent UDP ou TCP 5060, et SIP chiffré utilise fréquemment 5061. Ces valeurs ne sont pas universelles. De nombreux fournisseurs utilisent d’autres ports, des serveurs proxy ou des exigences NAT keepalive supplémentaires.

RTP utilise généralement des plages de ports UDP spécifiées par le fournisseur, le système téléphonique ou les appareils finaux. Pour une analyse claire, vous avez besoin des serveurs SIP spécifiques, des plages de ports RTP et des protocoles de transport du fournisseur ou de la documentation du PBX.

Sophos Firewall prend également en charge H.323 en plus de SIP. Ce runbook se concentre sur la signalisation SIP et RTP. Si le système téléphonique utilise réellement H.323, le service H.323 et le H.323 Helper doivent être vérifiés séparément ; les paramètres du SIP Helper ne sont alors pas automatiquement le bon levier.

Classer correctement les symptômes

Avant d’apporter des modifications, vous devez classer le symptôme aussi précisément que possible.

• Échec de l’enregistrement : Vérifiez le DNS, le routage, la règle de pare-feu, le NAT, les informations d’identification du fournisseur ou le transport SIP.
• L’appel ne se connecte pas : Vérifiez la signalisation SIP, la règle de pare-feu, Application Control et les éventuels blocages du fournisseur.
• L’appel fonctionne mais pas d’audio : Vérifiez la plage de ports RTP, NAT, l’itinéraire de retour, SD-WAN et SIP Helper.
• L’audio n’est audible que dans une seule direction : Vérifiez le chemin de retour RTP, NAT, le routage, le VPN et le SD-WAN.
• La conversation s’interrompt après 30, 60 ou 120 secondes : Vérifiez le délai d’expiration UDP, le maintien NAT, l’actualisation de la session et les attentes du fournisseur.
• Seuls les appels entrants ne fonctionnent pas : Vérifiez le DNAT, la règle de pare-feu, les réseaux sources du fournisseur et le partage de port PBX.
• Une seule ligne WAN pose problème : Vérifiez l’itinéraire SD-WAN, le chemin de réponse, la passerelle et la liaison IP du fournisseur.

Cette classification vous empêche de modifier les paramètres SIP même si le problème réel réside dans le chemin de retour RTP ou une route SD-WAN.

Relever la situation initiale avant toute modification

Avant d’apporter des modifications à la CLI, vous devez documenter l’état actuel :

• Quels téléphones, PBX ou SBC sont concernés ?
• Les appareils finaux s’enregistrent-ils directement auprès du fournisseur ou tout se déroule-t-il via un système téléphonique interne ?
• Quels serveurs SIP et plages de ports RTP le fournisseur nomme-t-il ?
• Quelle règle de pare-feu traite le trafic VoIP ?
• Log firewall traffic est-il activé dans cette règle ?
• Quelle règle NAT s’applique au trafic VoIP sortant et entrant ?
• Existe-t-il plusieurs lignes WAN, routes SD-WAN ou VPN basés sur des routes ?
• Le problème est-il devenu visible après une mise à niveau du micrologiciel, un changement de fournisseur ou une mise à jour du PBX ?

Tester les règles de pare-feu sur Sophos Firewall aide à l’analyse des règles. Pour le flux de paquets réel, Packet Capture dans WebAdmin est généralement plus parlant qu’un simple Policy Test. Les valeurs CLI globales ne doivent être modifiées qu’une fois cette situation initiale et un appel test reproductible disponibles.

Vérifier le chemin des paquets, le routage et la qualité

Vérifiez les règles de pare-feu et le NAT

NAT est souvent impliqué dans les problèmes de VoIP. Le Sophos Firewall doit non seulement autoriser le SIP, mais aussi traduire et renvoyer correctement les flux RTP associés dans les deux sens.

Ces points sont généralement pertinents pour les téléphones sortants ou un PBX interne :

• règle de pare-feu appropriée de la zone VoIP ou de la zone PBX vers le WAN
• règle SNAT ou MASQ appropriée
• Connexion à la règle de pare-feu
• pas de règle trop large ou mal positionnée au dessus de la règle VoIP
• aucune Application Control, IPS ou Web Filtering inattendue sur ce trafic

La nécessité d’une règle DNAT pour un trunk SIP entrant dépend de la conception du fournisseur. Un trunk basé sur un enregistrement peut utiliser la session sortante existante. Un trunk remis directement à une adresse publique ou un système téléphonique publié nécessite généralement une règle DNAT strictement limitée. Les exigences du fournisseur ou de l’opérateur SBC font foi.

Si DNAT est nécessaire, vérifier également les points suivants :

• DNAT vers le PBX ou SBC interne
• Règle de pare-feu avec zone cible et réseau cible appropriés
• Restriction aux réseaux sources du fournisseur, si possible
• uniquement les ports SIP et RTP requis
• Journalisation et Packet Capture pour les tests

Une règle NAT n’autorise pas le trafic, mais traduit uniquement les adresses ou les ports. Les connexions sont expliquées dans Comprendre NAT sur Sophos Firewall. Si un PBX doit être accessible depuis Internet, Serveur de publication via DNAT constitue la meilleure base pour la publication proprement dite.

Analyser le RTP et la direction du langage

Si l’appel est établi mais que l’audio manque, le SIP n’est généralement plus le problème principal. Ensuite, vous devez vérifier si le RTP circule dans les deux sens.

Processus typique :

1. Notez la plage de ports RTP du fournisseur ou du PBX.
2. Démarrez Packet Capture avec l’IP source du PBX ou du téléphone et la plage de ports RTP.
3. Effectuez un appel test.
4. Vérifiez si les paquets UDP du périphérique interne vers le fournisseur sont visibles.
5. Vérifiez si les paquets UDP reviennent du fournisseur.
6. Comparez NAT ID, Rule ID, In interface et Out interface.

Si RTP n’est visible qu’en sortie et que rien ne revient, le problème peut provenir du fournisseur, du chemin de retour, du NAT ou d’un équipement en amont. Si RTP revient mais n’est pas transmis au PBX, la règle de pare-feu, le DNAT, le routage ou l’affectation de zone sont plus probablement en cause.

Pour des enregistrements plus précis ou un export PCAP, tcpdump via SSH peut être utile. Le processus est décrit dans Sophos Firewall Utiliser tcpdump pour les journaux et les analyses.

SD-WAN, VPN et plusieurs lignes WAN

La VoIP est sensible aux chemins asymétriques. Si SIP s’exécute sur une ligne WAN mais que RTP revient sur une ligne différente ou qu’un VPN basé sur un itinéraire est acheminé différemment, des erreurs typiques telles qu’un son unilatéral se produisent.

Un bug corrigé dans SFOS 22.0 MR1 montre la connexion typique : après une mise à niveau vers SFOS 22.0 GA, l’audio VoIP ne pouvait fonctionner que dans un sens sur un VPN basé sur le routage avec un routage SD-WAN. En pratique, cela signifie : le SD-WAN doit toujours être vérifié lors de l’utilisation de VoIP sur VPN ou de plusieurs chemins WAN.

Points de contrôle importants :

• Une route SD-WAN accède-t-elle au trafic VoIP ?
• SIP et RTP sont-ils acheminés sur la même ligne WAN attendue ?
• Existe-t-il des spécifications du fournisseur concernant l’adresse IP source ou l’adresse publique de l’expéditeur ?
• Une route VPN basée sur une route avec une interface XFRM est-elle utilisée ?
• Les routes de retour et NAT correspondent-elles au chemin choisi ?
• Packet Capture affiche-t-il différentes passerelles ou interfaces pour les directions aller et retour ?

Pour les options SD-WAN spécifiques à Sophos, Paquet de réponse de routage SD-WAN et trafic système convient. Sophos Firewall Dépannage IPsec aide également avec les connexions IPsec.

Mise en forme du trafic pour la VoIP

La gestion du trafic peut stabiliser la VoIP lorsque les lignes sont étroites ou que des téléchargements volumineux déplacent les paquets vocaux. Cependant, cela ne résout pas les règles NAT incorrectes, les ports RTP manquants et les routes de retour incorrectes.

La gestion du trafic est particulièrement utile si :

• La VoIP s’aggrave lorsque la ligne Internet est en charge,
• Les téléchargements ou les sauvegardes perturbent les conversations,
• plusieurs applications utilisent la même ligne,
• La VoIP doit être spécifiquement prioritaire.

La configuration est décrite dans Mise en forme du trafic applicatif sur Sophos Firewall. Pour la VoIP, vous ne devez pas seulement vérifier les tests de vitesse après la mise en œuvre, mais également effectuer de véritables appels de test avec charge simultanée.

Tester SIP Helper, UDP Timeout et DoS de manière contrôlée

Les paramètres suivants affectent plus qu’une seule règle VoIP. Ils ne doivent être testés qu’après avoir circonscrit la cause, avec un état initial documenté, une fenêtre de maintenance et un rollback clair.

Vérifiez l’assistance SIP

Le SIP Helper, souvent également appelé SIP ALG, tente de reconnaître les paquets SIP et d’adapter les informations SIP pertinentes pour le NAT. Cela peut être utile dans des environnements simples. Cependant, cela peut également être perturbateur dans de nombreuses configurations VoIP modernes avec le fournisseur SBC, votre propre PBX, TLS, un keepalive NAT propre ou des plages de ports RTP plus complexes.

SIP Helper constitue donc un point de test utile, mais pas une solution permanente et universelle. Sophos indique que le module SIP est activé par défaut. Les modifications effectuées avec load ou unload persistent après un redémarrage.

Les commandes sont exécutées via SSH sur Sophos Firewall, dans 4. Device Console. L’accès SSH ne doit être autorisé que depuis des réseaux de confiance. Les bases sont décrites dans Se connecter à Sophos Firewall via SSH.

Afficher l’état actuel avant et après chaque modification avec une commande en lecture seule :

system system_modules show

La sortie correspondant à l’entrée sip doit être consignée. Il reste ainsi possible de vérifier si le Helper était chargé avant le test et quel état est attendu après le rollback.

Désactivez le module SIP :

system system_modules sip unload

Réactivez le module SIP :

system system_modules sip load

⚠️ Ce changement doit être effectué dans une fenêtre de maintenance ou avec des tests clairement définis. Après avoir désactivé ou activé, l’enregistrement, les appels sortants, les appels entrants et l’audio doivent être vérifiés dans les deux sens.

Si le changement ne vous aide pas, vous devriez le retirer. Il est important de documenter l’état avant et après le test.

Si le fournisseur utilise un port de signalisation SIP personnalisé au lieu d’UDP 5060, le Helper peut être chargé avec ce port précis :

system system_modules sip load ports <custom_port>

<custom_port> est remplacé par le port SIP spécifié par le fournisseur ou le constructeur du PBX, et non par une plage complète de ports RTP. Le SIP Helper prend en charge les ports multimédias de 1024 à 65535. Si un port multimédia se trouve hors de cette plage, le pare-feu peut rejeter le trafic et afficher Invalid Traffic dans le journal des événements.

SIP sur TCP présente une autre limite : le Helper ne prend pas en charge les messages SIP ou SDP répartis sur plusieurs paquets. Si Packet Capture montre exactement ce schéma, le transport doit être clarifié avec le fournisseur et le constructeur du PBX. Le passage à SIP sur UDP n’est pertinent que si les deux côtés le prennent en charge.

Vérifiez et ajustez le délai d’expiration UDP

La VoIP utilise souvent UDP. Si le NAT ou les entrées de session expirent trop tôt, un enregistrement peut sembler fonctionner, mais les appels sont interrompus ou les appels entrants n’atteignent pas le PBX de manière fiable.

Sophos distingue deux valeurs globales :

• udp-timeout s’applique aux connexions UDP qui ne sont pas encore reconnues comme un flux bidirectionnel.
• udp-timeout-stream s’applique aux flux UDP établis lorsque les deux extrémités ont envoyé du trafic sur le même port entre des segments réseau.

Dans SFOS 22, les deux valeurs acceptent une plage de 30 à 3600 secondes. Afficher les valeurs Advanced Firewall actuelles dans Device Console :

show advanced-firewall

L’aide actuelle de SFOS 22 indique 60 secondes comme valeur par défaut de UDP Timeout Stream et recommande 150 secondes pour la VoIP. La valeur réellement affichée et les exigences du fournisseur restent toutefois déterminantes. Si Packet Capture et l’heure de coupure indiquent un délai de flux trop court, la valeur documentée peut être testée de manière contrôlée :

set advanced-firewall udp-timeout-stream 150

⚠️ udp-timeout-stream n’est pas une option propre à une règle VoIP. Elle affecte tous les flux UDP correspondants. Ne pas l’augmenter par supposition ou de façon arbitraire. Noter l’ancienne valeur depuis show advanced-firewall et la restaurer avec la même commande set si le test échoue.

Si le fournisseur ou le système téléphonique prend en charge NAT keepalive, ce paramètre doit également être vérifié. Un keepalive propre du côté du PBX ou du fournisseur est souvent préférable à une valeur de délai d’attente globale très élevée.

Vérifier les seuils UDP flood

La VoIP génère de nombreux paquets UDP. Si les seuils sous Intrusion prevention > DoS & spoof protection > DoS settings sont trop bas, le pare-feu peut rejeter du trafic SIP ou RTP légitime comme UDP flood. Avant toute modification, consigner les valeurs actuelles de Packet rate, Burst rate et Apply flag, ainsi que les compteurs de paquets rejetés.

Sophos mentionne la suppression temporaire de l’Apply flag pour UDP flood comme test de diagnostic. Cette opération réduit la protection DoS pendant le test et doit donc être réalisée dans une fenêtre de maintenance avec un cas de test strictement défini. Si la VoIP s’améliore, adapter Packet rate et Burst rate à la charge légitime mesurée, puis réactiver Apply flag. Si le problème ne change pas, restaurer immédiatement l’état initial.

Une exception ciblée pour des hôtes ou ports connus peut être plus sûre qu’une désactivation globale. Spoof Protection et protection DoS sur Sophos Firewall explique l’interaction entre les seuils et les DoS bypass rules. La protection ne doit pas rester désactivée après le test.

Dépannage et éléments de preuve

Flux de dépannage pratique

1. Documenter les symptômes : enregistrement, configuration de l’appel, audio, heure d’abandon, direction.
2. Collectez les données du fournisseur : serveur SIP, transport, plage de ports RTP, exigences NAT.
3. Identifiez la règle de pare-feu et la règle NAT.
4. Activez la journalisation dans la règle de pare-feu concernée.
5. Ouvrez Log Viewer et Packet Capture lors d’un appel test.
6. Vérifiez si la signalisation SIP fonctionne dans les deux sens.
7. Vérifiez si RTP fonctionne dans les deux sens.
8. S’il existe plusieurs lignes WAN, vérifiez le SD-WAN et le chemin de retour.
9. Vérifiez l’état du SIP Helper, testez les modifications de manière ciblée et consignez les résultats.
10. Ajustez un délai UDP uniquement de manière délibérée et après avoir documenté l’ancienne valeur.
11. En cas de rejets UDP ou de problèmes de qualité sous charge, vérifiez les seuils UDP flood de manière contrôlée.
12. Après chaque changement, testez l’enregistrement, les appels sortants, les appels entrants et l’audio dans les deux sens.

Si plusieurs modifications sont apportées en même temps, la cause ultérieure est difficile à comprendre. Un test par changement est préférable.

Recueillir des preuves lors d’un appel test

Un test VoIP n’est utile que si l’heure, la direction et le flux des paquets correspondent. Surtout dans le cas des fournisseurs, la déclaration « L’audio ne fonctionne pas » n’est pas suffisante. Vous avez besoin d’un petit cas de test reproductible.

• Heure exacte avec fuseau horaire : Log Viewer, Packet Capture et les journaux du fournisseur peuvent être facilement comparés ultérieurement.
• Direction des appels : les appels entrants, les appels sortants et les renvois internes ne sont pas mélangés.
• Numéros de téléphone ou extensions : Les fournisseurs et les PBX trouvent l’appel spécifique plus rapidement.
• IP interne du PBX ou du téléphone : Packet Capture peut être filtré de manière étroite.
• Serveur SIP du fournisseur et plage de ports RTP : Les analyses SIP et RTP restent séparées.
• Rule ID, NAT ID, In interface et Out interface : vous pouvez voir quelle règle et quel chemin ont été réellement utilisés.
• Journal des événements et compteurs DoS : Invalid Traffic ou une augmentation des rejets UDP flood permettent de circonscrire la plage de ports du Helper et les seuils DoS.
• Résultat par test : L’enregistrement, la sonnerie, l’établissement de l’appel, l’audio gauche/droite et l’heure de fin restent traçables.

En cas d’erreurs sporadiques, vous devez également sauvegarder les journaux concernés avant qu’ils ne soient écrasés. Pour un package de journaux propre, Sophos Firewall Sauvegarder les journaux pour l’assistance et l’analyse convient. Quel fichier journal appartient à quel service est décrit dans Sophos Firewall Dépannage : services et journaux.

Erreurs courantes

• Seul le port SIP est activé, plage de ports RTP oubliée : L’appel est établi mais l’audio est manquant.
• Une règle NAT existe, mais aucune règle de pare-feu correspondante : Le trafic est traduit mais n’est pas autorisé.
• Règle de pare-feu sans journalisation : Le dépannage dans Log Viewer reste aveugle.
• SIP Helper désactivé ou activé à tous les niveaux : Le problème est déplacé de manière aléatoire au lieu d’être analysé.
• Port SIP personnalisé confondu avec la plage de ports RTP : Le Helper est chargé sur le mauvais port de signalisation.
• Délai d’expiration UDP très élevé : Les sessions UDP globales restent ouvertes inutilement longtemps.
• Protection UDP flood trop stricte ou désactivée en permanence : Des paquets vocaux légitimes sont rejetés ou la protection reste inutilement réduite après le test.
• Plusieurs chemins WAN sans règle SD-WAN claire : Le trafic audio unidirectionnel ou le trafic rejeté par le fournisseur deviennent plus probables.
• Réseaux sources du fournisseur non restreints : Le service SIP est inutilement largement accessible depuis Internet.
• Traffic shape compris comme remplacement du NAT/routage : La qualité de la voix reste mauvaise car la cause est ailleurs.

Annuler proprement les modifications

Pour toute modification VoIP, le retour arrière doit être clair :

• anciennes valeurs de udp-timeout et udp-timeout-stream documentées si elles sont modifiées
• test SIP load, unload ou de port personnalisé et état final attendu documentés
• seuils UDP flood et Apply flags d’origine documentés et restaurés après le test
• règles de pare-feu et NAT modifiées consignées avec la date et la raison
• appels test consignés avec leur direction et leur heure
• Packet Capture ou journaux pertinents conservés pour les cas de support

Si le changement n’aide pas, il ne faut pas le laisser comme un héritage accidentel. Les solutions de contournement VoIP en particulier deviendront autrement difficiles à comprendre plus tard.

Liste de contrôle opérationnelle

• Les informations SIP et RTP du fournisseur sont disponibles.
• La règle de pare-feu pour VoIP est identifiée et la journalisation est active.
• La règle NAT correspond au sens de la circulation.
• SIP et RTP ont été vérifiés séparément.
• Packet Capture montre le trafic dans les deux sens.
• L’état du SIP Helper a été vérifié avant et après le test ciblé.
• Un port SIP personnalisé correspond aux spécifications du fournisseur ou du PBX et n’est pas confondu avec la plage de ports RTP.
• Le délai d’expiration UDP n’a été modifié qu’avec une valeur initiale documentée.
• Les seuils UDP flood et la protection DoS ont été ramenés à un état final sûr après le test.
• SD-WAN, VPN et plusieurs lignes WAN ont été vérifiées.
• La mise en forme du trafic est utilisée uniquement pour le contrôle qualité, et non pour remplacer le routage ou les corrections NAT.

Questions fréquentes