Configurar un túnel IP en Sophos Firewall con 6in4, 6to4, 6rd o 4in6

En Network > IP tunnels, Sophos Firewall crea túneles que encapsulan un protocolo de red dentro de otro. Esto permite transportar IPv6 sobre una infraestructura IPv4 o IPv4 sobre una infraestructura IPv6. SFOS ofrece 6in4, 6to4, 6rd y 4in6 para estos escenarios.

Esta función no es el túnel GRE de Device Console ni una VPN IPsec. Un túnel IP encapsula paquetes, pero no los cifra ni autentica automáticamente.

⚠️ Solo se debe utilizar un túnel IP sobre una infraestructura no confiable si el diseño de seguridad acepta expresamente la falta de confidencialidad y autenticación del peer. Para conectar sedes de forma protegida, IPsec site-to-site suele ser el mejor punto de partida.

¿Qué tipo de túnel conviene?

Los cuatro tipos no resuelven el mismo problema:

• 6in4 conecta dos redes IPv6 sobre un backbone IPv4. Los endpoints IPv4 local y remoto se configuran manualmente. Sophos recomienda este tipo para conexiones punto a punto.
• 6to4 transporta IPv6 sobre IPv4 y está pensado para diseños punto a multipunto. La dirección IPv4 de origen se configura manualmente y la de destino se puede obtener automáticamente.
• 6rd amplía 6to4 con un prefijo proporcionado por el proveedor. Solo es adecuado si el ISP suministra los valores 6rd necesarios.
• 4in6 conecta dos redes IPv4 sobre un backbone IPv6. Los endpoints externos local y remoto son direcciones IPv6 y el tipo está pensado para conexiones punto a punto.

Para un enlace controlado con endpoints fijos, 6in4 o 4in6 resulta más fácil de comprender. No se debe elegir 6to4 o 6rd únicamente porque SFOS pueda crear una ruta automáticamente. El direccionamiento y el diseño del proveedor deben ajustarse exactamente a ese mecanismo.

Compatibilidad con IPv6 en Sophos Firewall resume los límites de IPv6 en SFOS. Un túnel GRE, por el contrario, transporta tráfico IP enrutado mediante un procedimiento propio de Device Console y no es intercambiable con estos cuatro tipos de WebAdmin.

Planificar el ejemplo y los requisitos

El ejemplo utiliza un túnel 6in4 estático entre dos sedes:

• Nombre visible: HQ-IPv6-via-IPv4
• Hardware name: v6hq01
• Dirección WAN IPv4 local: 192.0.2.10
• Endpoint IPv4 remoto: 198.51.100.20
• Red IPv6 local: 2001:db8:100::/64
• Red IPv6 remota: 2001:db8:200::/64
• Servidor de prueba: 2001:db8:200::20
• Zona de la interfaz de túnel: VPN en el ejemplo

192.0.2.0/24, 198.51.100.0/24 y 2001:db8::/32 son rangos de documentación. Deben sustituirse, junto con los nombres, la zona y los prefijos, por los valores reales. La zona VPN es una elección comprensible para el ejemplo, no un requisito del producto. Lo importante es que el modelo de zonas, las reglas de firewall y Device Access correspondan a la arquitectura real.

Antes de crear el túnel, ambos endpoints externos deben ser accesibles por la infraestructura. En ambos lados se necesita un túnel simétrico, redes internas únicas, una ruta de retorno y una regla de firewall para el tráfico real. Los prefijos solapados, un valor del proveedor ausente para 6rd o una configuración desconocida del peer son condiciones para detenerse.

Una copia de seguridad, una ventana de mantenimiento y un acceso de gestión independiente también forman parte del plan de recuperación. El túnel no se crea como experimento sobre la única conexión de producción.

Crear el túnel IP en WebAdmin

En Network > IP tunnels > Add, primero se definen la identidad y el tipo de túnel y después los endpoints y los valores IP avanzados.

Distinguir Name de Hardware name

El Name normal admite como máximo 58 caracteres y se puede modificar posteriormente. Debe identificar la finalidad y el peer, por ejemplo HQ-IPv6-via-IPv4.

El Hardware name es técnico y no se puede modificar después de guardar. Admite como máximo diez caracteres y solo A-Z, a-z, 0-9 y _. SFOS también bloquea numerosos nombres y fragmentos del sistema, entre ellos gre, ipsec0, sit, tun, xfrm, Port, MGMT, eth, WLAN y Halink. El valor neutro v6hq01 evita estos conflictos.

Un Hardware name incorrecto no se cambia más adelante. Hay que documentar las dependencias y volver a crear el túnel de forma controlada. Por eso este valor se comprueba con especial atención antes de pulsar Save.

Definir el tipo, la zona y los endpoints

Para el ejemplo se selecciona 6in4. En Zone se elige la zona de seguridad prevista. En Local endpoint se introduce 192.0.2.10 y en Remote endpoint, 198.51.100.20.

La familia de direcciones depende del tipo. En 6in4, 6to4 y 6rd, el endpoint externo local es IPv4; 6in4 también tiene un endpoint IPv4 remoto fijo. En 4in6, los endpoints externos local y remoto son direcciones IPv6. Una ruta interna de destino no se introduce en un campo de endpoint.

En la configuración avanzada, TTL determina cuánto pueden sobrevivir los paquetes encapsulados en la infraestructura. TOS asigna al paquete IP externo un valor de tipo de servicio para la priorización y el comportamiento de enrutamiento. La ayuda actual no establece valores óptimos universales. Por tanto, ambos campos se mantienen en el valor inicial documentado mientras ningún problema medido de routing o QoS justifique un cambio.

Después de Save, SFOS confirma la creación y abre el diálogo de rutas. Con 6to4 y 6rd, el firewall también crea automáticamente una ruta unicast IPv6 estática. Importante: cerrar esta ventana o seleccionar Cancel no elimina el túnel ni las rutas creadas automáticamente.

Añadir rutas y reglas de firewall

Un túnel guardado aún no es un flujo de datos funcional. Para 6in4, se añade una ruta IPv6 estática al prefijo remoto 2001:db8:200::/64 por la nueva interfaz de túnel. El peer necesita la ruta de retorno simétrica a 2001:db8:100::/64.

En 4in6, la ruta interna lleva a una red de destino IPv4. En 6to4 y 6rd, se revisa la ruta IPv6 creada automáticamente y se compara con el diseño del proveedor antes de añadir otras rutas. Cancel en el primer diálogo de rutas no constituye un rollback.

Las rutas adicionales se crean en Routing > Static routes. Rutas estáticas en Sophos Firewall explica cómo encajan el prefijo de destino, la interfaz, la distancia, la decisión de enrutamiento y una prueba real.

A continuación se crea entre las zonas implicadas una regla de firewall restringida y con logging, con valores reales de origen, destino y servicio. En una conexión normal entre sedes se conserva la dirección de origen original; no se activa MASQ para sustituir una ruta de retorno ausente. El procedimiento está en Configurar reglas de Sophos Firewall de forma segura.

Validar el túnel y el tráfico real

La validación separa la configuración guardada, la encapsulación externa y la aplicación interna:

1. En Network > IP tunnels, comparar Name, Hardware name, tipo, Zone y endpoints con el peer.
2. En Routing > Static routes, comprobar que el prefijo interno remoto apunta a la interfaz de túnel esperada.
3. Ejecutar Route Lookup para el servidor de prueba interno y confirmar la interfaz prevista.
4. Desde el cliente de prueba local, iniciar una conexión nueva a 2001:db8:200::20 mediante un servicio expresamente permitido.
5. En Log Viewer, comprobar Source, Destination, Service, Action y Firewall Rule ID.
6. Con Packet Capture, observar primero los endpoints externos y después la dirección interna de prueba.
7. En el peer, comprobar entrada, desencapsulación, ruta de retorno y dirección de origen real.
8. Repetir la prueba en sentido contrario solo con una regla destinada a esa dirección.

Una entrada de túnel verde o visible no demuestra la ruta ni el funcionamiento del peer. Una ruta creada automáticamente tampoco demuestra que el proveedor, los equipos intermedios y las reglas transporten realmente la encapsulación. Packet Capture en Sophos Firewall explica la captura controlada.

Localizar errores por síntoma

El túnel no se puede guardar

Primero se comprueban por separado Name y Hardware name. Hardware name puede tener como máximo diez caracteres, solo caracteres permitidos y ningún término de sistema bloqueado. Después se verifica que el tipo de túnel y la familia de direcciones de los endpoints local y remoto coincidan.

Un nombre visible distinto no corrige un Hardware name no válido. Si otra interfaz ya utiliza ese valor, se planifica un nombre técnico único en lugar de probar repetidamente sufijos aleatorios.

El túnel existe, pero no hay ruta a la red de destino

En 6in4 y 4in6 se crea expresamente la ruta estática necesaria. En 6to4 y 6rd se comprueba si SFOS ha creado la ruta unicast IPv6 prevista y si su prefijo coincide con el diseño. Una ventana cerrada anteriormente con Cancel no borra la configuración guardada automáticamente.

Route Lookup y la tabla de routing aportan la siguiente evidencia. No se modifica Route Precedence global por sospecha ni se añade una ruta blackhole o ficticia que compita con la ruta real.

Se ven paquetes externos, pero falta el tráfico interno

A menudo no coinciden el tipo del peer, las direcciones de endpoint, el prefijo interno o la ruta de retorno. Se comparan ambas configuraciones de forma simétrica. Después se revisan la regla, la Firewall Rule ID esperada y una captura de las direcciones internas de origen y destino.

Que la encapsulación funcione no demuestra que el tráfico real esté permitido. A la inversa, la ausencia de Rule ID puede indicar que el paquete interno nunca se desencapsuló o siguió otra ruta.

Los paquetes pequeños funcionan, pero las aplicaciones se bloquean

La encapsulación IP externa adicional reduce el tamaño de paquete utilizable respecto a la infraestructura. En lugar de copiar un valor MTU ajeno, se miden Path MTU, fragmentación y la aplicación afectada. El procedimiento controlado de Comprobar MTU y MSS en problemas de túnel también sirve para este análisis, pero los valores fijos de IPsec no se trasladan al túnel IP.

HA, cambios y rollback

Las dos páginas de ayuda de SFOS 22 no prometen un estado HA ininterrumpido para estos túneles IP. Después de un cambio de roles planificado, se vuelven a comprobar la entrada del túnel, Route Lookup, la encapsulación externa, Firewall Rule ID y una sesión nueva. Una conexión existente no demuestra continuidad.

Antes de un cambio se documentan Name, el Hardware name inmutable, tipo, Zone, endpoints, rutas creadas automática y manualmente, reglas y la última prueba real. Esto permite distinguir un cambio de configuración de uno en el flujo de datos.

Para el rollback, primero se detiene el tráfico de prueba. Las reglas dependientes y las rutas manuales se desactivan de forma controlada o se restauran al estado anterior confirmado. También se revisan expresamente las rutas automáticas de 6to4 o 6rd. El túnel solo se elimina cuando ya no queda ninguna dependencia productiva. Finalmente se vuelven a probar la ruta anterior y un flujo conocido.

Lista de comprobación

• El tipo elegido corresponde a las familias de direcciones interna y externa.
• Ambos endpoints y prefijos están acordados con el peer.
• El nombre visible y el Hardware name inmutable están documentados.
• Zone, ruta estática y ruta de retorno corresponden al diseño de seguridad.
• Se revisaron las rutas automáticas de 6to4 o 6rd.
• Una regla restringida coincide con la Firewall Rule ID esperada.
• La encapsulación externa y el tráfico interno se probaron por separado.
• MTU, HA y rollback se validaron sobre el flujo real.

Preguntas frecuentes