Sophos Firewall Solucionar problemas de VoIP con SIP y RTP

Los problemas de VoIP detrás de un Sophos Firewall a menudo tienen un efecto difuso: los teléfonos no registran, las llamadas se cortan, suena sin audio o la voz solo se escucha en una dirección. En la práctica, la causa rara vez se debe a un solo interruptor. La señalización SIP, el flujo de medios RTP, NAT, las reglas de firewall, los tiempos de espera UDP o el enrutamiento suelen funcionar juntos.

Este artículo presenta el diagnóstico de VoIP en Sophos Firewall como un proceso estructurado. Las soluciones rápidas habituales, como desactivar SIP Helper o aumentar un tiempo de espera UDP, son solo pruebas controladas. Primero se debe identificar la ruta de los paquetes, las reglas de firewall y NAT realmente utilizadas, y analizar SIP y RTP por separado.

Comprender SIP, RTP y los síntomas

Qué tráfico VoIP atraviesa el firewall

VoIP consta aproximadamente de dos partes:

SIP: controla el registro, el establecimiento de llamadas, la liberación de llamadas y la negociación de parámetros de medios. Los errores típicos incluyen registro fallido, llamadas que no se establecen o diálogos SIP rechazados por el proveedor.
RTP: transporta los datos de voz durante la conversación. Los errores típicos son la ausencia de audio, el audio unidireccional o una interrupción tras poco tiempo.

SIP suele utilizar UDP o TCP 5060, y SIP cifrado suele utilizar 5061. Estos valores no son universales. Muchos proveedores emplean otros puertos, servidores proxy o requisitos adicionales de NAT keepalive.

RTP suele utilizar rangos de puertos UDP especificados por el proveedor, el sistema telefónico o los dispositivos finales. Para un análisis limpio, necesita los servidores SIP específicos, los rangos de puertos RTP y los protocolos de transporte del proveedor o la documentación de la PBX.

Sophos Firewall también admite H.323 además de SIP. Esta guía se centra en la señalización SIP y RTP. Si el sistema telefónico utiliza realmente H.323, el servicio H.323 y el H.323 Helper deben comprobarse por separado; los ajustes de SIP Helper no son entonces automáticamente el punto de intervención correcto.

Clasificar los síntomas correctamente

Antes de realizar cualquier cambio, debes clasificar el síntoma con la mayor precisión posible.

Error de registro: Verifique DNS, enrutamiento, regla de firewall, NAT, credenciales de proveedor o transporte SIP.
La llamada no se conecta: Verifique la señalización SIP, la regla del firewall, Application Control y posibles bloqueos del proveedor.
La llamada funciona pero no hay audio: Verifique el rango de puertos RTP, NAT, ruta de regreso, SD-WAN y SIP Helper.
El audio solo se escucha en una dirección: Verifique la ruta de retorno RTP, NAT, enrutamiento, VPN y SD-WAN.
La conversación se interrumpe después de 30, 60 o 120 segundos: Verifique el tiempo de espera de UDP, el mantenimiento de NAT, la actualización de la sesión y las expectativas del proveedor.
Solo las llamadas entrantes no funcionan: Verifique DNAT, regla de firewall, redes de origen del proveedor y puerto compartido de PBX.
Solo una línea WAN causa problemas: Verifique la ruta SD-WAN, la ruta de respuesta, la puerta de enlace y el enlace de IP del proveedor.

Esta clasificación le impide cambiar la configuración de SIP aunque el problema real radica en la ruta de retorno RTP o una ruta SD-WAN.

Registrar el estado inicial antes de los cambios

Antes de realizar cambios en la CLI, se debe documentar el estado actual:

¿Qué teléfonos, PBX o SBC están afectados?
¿Los dispositivos finales se registran directamente con el proveedor o todo funciona a través de un sistema telefónico interno?
¿Qué servidores SIP y rangos de puertos RTP nombra el proveedor?
¿Qué regla de firewall procesa el tráfico VoIP?
¿Está habilitado Log firewall traffic en esta regla?
¿Qué regla NAT se aplica al tráfico VoIP saliente y entrante?
¿Existen varias líneas WAN, rutas SD-WAN o VPN basadas en rutas?
¿El problema se hizo visible después de una actualización de firmware, cambio de proveedor o actualización de PBX?

Probar reglas de firewall en Sophos Firewall ayuda a analizar las reglas. Para el flujo real de paquetes, Packet Capture en WebAdmin suele aportar más información que un Policy Test aislado. Los valores CLI globales no deben modificarse hasta disponer de esta línea base y de una llamada de prueba reproducible.

Comprobar la ruta de paquetes, el enrutamiento y la calidad

Verifique las reglas del firewall y NAT

NAT suele estar implicada en problemas de VoIP. El Sophos Firewall no solo debe permitir SIP, sino también traducir y devolver correctamente los flujos RTP asociados en ambas direcciones.

Estos puntos suelen ser relevantes para teléfonos salientes o una centralita interna:

regla de firewall adecuada desde la zona VoIP o zona PBX a WAN
regla SNAT o MASQ apropiada
Iniciar sesión en la regla del firewall
ninguna regla que sea demasiado amplia o esté incorrectamente colocada encima de la regla VoIP
ninguna Application Control, IPS o Web Filtering inesperada en este tráfico

Que un trunk SIP entrante necesite DNAT depende del diseño del proveedor. Los trunks basados en registro pueden utilizar la sesión saliente existente. Los trunks entregados directamente a una dirección pública o los sistemas telefónicos publicados suelen requerir una regla DNAT limitada de forma precisa. Las especificaciones del proveedor o del operador SBC son determinantes.

Si se necesita DNAT, también se deben comprobar estos puntos:

DNAT al PBX interno o SBC
Regla de firewall con zona de destino y red de destino apropiadas
Restricción a las redes de origen del proveedor, si es posible.
sólo se requieren puertos SIP y RTP
Registro y Packet Capture para pruebas.

Una regla NAT no permite el tráfico, solo traduce direcciones o puertos. Las conexiones se explican en Comprender NAT en Sophos Firewall. Si es necesario acceder a una PBX desde Internet, Servidor de publicación a través de DNAT es la mejor base para la publicación real.

Analizar RTP y dirección del idioma

Si se establece la llamada pero falta el audio, SIP ya no suele ser el problema principal. Luego hay que comprobar si el RTP fluye en ambas direcciones.

Proceso típico:

Tenga en cuenta el proveedor o el rango de puertos RTP de PBX.
Inicie Packet Capture con la IP de origen del PBX o teléfono y el rango de puertos RTP.
Haz una llamada de prueba.
Compruebe si los paquetes UDP del dispositivo interno al proveedor son visibles.
Compruebe si los paquetes UDP regresan del proveedor.
Compare NAT ID, Rule ID, In interface y Out interface.

Si RTP solo se ve en sentido saliente y no regresa nada, el problema puede estar en el proveedor, la ruta de retorno, NAT o un equipo anterior. Si RTP regresa pero no se reenvía a la PBX, las causas más probables son la regla de firewall, DNAT, el enrutamiento o la asignación de zona.

Para grabaciones más precisas o exportación PCAP, tcpdump vía SSH puede resultar útil. El proceso se describe en Sophos Firewall Utilice tcpdump para registros y análisis.

SD-WAN, VPN y múltiples líneas WAN

VoIP es sensible a rutas asimétricas. Si SIP se ejecuta a través de una línea WAN pero RTP regresa a través de una línea diferente o una VPN basada en rutas se enruta de manera diferente, surgen errores típicos como audio unilateral.

Un error corregido en SFOS 22.0 MR1 muestra la conexión típica: después de una actualización a SFOS 22.0 GA, el audio VoIP solo podía funcionar unidireccionalmente a través de VPN basada en rutas con enrutamiento SD-WAN. En la práctica, esto significa: Siempre se debe verificar SD-WAN cuando se utiliza VoIP a través de VPN o múltiples rutas WAN.

Puntos de control importantes:

¿Una ruta SD-WAN coincide con el tráfico VoIP?
¿SIP y RTP se enrutan a través de la misma línea WAN esperada?
¿Existen especificaciones del proveedor con respecto a la IP de origen o la dirección pública del remitente?
¿Se utiliza una ruta VPN basada en rutas con una interfaz XFRM?
¿Las rutas de regreso y NAT coinciden con el camino elegido?
¿Packet Capture muestra diferentes puertas de enlace o interfaces para direcciones de ida y vuelta?

Para las opciones SD-WAN específicas de Sophos, encaja Paquete de respuesta de enrutamiento SD-WAN y tráfico del sistema. Sophos Firewall Solución de problemas de IPsec también ayuda con las conexiones IPsec.

Modelado de tráfico para VoIP

La configuración del tráfico puede estabilizar VoIP cuando las líneas son estrechas o las cargas grandes desplazan los paquetes de voz. Sin embargo, no soluciona reglas NAT incorrectas, puertos RTP faltantes y rutas de retorno incorrectas.

La configuración del tráfico es particularmente útil si:

VoIP empeora cuando la línea de Internet está bajo carga,
Las cargas o copias de seguridad interrumpen las conversaciones,
varias aplicaciones utilizan la misma línea,
Se debe dar prioridad específica a VoIP.

La configuración se describe en Aplicación de modelado de tráfico en Sophos Firewall. Para VoIP, no sólo se deben realizar pruebas de velocidad después de la implementación, sino también realizar llamadas de prueba reales con carga simultánea.

Probar SIP Helper, UDP Timeout y DoS de forma controlada

Los siguientes ajustes afectan a más de una regla VoIP. Solo deben probarse después de acotar la causa, con una línea base documentada, una ventana de mantenimiento y un rollback claro.

Verifique el asistente SIP

El SIP Helper, a menudo también llamado SIP ALG, intenta reconocer paquetes SIP y adaptar la información SIP relevante para NAT. Esto puede ayudar en entornos simples. Sin embargo, también puede ser perjudicial en muchas configuraciones VoIP modernas con SBC del proveedor, PBX propio, TLS, NAT clean keepalive o rangos de puertos RTP más complejos.

SIP Helper es, por tanto, un punto de prueba útil, pero no una solución permanente universal. Sophos documenta el módulo SIP como activado de forma predeterminada. Los cambios realizados con load o unload persisten después de un reinicio.

Los comandos se ejecutan mediante SSH en Sophos Firewall, en 4. Device Console. El acceso SSH solo debe permitirse desde redes de confianza. Los conceptos básicos se describen en Conectar con Sophos Firewall mediante SSH.

El estado actual se muestra antes y después de cada cambio con un comando de solo lectura:

system system_modules show

La salida del registro sip debe documentarse. Así queda claro si el Helper estaba cargado antes de la prueba y qué estado se espera después del rollback.

Desactivar el módulo SIP:

system system_modules sip unload

Reactivar el módulo SIP:

system system_modules sip load

⚠️ Este cambio debe realizarse en una ventana de mantenimiento o con pruebas claramente definidas. Después de deshabilitar o habilitar, se debe verificar el registro, las llamadas salientes, las llamadas entrantes y el audio en ambas direcciones.

Si el cambio no ayuda, deberías retirarlo. Es importante documentar la condición antes y después de la prueba.

Si el proveedor utiliza un puerto propio de señalización SIP en lugar de UDP 5060, el Helper puede cargarse con ese puerto exacto:

system system_modules sip load ports <custom_port>

<custom_port> se sustituye por el puerto SIP especificado por el proveedor o el fabricante de la PBX, no por un rango completo de puertos RTP. SIP Helper admite puertos de medios de 1024 a 65535. Si un puerto de medios está fuera de este rango, el firewall puede descartar el tráfico y mostrar Invalid Traffic en el registro de eventos.

SIP sobre TCP tiene otra limitación: el Helper no admite mensajes SIP o SDP que se extiendan por varios paquetes. Si Packet Capture muestra exactamente este patrón, el transporte debe aclararse con el proveedor y el fabricante de la PBX. Cambiar a SIP sobre UDP solo tiene sentido si ambos extremos lo admiten.

Verifique y ajuste el tiempo de espera de UDP

VoIP suele utilizar UDP. Si las entradas de sesión o NAT caducan demasiado pronto, puede parecer que un registro funciona, pero las llamadas se interrumpen o las llamadas entrantes no llegan al PBX de manera confiable.

Sophos distingue dos valores globales:

udp-timeout se aplica a conexiones UDP que todavía no se han reconocido como un flujo bidireccional.
udp-timeout-stream se aplica a flujos UDP establecidos en los que ambos extremos han enviado tráfico por el mismo puerto entre segmentos de red.

En SFOS 22, ambos valores aceptan entre 30 y 3600 segundos. Los valores actuales de Advanced Firewall se muestran en Device Console:

show advanced-firewall

Valor de flujo de tiempo de espera UDP en Sophos Firewall — El valor del flujo de tiempo de espera de UDP debe documentarse antes de cualquier cambio.

La ayuda actual de SFOS 22 indica 60 segundos como valor predeterminado de UDP Timeout Stream y recomienda 150 segundos para VoIP. Sin embargo, siguen siendo determinantes el valor mostrado realmente y la especificación del proveedor. Si Packet Capture y el momento del corte indican un timeout de flujo demasiado corto, el valor documentado puede probarse de forma controlada:

set advanced-firewall udp-timeout-stream 150

⚠️ udp-timeout-stream no es una opción de una regla VoIP. Afecta a todos los flujos UDP que coincidan. No se debe aumentar por intuición ni de forma arbitraria. Antes de la prueba se anota el valor anterior de show advanced-firewall y se restaura con el mismo comando set si la prueba no funciona.

Si el proveedor o el sistema telefónico admite NAT keepalive, también se debe verificar esta configuración. Un mantenimiento limpio del lado de la PBX o del proveedor suele ser mejor que un valor de tiempo de espera global muy alto.

Comprobar los umbrales de UDP flood

VoIP genera muchos paquetes UDP. Si los umbrales de Intrusion prevention > DoS & spoof protection > DoS settings son demasiado bajos, el firewall puede descartar tráfico SIP o RTP legítimo como UDP flood. Antes de realizar un cambio, deben documentarse los valores actuales de Packet rate, Burst rate y Apply flag, así como los contadores de descartes.

Sophos menciona la retirada temporal de Apply flag para UDP flood como prueba de diagnóstico. Esto reduce la protección DoS durante la prueba y, por tanto, debe realizarse en una ventana de mantenimiento con un caso de prueba limitado. Si VoIP mejora, Packet rate y Burst rate se ajustan a la carga legítima medida y se vuelve a establecer Apply flag. Si el problema no cambia, el estado inicial se restaura de inmediato.

Una excepción específica para hosts o puertos conocidos puede ser más segura que una desactivación global. Spoof Protection y protección DoS en Sophos Firewall explica cómo interactúan los umbrales y las DoS bypass rules. La protección no debe permanecer desactivada después de la prueba.

Diagnóstico y evidencias

Flujo práctico de resolución de problemas

Síntoma del documento: registro, establecimiento de llamada, audio, hora de cancelación, dirección.
Recopile datos del proveedor: servidor SIP, transporte, rango de puertos RTP, requisitos NAT.
Identifique la regla de firewall y la regla NAT.
Active el inicio de sesión en la regla de firewall afectada.
Abra Log Viewer y Packet Capture durante una llamada de prueba.
Compruebe si la señalización SIP se ejecuta en ambas direcciones.
Compruebe si RTP se ejecuta en ambas direcciones.
Si hay varias líneas WAN, verifique SD-WAN y la ruta de retorno.
Compruebe el estado de SIP Helper, pruebe los cambios de forma específica y documente los resultados.
Ajuste un tiempo de espera UDP solo de forma deliberada y con el valor anterior documentado.
Si hay descartes UDP o problemas de calidad bajo carga, compruebe los umbrales de UDP flood de forma controlada.
Después de cada cambio, pruebe el registro, las llamadas salientes, las llamadas entrantes y el audio en ambas direcciones.

Si se realizan varios cambios al mismo tiempo, la causa posterior es difícil de entender. Una prueba por cambio es mejor.

Recopilar pruebas durante una llamada de prueba

Una prueba de VoIP sólo es útil si la hora, la dirección y el flujo de paquetes coinciden. Especialmente en el caso de los proveedores, la afirmación “El audio no funciona” no es suficiente. Necesita un caso de prueba pequeño y reproducible.

Hora exacta con zona horaria: Log Viewer, Packet Capture y los registros del proveedor se pueden comparar fácilmente más adelante.
Dirección de llamada: Las llamadas entrantes, las llamadas salientes y el desvío interno no se mezclan.
Números de teléfono o extensiones: Los proveedores y PBX encuentran más rápidamente la llamada específica.
IP interna de PBX o teléfono: Packet Capture se puede filtrar de forma estricta.
Servidor SIP del proveedor y rango de puertos RTP: Los análisis SIP y RTP permanecen separados.
Rule ID, NAT ID, In interface y Out interface: puedes ver qué regla y qué ruta se utilizaron realmente.
Registro de eventos y contadores DoS: Invalid Traffic o el aumento de descartes UDP flood ayudan a delimitar el rango de puertos del Helper y los umbrales DoS.
Resultado por prueba: El registro, el timbre, el establecimiento de llamada, el audio izquierdo/derecho y el tiempo de finalización permanecen rastreables.

En caso de errores esporádicos, también debería hacer una copia de seguridad de los registros relevantes antes de que se sobrescriban. Para un paquete de registro limpio, encaja Sophos Firewall Copia de seguridad de registros para soporte y análisis. Qué archivo de registro pertenece a qué servicio se describe en Sophos Firewall Solución de problemas: servicios y registros.

Errores comunes

Solo el puerto SIP habilitado, olvidé el rango del puerto RTP: La llamada se establece pero falta el audio.
Existe una regla NAT, pero no hay una regla de firewall que coincida: El tráfico se traduce pero no se permite.
Regla de firewall sin registro: La solución de problemas en Log Viewer permanece ciega.
SIP Helper desactivado o activado en todos los ámbitos: El problema se mueve aleatoriamente en lugar de analizarse.
Puerto SIP personalizado confundido con el rango de puertos RTP: El Helper se carga en el puerto de señalización equivocado.
Tiempo de espera de UDP establecido muy alto: Las sesiones UDP globales permanecen abiertas durante un tiempo innecesariamente largo.
Protección UDP flood demasiado estricta o desactivada de forma permanente: Se descartan paquetes de voz legítimos o la protección permanece innecesariamente reducida después de la prueba.
Múltiples rutas WAN sin una regla SD-WAN clara: Es más probable que el audio unidireccional o el tráfico rechazado por el proveedor.
Redes de origen del proveedor no restringidas: El servicio SIP es innecesariamente accesible desde Internet.
Traffic shaping entendido como sustituto de NAT/enrutamiento: La calidad de la voz sigue siendo mala porque la causa está en otra parte.

Revertir los cambios de forma limpia

En cualquier cambio de VoIP debe quedar claro cómo volver atrás:

valores anteriores de udp-timeout y udp-timeout-stream documentados si se modifican
prueba SIP load, unload o de puerto personalizado y estado final deseado documentados
umbrales UDP flood y Apply flags originales documentados y restaurados después de la prueba
reglas de firewall y NAT modificadas registradas con fecha y motivo
llamadas de prueba registradas con dirección y hora
Packet Capture o registros relevantes conservados para casos de soporte

Si el cambio no ayuda, no debería dejarse como un legado accidental. De lo contrario, las soluciones VoIP en particular serán difíciles de entender más adelante.

Lista de verificación operativa

La información SIP y RTP del proveedor está disponible.
Se identifica la regla de firewall para VoIP y el registro está activo.
La regla NAT coincide con la dirección del tráfico.
SIP y RTP se comprobaron por separado.
Packet Capture muestra la dirección de ida y vuelta.
El estado de SIP Helper se comprobó antes y después de la prueba específica.
Un puerto SIP personalizado coincide con la especificación del proveedor o la PBX y no se confunde con el rango de puertos RTP.
El tiempo de espera de UDP solo se cambió con un valor inicial documentado.
Los umbrales de UDP flood y la protección DoS se devolvieron a un estado final seguro después de la prueba.
Se verificaron SD-WAN, VPN y múltiples líneas WAN.
La configuración del tráfico se utiliza únicamente para el control de calidad, no como reemplazo del enrutamiento o correcciones NAT.

Preguntas frecuentes

¿Debería desactivar siempre SIP Helper en Sophos Firewall?

No. SIP Helper puede ayudar o dificultar según el proveedor y el sistema telefónico. Se debe probar específicamente. Si la desactivación no aporta ninguna mejora, deberás restaurar el estado anterior.

¿Por qué funciona la llamada pero no se escucha nada?

Entonces la señalización SIP funciona al menos parcialmente, pero el flujo de medios RTP no se ejecuta correctamente. Verifica el rango de puertos RTP, NAT, regla de firewall, ruta de retorno y, si hay varias rutas WAN, SD-WAN.

¿Un mayor tiempo de espera UDP ayuda con los problemas de VoIP?

A veces sí, sobre todo en el caso de llamadas interrumpidas o registros inestables. Sin embargo, el valor tiene un impacto más amplio en las sesiones UDP y, por lo tanto, debe ser consciente, documentado y no establecerse innecesariamente alto.

¿Qué tiene de importante VoIP sobre SD-WAN?

SIP y RTP deben ejecutarse por la ruta esperada. Si los viajes de ida y vuelta utilizan diferentes líneas WAN o rutas VPN, es posible que se produzcan audio unilateral o conexiones rechazadas.