FortiGate bloqueaba mi RTP
y no lo sabía

El síntoma

Todo parecía funcionar. El trunk SIP con el carrier estaba registrado. Al marcar desde Asterisk, la señalización corría perfecta: INVITE → 100 Trying → 183 Session Progress → 200 OK → ACK. La llamada "se establecía". Pero en el teléfono: silencio total. Y a los 16-18 segundos, la llamada se colgaba sola.

El carrier terminaba la llamada por timeout de RTP. Su SBC esperaba recibir audio dentro de los primeros 20 segundos y nunca llegó nada.

Diagnóstico: el sniffer no miente

Lo primero que hice fue correr el sniffer en FortiGate sobre la interfaz WAN. El objetivo era ver si los paquetes RTP salían de la red. El resultado fue revelador:

• SIP: visible en ambas direcciones. INVITE, 200 OK, ACK, todo ahí.
• RTP entrante (carrier → LAN): visible, llegaba correctamente.
• RTP saliente (LAN → carrier): no aparecía ningún paquete.

Revisé en la interfaz LAN (SVR-VLAN150): el RTP salía del Asterisk correctamente. Llegaba al FortiGate. Pero ahí se quedaba. Algo en el firewall lo estaba tirando.

La causa raíz: dst-port vs src-port

La policy outbound de Asterisk hacia el trunk SIP tenía configurados dos services:

config firewall service custom
    edit "SIP"
        set udp-portrange 5060
    next
    edit "RTP-Audio"
        set udp-portrange 10000-20000
    next
end

¿Parece razonable? El problema es sutil pero crítico: udp-portrange en Fortinet filtra por puerto de destino. Pero el RTP saliente tiene como origen el puerto del rango RTP de Asterisk (10000-20000) y como destino un puerto aleatorio que elige el carrier.

Lo más frustrante: el RTP entrante sí pasaba, porque venía con src-port random del carrier y dst-port en 10000-20000 (del Asterisk). Ese sí matcheaba el service. Por eso el síntoma era unidireccional.

El fix

Fortinet tiene una sintaxis específica para definir rangos de src-port: dst:src. Así se crea un service que restringe el tráfico saliente RTP correctamente:

config firewall service custom
    edit "RTP-Audio-OUT"
        set udp-portrange 1024-65535:10000-20000
    next
end

Esta definición significa:

• dst-port: 1024-65535 (cualquier puerto de destino, lo que elige el carrier)
• src-port: 10000-20000 (el rango RTP de Asterisk)

Con ese service agregado a la policy outbound y el RTP-Audio-OUT en lugar del anterior, el audio funcionó inmediatamente en ambas direcciones.

Por qué es difícil de diagnosticar

Este bug tiene varios factores que lo hacen traicionero:

1. El deny es silencioso. FortiGate no loggea por defecto los paquetes denegados en policies existentes. La llamada "funciona" porque SIP pasa, pero el RTP se descarta sin registro visible.
2. El RTP entrante sí funciona. Eso genera la falsa impresión de que la policy está bien y el problema es del carrier o del Asterisk.
3. El timing es consistente. El colgado a los 18 segundos parece un bug de Asterisk o del dialplan. Es el timeout del carrier, no del firewall.
4. La configuración parece correcta. "Tengo SIP y RTP habilitados". Sí, pero para el tráfico equivocado.

Checklist para VoIP en FortiGate

Si estás integrando Asterisk (o cualquier PBX) con un trunk SIP detrás de un FortiGate, verificá:

• Corrés sniffer en WAN específicamente buscando UDP desde el rango RTP del PBX.
• Si tenés RTP-Audio con udp-portrange 10000-20000, revisá si filtra por dst o src.
• Creás services separados para RTP entrante y saliente. Los flujos son opuestos en dst/src.
• Habilitás logging en la policy outbound temporalmente durante el diagnóstico.
• El ALG SIP de FortiGate puede interferir con Asterisk. Considerá desactivarlo si tenés Kamailio o manejo propio de NAT.

---