Tu subred se cae sin causa aparente: el IP pool olvidado que contesta ARP

Hay una clase de falla que desgasta más que cualquier caída total: la subred que se cae a ratos. Un servidor deja de contestar a la mitad del turno, regresa solo, y a la hora vuelve a desaparecer. Los cables están bien, el switch no marca errores, el servidor nunca se apagó. ¿Te suena?

Nos tocó heredar una red así. La operación llevaba tiempo sobreviviendo con un ritual: cuando una subred se caía, alguien entraba a los switches y editaba a mano la tabla ARP, y en los casos peores también fijaba entradas ARP estáticas directamente en los servidores. Funcionaba… hasta la siguiente caída. La causa raíz resultó ser una sola línea de configuración del FortiGate, en un objeto que colgaba de una política que llevaba años muerta.

El síntoma: dos equipos contestan por la misma IP

Cuando un equipo quiere hablar con 192.168.10.50, primero pregunta por ARP: "¿quién tiene la 192.168.10.50?". Lo normal es que conteste uno solo, el dueño de esa IP. El problema empieza cuando contestan dos: el servidor legítimo y otro equipo que no tiene nada que ver. Cada cliente se queda con la respuesta que le llegó al último, así que una parte de la red manda su tráfico al servidor y otra parte lo manda a un lugar donde nadie lo espera.

Por eso la falla parece aleatoria: depende de qué respuesta ganó en cada equipo y de cuándo expiró su caché ARP. Y por eso el parche de ARP estático "funciona": al fijar a mano la MAC correcta, dejas de escuchar al impostor. Pero el impostor sigue ahí, contestando.

El impostor: un IP pool con arp-reply activado

Un IP pool en FortiGate es un rango de direcciones que el firewall usa como origen al hacer NAT de salida. Para que el tráfico de regreso llegue, el FortiGate tiene que reclamar esas direcciones en la red, y lo hace contestando ARP por ellas. Eso lo controla el parámetro arp-reply, que viene activado por defecto.

Si el rango del pool cae dentro de un segmento que ya usan servidores o equipos, el FortiGate empieza a contestar ARP por direcciones que pertenecen a otros. No hace falta equivocarse en nada más: basta con crear el pool con un rango mal elegido y olvidarlo. En nuestro caso, el pool pertenecía a una política de una VPN IPsec que se había caído años atrás. El túnel no volvió a levantar, nadie borró la política, y el pool que usaba para hacer NAT hacia el socio tenía un rango que caía dentro de una subred interna. La política ya no pasaba tráfico, pero el pool seguía contestando ARP.

Esa es la distinción que importa: que un objeto no pase tráfico no significa que nada lo reclame. Para la configuración, ese pool estaba en uso: tenía una política que lo referenciaba. Que la política no volviera a hacer match nunca más no le quitaba nada al pool.

Y aunque borres la política, el pool puede seguir contestando. La referencia del CLI describe arp-reply como la respuesta a ARP "cuando el IP pool se agrega a una política", pero Fortinet documenta en una nota técnica que en FortiOS 7.4.1 y posteriores (también 7.2.6+, 7.0.13+ y 6.4.17+), un IP pool o una VIP con arp-reply enable se trata como dirección local del FortiGate aunque ninguna política lo use. El firewall deja de enrutar hacia esas IPs porque las considera suyas. En 7.2.0-7.2.5 y 7.4.0 no era así, y por eso Fortinet recomienda borrar los pools y VIP sin uso antes de actualizar desde esas versiones: un upgrade puede "despertar" un objeto que llevaba años dormido. Todo lo que sigue está validado sobre FortiOS 7.4.12.

FGT # show firewall ippool
config firewall ippool
    edit "pool-vpn-socio"
        set startip 192.168.10.40
        set endip 192.168.10.60
    next
end

FGT # show full-configuration firewall ippool
config firewall ippool
    edit "pool-vpn-socio"
        set type overload
        set startip 192.168.10.40
        set endip 192.168.10.60
        set arp-reply enable
        set arp-intf ''
        ...
    next
end

Ese detalle es la trampa: show solo despliega lo que se cambió respecto al default, y como arp-reply enable es el default, no aparece. Puedes revisar la configuración diez veces con show y nunca verlo. Solo show full-configuration lo enseña. Fíjate también en arp-intf: vacío significa que el FortiGate contesta por ese rango en cualquier interfaz, no solo en la que da a internet.

Lo mismo aplica a las VIP (config firewall vip), que también tienen su arp-reply activado por defecto. Si ya leíste NAT a fondo: port forwarding, DMZ y las VIP de FortiGate, esta es la letra chiquita que complementa esa pieza.

¿Cómo confirmas que el FortiGate contesta por IPs ajenas?

1. Desde un equipo afectado, mira a qué MAC tiene asociada la IP del servidor que "se cae":

C:\> arp -a 192.168.10.50

Interface: 192.168.10.23 --- 0x7
  Internet Address      Physical Address      Type
  192.168.10.50         00-09-0f-aa-bb-cc     dynamic

Compara esa MAC con la del servidor real. Si no coincide y los primeros tres octetos (el OUI) son de Fortinet, como el 00:09:0f del ejemplo, ya tienes al sospechoso. Para confirmar que es la MAC de una interfaz del FortiGate, en el CLI usa get hardware nic port2 y busca el campo Current_HWaddr.

2. En el FortiGate, atrapa al impostor en el acto con el sniffer filtrado a ARP (el tcpdump escondido del FortiGate):

FGT # diagnose sniffer packet port2 'arp and host 192.168.10.50' 4 20
interfaces=[port2]
filters=[arp and host 192.168.10.50]
2.418830 port2 in arp who-has 192.168.10.50 tell 192.168.10.23
2.418871 port2 out arp reply 192.168.10.50 is-at 00:09:0f:aa:bb:cc
2.419102 port2 in arp reply 192.168.10.50 is-at 3c:ec:ef:12:34:56

Esas tres líneas son el caso completo: una pregunta, dos respuestas. La primera sale del FortiGate (out), la segunda llega del servidor real (in). Cualquier equipo que se quede con la primera va a mandar su tráfico al firewall en vez de al servidor.

3. Encuentra qué objeto reclama esa IP. Busca en show full-configuration firewall ippool y show full-configuration firewall vip cualquier rango que contenga la dirección en disputa. Luego averigua quién lo referencia:

FGT # diagnose sys cmdb refcnt show firewall.ippool.name pool-vpn-socio
entry used by child table poolname:name 'pool-vpn-socio' of table firewall.policy:policyid '37'

Cada línea entry used by es un lugar donde el objeto se usa. En la GUI ves lo mismo en la columna Ref. de la lista de IP pools; con un clic abres la ventana de uso del objeto. Si no devuelve nada, es un huérfano. Pero aquí está la trampa: una referencia no prueba que el objeto esté vivo. Una referencia solo dice que algo lo usa en la configuración, no que ese algo siga funcionando. El siguiente paso es revisar la política que lo referencia:

• En la lista de políticas, las columnas Hit Count y Last Used. Una política con meses o años sin hits es sospechosa por definición.
• Si la política sale o entra por un túnel, su estado con get vpn ipsec tunnel summary. Un túnel con selectors(total,up): 1/0 y contadores en cero lleva tiempo sin levantar.

FGT # get vpn ipsec tunnel summary
'vpn-socio' 203.0.113.10:0  selectors(total,up): 1/0  rx(pkt,err): 0/0  tx(pkt,err): 0/0

Una política zombi (túnel caído, cero hits, nadie que la reclame) sigue sosteniendo todo lo que referencia: pools, direcciones, rutas. Es configuración muerta que sigue teniendo efectos en la red.

La corrección: dos líneas y una limpieza que casi nadie hace

Si el pool cuelga de una política zombi, borra primero la política y después el pool (el FortiGate no te deja borrar un objeto con referencias). No te quedes en borrar solo la política: en 7.4.1+ el pool sin referencias sigue siendo dirección local. Si el pool sí está vivo, pero su rango no necesita que el FortiGate conteste ARP en la LAN (lo común cuando el rango es de direcciones públicas enrutadas por el carrier), apaga el arp-reply o limítalo a la interfaz correcta:

# Opción A
config firewall policy
    delete 37
end
config firewall ippool
    delete "pool-vpn-socio"
end

# Opción B
config firewall ippool
    edit "pool-vpn-socio"
        set arp-reply disable
        # o, si sí debe contestar, solo en la interfaz WAN:
        # set arp-intf "wan1"
    next
end

Y luego viene el paso que separa arreglar de parchar: quitar todas las entradas ARP estáticas que se fueron sembrando en switches y servidores durante el tiempo que duró el problema. Si las dejas, se convierten en la siguiente falla: el día que cambies la NIC de un servidor, o migres una VM a otro host con otra MAC, esa entrada estática va a mandar el tráfico a una MAC que ya no existe. Y nadie se va a acordar de por qué estaba ahí. Es exactamente la dinámica de no hay nada más permanente que una solución temporal.

Al final, vacía las cachés para que la red aprenda de nuevo lo que es cierto: execute clear system arp table en el FortiGate, el equivalente en cada switch, y arp -d en los equipos que quedaron con la entrada envenenada. Después verifica con get system arp que cada IP apunte a una sola MAC, la correcta.

Lo que este caso enseña de una red heredada

Ningún comando de esta pieza es avanzado. Lo difícil nunca fue la herramienta; fue que durante mucho tiempo la respuesta a "se cayó la subred" fue parchar el síntoma en lugar de preguntar quién más está contestando por esa IP. Cada ARP estático que se sembró hizo la falla un poco más rara y un poco más difícil de rastrear.

Si recibes una red de otro equipo, agrega esto a tu revisión de entrada. Toma cinco minutos y te puede ahorrar meses:

• Lista todos los IP pools y VIP con show full-configuration, no con show.
• Por cada uno con arp-reply enable, confirma que su rango no se empalme con ningún segmento interno en uso y que arp-intf apunte a la interfaz correcta.
• Borra los objetos que nada referencia (diagnose sys cmdb refcnt show vacío o Ref. en 0), y hazlo antes de cualquier actualización de firmware.
• No confíes en la referencia: revisa Last Used de cada política y el estado de cada túnel. Las políticas zombi de VPNs caídas se llevan de encuentro todo lo que referencian.
• Busca entradas ARP estáticas en switches y servidores. Cada una debería tener un motivo escrito; si nadie sabe por qué existe, probablemente está tapando algo.

Cuando una red lleva años "cayéndose sin causa aparente", casi nunca es sin causa. Lo más seguro es que nadie haya buscado a quién más le estaba contestando, y el debug flow no te lo va a enseñar, porque el problema vive un piso más abajo: en la capa 2.