Este es un articulo de opinión basado en mi experiencia desplegando sistemas VoIP en proyectos de telecomunicaciones en los que había firewalls gestionados por empresas externas. Tener un punto ciego que no puedes gestionar en una red y poder hacer pruebas de forma autónoma limita mucho la rapidez y eficacia que puedes dar ante una incidencia. En el caso que nos atañe aquí y ahora, mi punto ciego fue un firewall que limitaba la comunicación de telefonía VoIP.
Durante el tiempo que trabaje desplegando sistemas de telefonía IP, hubo una incidencia que acabé viendo demasiadas veces y al principio era un «dolor de cabeza» para mi: teléfonos que registraban perfectamente contra la centralita, funcionaban durante horas o días y, de repente, dejaban de estar registrados. Lo curioso era que muchas veces bastaba con reiniciar el teléfono para que todo volviera a funcionar.
Al principio, como es lógico, miraba primero nuestra parte. Revisaba la configuración del teléfono, credenciales SIP, servidor de registro, firmware, DNS y tiempos de registro. Incluso llegué a modificar esos intervalos pensando que quizá el terminal estaba tardando demasiado en renovar la sesión. Con el tiempo entendí que estaba mirando solo una parte del problema…
Una de las principales lecciones que me llevé de aquellos despliegues fue que abrir los puertos de VoIP y activar o desactivar SIP ALG no garantiza que un teléfono vaya a mantener correctamente su registro. La comunicación podía fallar aunque, aparentemente, todo estuviera bien configurado.
Y fue precisamente ese tipo de incidencias lo que terminó cambiando mi forma de trabajar y avanzar como profesional.
El despliegue empezaba antes de conectar el primer teléfono
Antes de instalar un servicio siempre hacía un pequeño estudio de las necesidades y de la infraestructura del cliente. Revisaba cómo estaba montada la red, qué direccionamiento utilizaban, si necesitábamos una VPN, qué servicios iban a comunicarse con nuestra infraestructura y si existía algún firewall entre los teléfonos y nuestras centralitas.
Cuando ese firewall estaba gestionado por otra empresa, trasladábamos previamente los requisitos técnicos del proyecto. Si necesitábamos SIP, determinados rangos para RTP, una VPN o cualquier otra comunicación relacionada con el despliegue, solicitábamos que parametrizaran el firewall para permitirlo. Sobre el papel era sencillo: nosotros indicábamos qué necesitábamos y la empresa responsable del firewall aplicaba las reglas.
Aquí la parte VoIP tenia otros planes. 😀
Cuando todo esta bien y, aun así, no funciona
El teléfono funcionaba… hasta que dejaba de registrar.
El patrón se repetía bastante. Instalábamos el terminal, configurábamos la cuenta SIP y este registraba correctamente contra una centralita alojada en nuestra infraestructura. El cliente podía realizar y recibir llamadas y aparentemente todo estaba bien.
Hasta que dejaba de estarlo.
En algún momento el teléfono perdía el registro. Desde la centralita veíamos que ya no estaba conectado y el terminal podía quedarse en ese estado sin conseguir registrarse de nuevo.
Lo primero era revisar aquello que controlábamos nosotros: credenciales SIP, servidor de registro, DNS, firmware, configuración del terminal o parámetros relacionados con la renovación del registro. Además de revisar también nuestro router y centralita pero siempre estaban bien configuradas y no era el problema. También probé a modificar los tiempos de registro buscando que el teléfono renovase la sesión antes de que apareciera el problema.
A veces parecía mejorar, pero la incidencia volvía.
Lo más llamativo era que se solucionaba con reiniciar el teléfono o recargar las credenciales SIP en el teléfono. Reiniciar el terminal simplemente obligaba a empezar otra vez: nueva comunicación, nueva asociación NAT y nuevo registro SIP
Había algo en medio que causaba el problema y ese era el firewall.
El problema de no tener gestión y depender de un tercero
Cuando contactábamos con la empresa que gestionaba el firewall, la respuesta era perfectamente razonable:
“El tráfico VoIP está permitido.” Con eso te quedabas… Y seguramente era verdad.
El problema es que permitir UDP/5060-5061 o los rangos RTP necesarios no significa necesariamente que el firewall vaya a tratar correctamente todo el ciclo de una comunicación VoIP.
Sin tener gestión del firewall y no poder hacer pruebas con el, estaba a ciegas en este punto. Lo cual era frustante.
Un firewall mantiene estados, realiza NAT, tiene sus propios timeouts y puede inspeccionar SIP. Dependiendo del fabricante y de la configuración, también puede modificar determinadas partes de los mensajes o aplicar un SIP ALG.
El teléfono puede seguir considerando válida su relación con la centralita mientras el firewall ha eliminado una asociación NAT por inactividad. Cuando llega la siguiente renovación del registro, la comunicación ya no se encuentra exactamente en el mismo estado que al principio.
SIP ALG y abrir puertos SIP tampoco eran una respuesta al problema
Otro de los conceptos que revise fue SIP ALG.
Aplicar SIP ALG es una regla genérica que por lo general funciona. El firewall reconoce SIP e intenta facilitar su funcionamiento cuando hay NAT de por medio. El problema es que ese intento de “ayudar” también puede introducir una nueva variable.
Dependiendo de la centralita, del terminal, de la topología y del fabricante del firewall, SIP ALG puede funcionar correctamente o provocar problemas bastante difíciles de seguir: registros que dejan de renovarse, puertos inesperados, cabeceras modificadas o llamadas con comportamiento extraño.
RouterOS me ayudaba a ver lo que estaba ocurriendo realmente
Para diagnosticar muchos de estos problemas, entre otras aplicaciones y sistemas, utilizaba RouterOS como punto de observación.
Tener acceso al router permitía comprobar qué estaba ocurriendo con las comunicaciones sin depender únicamente de lo que mostraban el teléfono o la centralita. Herramientas como Torch, la tabla de conexiones o el Packet Sniffer de RouterOS me ayudaban a ver hacia qué IP estaba enviando tráfico el terminal, qué puertos estaba utilizando o si seguía existiendo una comunicación activa. Eso era especialmente útil cuando había otros proveedores implicados.
Podía comprobar que desde nuestra parte el teléfono estaba generando correctamente tráfico hacia la centralita y llegar a la empresa que gestionaba el firewall con información más concreta. Ya no era simplemente “el teléfono no registra”, sino que podía explicar qué comunicación estábamos viendo, hacia dónde iba y en qué punto parecía aparecer el problema.
Eso hizo que el troubleshooting fuera mucho más efectivo.
La lección más importante: dos proveedores pueden tener «razón» y el servicio seguir fallando
Esta fue probablemente una de las cosas que más aprendí de aquellos despliegues. Nosotros podíamos revisar nuestra centralita y concluir que funcionaba correctamente. La empresa que administraba el firewall podía revisar sus reglas y confirmar que los puertos solicitados estaban permitidos:
Los dos podíamos tener razón y el teléfono seguir sin registrar. (Esto no solo pasa con VoIP, ya había tenido otras experiencias en otros escenarios y es un problema recurrente cuando, en la infraestructura IT, conviven varios operadores).
Porque el problema podía estar justo en la interacción entre ambos sistemas. Esa experiencia me hizo dejar de pensar en términos de “mi parte funciona” y empezar a mirar la comunicación completa. Si no podía tener acceso al FW, podía mirar la documentación del fabricante y proponer yo la solución a esto. En un servicio VoIP no importa únicamente que el teléfono esté bien configurado o que el firewall tenga una regla de permit. Importa qué ocurre desde que el terminal genera el tráfico hasta que llega a la centralita y vuelve la respuesta.
Ahí es donde aparecen NAT, timeouts, inspección SIP, estados del firewall y particularidades de cada fabricante.
Empecé a adelantarme al problema
Después de varias incidencias dejé de esperar a que el problema apareciera. Si un cliente me decía que tenía un firewall gestionado por otra empresa, una de las primeras preguntas pasó a ser:
¿Qué fabricante y modelo tenéis? (Y que versión tenia el firewall pero esto el cliente no solía saberlo).
Uno de los casos que recuerdo especialmente fue con el fabricante SonicWall. Fue el primer fabricante de firewall que tuve que investigar a conciencia para resolver este problema (después vinieron otros). Cuando me encontraba con el fallo de registro, investigaba cómo trataba SonicWall SIP, NAT y los timeouts, qué opciones específicas podían afectar al tráfico y qué configuración recomendaba el fabricante para escenarios similares y tambien plantear mi propia hipótesis de funcionamiento. Entonces enviaba esa información a la empresa responsable del firewall.
Entonces ya no enviaba únicamente los requisitos genéricos del servicio. Preparaba información especifica y exacta que los técnicos que administraban ese firewall debían parametrizar: qué reglas necesitábamos, qué comportamiento NAT debía revisarse, qué parámetros podían afectar al registro y qué recomendaciones hacía el propio fabricante para ese escenario.
También mejoró mucho mi comunicación entre proveedores. En lugar de abrir una incidencia cuando algo ya estaba fallando, trataba de dejar el firewall correctamente preparado antes de poner el servicio en producción.
Ese pequeño cambio me ahorró muchos problemas y me hizo ser mas mucho profesional. El fallo dejo de repetirse. ☺️
Aprender a gestionar las expectativas del cliente
Otra cosa que cambié fue la forma de explicar el despliegue al propio cliente.
Si sabía que había un firewall de terceros en medio, prefería avisar desde el principio de que durante las primeras semanas podían aparecer incidencias de registro mientras terminábamos de ajustar el comportamiento del firewall a nuestros servicios.
No era decirle al cliente que el servicio iba a funcionar mal. Era explicar una realidad técnica: estábamos integrando nuestra plataforma con una infraestructura administrada por otra empresa y podía ser necesario realizar algún ajuste fino una vez observásemos el comportamiento real del tráfico.
Eso ayudaba a evitar una situación bastante habitual: que apareciera la primera incidencia, se reiterara en el tiempo, y el cliente pensase que todo el despliegue estaba mal realizado o el servicio no era el esperado…
CIERRE – Lecciones de una incidencia VoIP
De esta experiencia me quedo con varias lecciones que sigo considerando útiles a día de hoy.
–No hay que dar por sentado que abrir puertos y aplicar una configuración genérica sea suficiente para que un protocolo funcione correctamente. En VoIP había que entender cómo intervenían NAT, los timeouts, SIP ALG y el estado de las sesiones durante todo el ciclo de registro. Ese mismo principio puede aplicarse a VPN, DNS, correo, túneles, aplicaciones publicadas o cualquier servicio que atraviese varios elementos de red.
–Dos proveedores pueden tener «correctamente» configurada su parte y el servicio seguir fallando. Cuando eso ocurre, hay que dejar de mirar sistemas aislados y estudiar cómo interactúan entre ellos.
-Identificar los puntos ciegos de una infraestructura. Si un firewall, router, proxy o cualquier otro elemento está gestionado por un tercero y no puedes comprobar hipótesis o hacer pruebas de forma autónoma, la resolución de incidencias se vuelve más lenta y dependiente de otros. Ese concepto es aplicable a muchos otros escenarios. Un firewall, un proxy, un balanceador, un router, una VPN o cualquier equipo situado en mitad de una comunicación puede convertirse en un punto ciego si no tienes visibilidad sobre él. Cuantos más elementos del camino puedas observar y comprender, más rápido puedes aislar una incidencia y comprobar tus hipótesis.
-Merece la pena salir de tu zona de comfort e investigar por tu cuenta. Descarte el camino fácil, que hubiera sido que la empresa del firewall fuera la que me diera solución, lavándome las manos con el asunto del registro y diciendo que no era mi infraestructura y por tanto no era mi problema. Dar un paso mas allá hará que aprendas en el camino y que seas un mejor profesional. No esperes que la otra empresa resuelva el problema, estudiar la documentación del fabricante y preparar previamente la parametrización adecuada puede evitar muchas horas de troubleshooting después.
Espero que alguna de ellas te pueda ayudar en tu día a día como administrador.
