Configurar IPv6 Router Advertisement en Sophos Firewall

Un cliente IPv6 puede tener una dirección y, aun así, no disponer de una red funcional. En Sophos Firewall, Router Advertisement, o RA, proporciona el prefijo, el router predeterminado y la información sobre si SLAAC o DHCPv6 se encarga de los valores adicionales. DHCPv6 por sí solo no proporciona un gateway predeterminado.

Por tanto, el error más frecuente no es un rango de leases incorrecto, sino una combinación inadecuada de prefijo RA, flags y función DHCPv6. Una red SLAAC sencilla normalmente solo necesita un /64 anunciado con Autonomous. Si un servidor DHCPv6 debe asignar direcciones, también se necesita Managed flag. Other flag remite a los clientes a parámetros DHCPv6 adicionales, como DNS o Domain Name.

⚠️ Un Router Advertisement incorrecto puede cambiar las direcciones o el router predeterminado de todo el segmento de capa 2. Documente las fuentes RA, los prefijos IPv6 y el acceso de administración existentes antes de guardar. Pruebe primero el cambio en una VLAN piloto con un cliente real.

Router Advertisement en ocho pasos

1. Definir el /64 IPv6 previsto, el segmento de clientes y las funciones deseadas de SLAAC y DHCPv6.
2. Comprobar si un router ya envía mensajes RA o si Prefix Delegation ha creado automáticamente una configuración RA.
3. Abrir Network > IPv6 router advertisement y seleccionar Add.
4. Seleccionar la interfaz física, LAG, VLAN o bridge compatible con IPv6 del segmento de clientes.
5. Establecer los intervalos mínimo y máximo de advertisement adecuados para el entorno.
6. Activar Managed flag, Other flag y Default gateway únicamente según el modelo de cliente previsto.
7. Añadir el /64 con On-link, Autonomous, Preferred lifetime y Valid lifetime.
8. Guardar y utilizar una nueva ejecución del cliente para comprobar RS, RA, dirección, gateway predeterminado, DNS y tráfico de aplicación IPv6 real.

Una entrada RA visible todavía no demuestra el éxito. Solo el cliente muestra si el sistema operativo, el prefijo, DHCPv6 y la ruta predeterminada aplican la misma planificación.

Entender SLAAC, DHCPv6 y los dos flags

Independientemente de ello, una interfaz compatible con IPv6 crea automáticamente una dirección link-local para comunicarse en el segmento local; no necesita RA para hacerlo. Esta dirección local es distinta de la dirección SLAAC global y no demuestra que la configuración de direcciones globales funcione. Una dirección global por sí sola tampoco demuestra que haya acceso a internet.

Con SLAAC, el cliente forma su dirección IPv6 global a partir del prefijo anunciado y de su identificador de interfaz. Para ello, el prefijo debe permitir Autonomous. El firewall también anuncia el router predeterminado mediante RA cuando Default gateway está activado.

Managed flag indica que los clientes deben obtener su dirección IPv6 de un servidor DHCPv6. Sophos señala expresamente que este flag solo debe utilizarse cuando haya un servidor DHCPv6 disponible. El procedimiento completo se describe en Configurar y probar un servidor DHCPv6 en Sophos Firewall.

Other flag dirige a los clientes a DHCPv6 para obtener parámetros de red adicionales. Pueden incluir servidores DNS, Domain Name, NIS, NISP, SIP, SNTP y BCMS. El flag no proporciona estos valores por sí mismo; DHCPv6 debe entregarlos realmente y el cliente debe admitirlos.

Según el sistema operativo, un cliente puede crear varias direcciones o interpretar los flags de forma diferente. Por eso, la combinación prevista debe comprobarse con las plataformas de cliente realmente utilizadas y no deducirse únicamente del formulario de WebAdmin.

Elegir conscientemente el modelo de direccionamiento

Las tres opciones cumplen funciones distintas: Managed flag y Other flag están en la cabecera RA, mientras que Autonomous pertenece a cada prefijo anunciado. Default gateway vuelve a ser independiente. Esto permite los siguientes modelos habituales:

• Solo SLAAC: Active Autonomous y Default gateway, y deje desactivado Managed flag. Deje desactivado Other flag si el cliente no debe obtener otros valores mediante DHCPv6.
• SLAAC más DHCPv6 stateless: Active Autonomous, Default gateway y Other flag, y deje desactivado Managed flag. SLAAC crea la dirección; DHCPv6 proporciona, por ejemplo, DNS.
• DHCPv6 stateful: Active Managed flag y Default gateway, y asegúrese de que haya un servidor DHCPv6 accesible. Deje desactivado Autonomous si el cliente no debe crear además una dirección SLAAC; active Other flag para los parámetros DHCPv6 adicionales.
• Coexistencia: Si Autonomous y Managed flag están activos, los clientes pueden utilizar SLAAC y DHCPv6 en paralelo. Elija esta variante solo cuando se pretendan varias direcciones y se hayan comprobado los sistemas operativos utilizados.

El formulario RA documentado de SFOS 22 no contiene campos RDNSS ni DNSSL. Para distribuir DNS mediante este procedimiento de Sophos, planifique conjuntamente Other flag y un servidor DHCPv6. Esto no afecta a la configuración estática de los clientes.

RA automático con Prefix Delegation

Cuando se selecciona IPv6 prefix delegation en una interfaz interna, SFOS crea automáticamente un Router Advertisement. El prefijo asignado automáticamente a este servidor RA no se puede modificar. Para anunciar un prefijo adicional, se debe crear otro servidor RA con ese prefijo.

La creación automática resulta práctica, pero no debe pasarse por alto. Las notas de la versión SFOS 21.5 GA también indican que RA y el servidor DHCPv6 están activados de forma predeterminada para DHCP Prefix Delegation. Antes de crear una entrada RA manual, compruebe en la interfaz interna y en Network > IPv6 router advertisement qué configuraciones existen realmente y están activas en el sistema SFOS 22 concreto. Configurar IPv6 Prefix Delegation en Sophos Firewall explica el procedimiento completo para el proveedor, la WAN y la interfaz delegada.

Una distinción es importante para el modelo de direccionamiento: según la ayuda de SFOS 22, la opción DHCPv6 server de una interfaz interna en modo Delegated solo proporciona parámetros adicionales, como DNS, y no asigna direcciones IPv6. Para DHCPv6 stateful se necesita, en cambio, un servidor independiente que asigne direcciones en Network > DHCP.

Planificar la red de ejemplo

El siguiente ejemplo utiliza 2001:db8::/32, un rango reservado para documentación. No está destinado a la comunicación productiva por internet y debe sustituirse por el prefijo realmente asignado:

• Segmento de clientes: VLAN20
• Dirección del firewall: 2001:db8:20::1/64
• Prefijo anunciado: 2001:db8:20::/64
• Modo de funcionamiento: SLAAC con gateway predeterminado
• DHCPv6: solo para parámetros DNS adicionales, si son necesarios
• Cliente de prueba: un dispositivo administrado en VLAN20

El prefijo, la dirección de la interfaz y el segmento de clientes deben corresponder entre sí. Una configuración RA copiada de otra VLAN puede proporcionar a los clientes una dirección formalmente válida que no funcione en el routing local.

Configurar Router Advertisement

Seleccionar la interfaz y los intervalos

En Network > IPv6 router advertisement > Add, seleccione primero la interfaz de clientes. SFOS permite una interfaz física, LAG, VLAN o bridge compatible con IPv6. No seleccione una interfaz WAN o de tránsito solo porque allí llegue el prefijo del proveedor; lo determinante es el segmento de capa 2 de los clientes.

Min advertisement interval y Max advertisement interval determinan el intervalo entre mensajes RA no solicitados. Si el intervalo máximo es de nueve segundos o más, SFOS exige que el mínimo sea el 75 por ciento del máximo. No existe un valor ideal universal: los cambios afectan al tiempo de detección y a la densidad de mensajes, por lo que solo deben realizarse con un valor inicial documentado y una prueba de cliente.

Establecer los flags y el gateway predeterminado

En el ejemplo SLAAC, Managed flag permanece desactivado. Active Other flag únicamente si un servidor DHCPv6 accesible proporciona realmente valores adicionales. Default gateway hace que el firewall sea el router predeterminado anunciado; el tiempo correspondiente se indica en segundos.

Un flag activado no demuestra el funcionamiento. Si se establece Managed flag, pero ningún servidor DHCPv6 responde, la configuración de direcciones queda incompleta. Si Default gateway está desactivado, el cliente puede formar una dirección global, pero no recibe una ruta predeterminada de este RA.

Introducir el prefijo y los lifetimes

Según Sophos, un RA puede contener cero o más opciones de prefijo. Por tanto, el router predeterminado, los flags M/O y el prefijo anunciado son decisiones independientes: un RA sin prefijo aún puede proporcionar información del router, pero no crea una dirección SLAAC para este segmento.

Para este ejemplo, introduzca 2001:db8:20::/64 en la configuración de Prefix Advertisement. El campo espera exactamente un /64; primero debe dividir un prefijo delegado del proveedor más grande en redes de clientes /64 adecuadas. On-link indica al cliente que los destinos de este prefijo se pueden alcanzar en el segmento local sin otro router. Autonomous permite crear automáticamente la dirección mediante SLAAC.

Preferred lifetime especifica en minutos durante cuánto tiempo se prefiere una dirección para las conexiones nuevas. Después pasa a estar deprecated, pero puede seguir utilizándose para la comunicación existente. Valid lifetime indica durante cuánto tiempo sigue siendo válida en total. Tras expirar, ya no puede enviar ni recibir. Por eso, SFOS exige que Valid lifetime sea al menos igual a Preferred lifetime.

Con SLAAC, un RA posterior que contenga un prefijo coincidente y apto para SLAAC puede actualizar Preferred lifetime según el nuevo valor recibido. Una dirección asignada mediante DHCPv6 puede actualizarse mediante una renovación DHCPv6. Recibir RA continuamente no garantiza por sí solo que la dirección siga siendo preferida: un valor anunciado de Preferred lifetime de cero provoca la deprecación, mientras que uno demasiado corto puede expirar antes de la siguiente actualización.

Con prefijos dinámicos del proveedor, estos tiempos no deben planificarse como si el prefijo permaneciera siempre igual. Un cambio de prefijo debe probarse con una nueva ejecución del cliente y con conexiones existentes y nuevas.

Tratar MTU y parámetros de Neighbor de forma consciente

Los campos avanzados controlan información para IPv6 Neighbor Discovery:

• Link MTU anuncia el tamaño máximo de paquete en bytes. Con 0, la interfaz no anuncia información MTU.
• Reachable time determina cuánto tiempo considera el cliente que un neighbor confirmado está accesible.
• Retransmit time determina la espera antes de otra Neighbor Solicitation.
• Hop limit limita el número de saltos de router; cada router reduce el valor.

No utilice estos valores como controles generales de optimización del rendimiento. Un cambio de MTU o neighbor requiere un síntoma concreto, un valor inicial registrado y nuevas pruebas con paquetes grandes, Neighbor Discovery y aplicaciones reales.

Solo API: nombre del objeto y estado en SFOS 22/23

La automatización mediante API debe tener en cuenta la versión de SFOS. Estas diferencias afectan al esquema de la API, no a los pasos de WebAdmin anteriores; no permiten deducir un campo adicional en la interfaz gráfica.

Para Add Router Advertisement y Update Router Advertisement, SFOS 23 exige un Name único para el objeto RA previsto, además de Interface, que sigue siendo obligatorio. Name está documentado como SCALAR de tipo STRING: un máximo de 64 caracteres, sin comas y con caracteres UTF-8 permitidos. El esquema de SFOS 22 no contiene este parámetro ni el elemento correspondiente en el ejemplo.

Para Delete Router Advertisement, Interface es el selector obligatorio en SFOS 22; SFOS 23 lo sustituye por Name, con las mismas reglas de nombre. Antes de eliminar, identifique claramente el objeto RA previsto, su nombre en SFOS 23 y la interfaz de clientes asociada, y documente la fuente RA que funciona y su configuración. No elimine preventivamente una entrada existente que funcione. Si se sustituyó la fuente anterior, siga el procedimiento de recuperación descrito más abajo: restaure primero la fuente anterior y después desactive la nueva entrada.

La tabla de estados de la API de SFOS 23 añade 505 para Add y Update con la clave simbólica de mensaje Message.RouterAdvertisementNameRecordExists; SFOS 22 solo enumera 200 y 500 para estas operaciones. La clave apunta a un nombre ya existente. Ante este resultado, compruebe el objeto previsto y que Name sea único, en lugar de eliminarlo y volver a crearlo a ciegas. Aquí 505 es un estado documentado de la API, no una afirmación sobre un estado HTTP. La tabla no establece un texto de mensaje verificado, un comportamiento probado del dispositivo ni reglas de identificación para las actualizaciones, cambio de nombre o migración.

Comprobar RA y el comportamiento del cliente

Después de guardar, vuelva a conectar el cliente piloto o renueve de forma controlada su configuración IPv6. Una captura de paquetes con el filtro BPF icmp6 debe mostrar la Router Solicitation del cliente como ICMPv6 Type 133 y el Router Advertisement del firewall como Type 134. El Type 135 es una Neighbor Solicitation y no debe confundirse con RS durante el análisis.

A continuación, compruebe las capas por separado:

1. El RA llega por la interfaz esperada y desde el router previsto.
2. El prefijo, On-link, Autonomous y los flags coinciden con la planificación.
3. El cliente tiene la dirección IPv6 global y el gateway predeterminado esperados.
4. Si Managed flag u Other flag están activos, DHCPv6 proporciona los valores previstos.
5. Los nombres DNS internos y externos se resuelven mediante los servidores planificados.
6. Un flujo IPv6 real coincide con el Firewall Rule ID esperado y la prueba negativa sigue bloqueada.

Packet Capture en WebAdmin de Sophos Firewall explica la captura de WebAdmin y sus campos. Compatibilidad y límites de IPv6 en Sophos Firewall con SFOS 22 sigue siendo relevante para la matriz general de reglas, routing y VPN de IPv6.

Delimitar los errores sistemáticamente

El cliente envía RS, pero el firewall no responde

Compruebe la interfaz, la dirección IPv6, el estado RA y cualquier configuración automática existente de Prefix Delegation. Después, correlacione radvd.log con la hora de la prueba. Reiniciar el servicio no es el primer paso de diagnóstico; primero, la configuración, la captura y el log deben demostrar dónde falta la respuesta.

Llega RA, pero el cliente no recibe una dirección global

Compare el /64 anunciado, Autonomous y el RA recibido realmente. Si Managed flag está activo, compruebe también la comunicación DHCPv6 mediante UDP 546 y 547. Un RA visible por sí solo no demuestra una asignación de dirección completa.

El cliente tiene una dirección, pero no un gateway predeterminado

Compruebe si Default gateway está activado y qué router lifetime llega en el RA. DHCPv6 no puede sustituir esta ruta predeterminada ausente. Si se ven varios Router Advertisements, asigne cada origen mediante la dirección de origen y la interfaz de entrada. Allowed RA servers, en Network > Interfaces > [editar interfaz] > Advanced settings, solo limita los servidores RA de los que el propio firewall acepta una configuración stateless; no filtra los mensajes RA para otros clientes del segmento de capa 2.

La dirección y el gateway son correctos, pero falta DNS

Cuando se utiliza Other flag o un modelo DHCPv6, el servidor DHCPv6 debe proporcionar realmente los valores DNS previstos. Compare después la solicitud del cliente, la respuesta del servidor y la configuración del resolver local. Establecer el flag por sí solo no crea un servidor DNS.

IPv6 solo funciona parcialmente

Compruebe primero la ruta y el camino de retorno, y después la regla IPv6 y el Rule ID. Para paquetes grandes, compare también la Link MTU realmente anunciada con una captura y una prueba de aplicación. El éxito de IPv4 no demuestra el funcionamiento del camino IPv6 independiente.

Prefix Delegation ha creado otro prefijo

El prefijo de una configuración RA creada automáticamente por Prefix Delegation no puede sustituirse manualmente. Compruebe conjuntamente el prefijo del proveedor, la interfaz delegada y la entrada RA existente. Un prefijo adicional necesita su propio servidor RA y un camino de routing completamente funcional.

Comprobar servicios y logs de Sophos Firewall mediante CLI clasifica los servicios y archivos de log pertinentes, incluido radvd.log.

Revertir el cambio

Para disponer de una recuperación que conserve el estado, registre antes del cambio la interfaz, el estado, los intervalos, los flags, el tiempo del gateway predeterminado, todas las opciones de prefijo, los lifetimes y los Advanced Settings. No elimine preventivamente una entrada RA existente que funcione.

Si el origen RA anterior permaneció activo durante la prueba, para el rollback basta con desactivar o eliminar la nueva entrada manual. Si se sustituyó el origen anterior, restáurelo primero con los valores documentados y desactive después la nueva entrada, de modo que no haya un intervalo sin el router previsto. No trate una configuración creada automáticamente mediante Prefix Delegation como una entrada manual independiente; devuelva la configuración documentada de interfaz y delegación a su estado anterior.

Después, vuelva a conectar el cliente y compruebe de nuevo la fuente RA, la dirección, el gateway predeterminado, DNS y un camino IPv6 real. Las direcciones y rutas ya recibidas pueden seguir visibles hasta que expiren sus lifetimes anunciados; no deje activas en paralelo las fuentes RA antiguas y nuevas sin control ni compruebe únicamente los valores ya presentes en el cliente.

Preguntas frecuentes