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.

La ayuda de SFOS 23 explica con más precisión el mecanismo automático: 6to4 deriva el prefijo IPv6 de la dirección IPv4 pública local. No se configura un endpoint remoto; el gateway de destino se determina automáticamente a partir de la dirección IPv6 de destino. En cambio, 6rd utiliza prefijos IPv6 y gateways de relay proporcionados por el ISP. El firewall determina automáticamente el gateway de relay del ISP. Para ello, el ISP debe ofrecer un servicio 6rd adecuado; si hay IPv6 nativo, se prefiere este. Estos mecanismos no cambian la advertencia sobre tecnología heredada que aparece a continuación.

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.

En 6to4 también hay que distinguir el mecanismo unicast que sigue definido del mecanismo de relay anycast público. La IETF retiró el anycast 6to4 por sus problemas operativos y recomienda que los routers mantengan 6to4 desactivado de forma predeterminada (RFC 7526). Por tanto, no se debe activar 6to4 para una nueva conexión a Internet. Como máximo, debe usarse en un diseño unicast existente y coordinado expresamente; la conectividad IPv6 nativa, un 6rd gestionado por el proveedor o un peer 6in4 fijo son alternativas más controlables.

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. El modelo de zonas y las reglas de firewall deben corresponder a la arquitectura real. Device access controla el acceso a servicios del propio firewall y no sustituye una regla para el tráfico de aplicación reenviado.

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.

La infraestructura debe transportar un protocolo IP encapsulado, no un puerto TCP o UDP. 6in4, 6to4 y 6rd usan IPv6 dentro de IPv4 con el número de protocolo IPv4 41 (RFC 4213); 4in6 sigue el modelo de túnel IPv6 de RFC 2473 e identifica el paquete IPv4 interno en la cabecera IPv6 externa con el valor Next Header 4 registrado por IANA. Antes del despliegue hay que confirmar este flujo exacto con el proveedor, el firewall ascendente y cualquier dispositivo NAT. Abrir un puerto no sustituye esta comprobación.

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.

En otras configuraciones se muestra este nombre de interfaz personalizable, no el Hardware name inmutable.

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.

La lista completa de restricciones documentadas para Hardware name en SFOS 22 y 23 es: all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp, imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port, MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos, GuestAP, spq, Halink. El nombre no puede contener ninguno de estos fragmentos; no se trata solo de nombres completos idénticos. Se conservan las grafías documentadas sin deducir cómo se comprueban las mayúsculas y minúsculas.

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 etiqueta Remote endpoint corresponde a la ayuda de SFOS 22. La ayuda de SFOS 23 llama al campo Remote gateway: acepta una dirección IPv4 o un FQDN para 6in4, y una dirección IPv6 o un FQDN para 4in6. Un FQDN es el nombre DNS completo del peer, no el prefijo interno de destino. Para Local endpoint, SFOS 23 describe una dirección asociada a una interfaz (6in4/6to4), expresamente una dirección IPv4 asociada para 6rd y una interfaz IPv6 para 4in6. La familia de direcciones local sigue siendo la indicada a continuación. Las diferencias en la ayuda no demuestran en qué versión exacta empezó la compatibilidad en tiempo de ejecución.

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 ni indica un valor predeterminado en la página de ayuda. Por tanto, se anotan los valores iniciales que muestra el formulario propio y solo se cambian si lo exige un requisito concreto de la infraestructura o de QoS.

Estos fundamentos de TTL/TOS corresponden a la ayuda de SFOS 22. La ayuda de SFOS 23 explica TTL como el número máximo de routers que puede atravesar un paquete encapsulado antes de descartarse. Este límite ayuda a evitar bucles de enrutamiento. Tampoco indica un valor predeterminado numérico para TTL o ToS.

Para 4in6, SFOS 23 describe además estos ajustes avanzados:

• Inherit ToS es opcional y utiliza el valor ToS del paquete interno.
• MTU es el tamaño máximo de paquete en bytes que puede atravesar el túnel sin fragmentación. El valor predeterminado documentado es la MTU de la interfaz física menos 48 bytes; la reducción tiene en cuenta la sobrecarga de encapsulación 4in6.
• Override MSS es opcional y permite especificar la MSS manualmente. MSS es la mayor carga útil TCP en bytes dentro de un único paquete TCP sin fragmentación. Ajustarla permite evitar la fragmentación o adaptarse a los límites de Path MTU. El valor predeterminado documentado es el valor MTU menos 40 bytes.

Estas fórmulas son valores documentados, no cálculos propios de la sobrecarga del protocolo ni resultados de laboratorio. No se afirma un estado de activación predeterminado de las casillas opcionales. Los ajustes siguen dependiendo del recorrido real.

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.

API de SFOS 23: esquema y validación

Este apartado describe la documentación de la API para Add IP Tunnel / Edit IP Tunnel, no el procedimiento de WebAdmin ni una solicitud probada. Frente a la documentación de SFOS 22, la tabla de parámetros de SFOS 23 añade cuatro campos opcionales de tipo SCALAR:

• MSS: INTEGER, rango permitido 536–8912, como máximo cuatro dígitos.
• MTU: INTEGER, rango permitido 576–8952, como máximo cuatro dígitos.
• LocalInterface: STRING para la interfaz local del túnel; la celda Default está vacía. Esto no confirma un valor predeterminado en ejecución.
• InheritToS: valores permitidos Disable y Enable.

La tabla no confirma que todos los campos se apliquen a todos los tipos de túnel, la precedencia entre LocalInterface y LocalEndPoint, las combinaciones de campos obligatorias ni la versión en la que empezó la compatibilidad en ejecución. Las indicaciones de WebAdmin sobre endpoints y FQDN no se trasladan como garantía de compatibilidad con la API.

Estado 541 de la API en Add y Edit

Para ambas operaciones, SFOS 23 documenta el estado 541 con el mensaje MTU and MSS must not exceed the local interface values. Por tanto, MTU y MSS no deben superar los valores correspondientes de la interfaz local. Antes de modificar nada, se comparan los valores MTU/MSS enviados, la interfaz local asociada y su configuración registrada. Esta validación de la API no mide la MTU del flujo de datos ni confirma una relación general de cálculo entre MTU y MSS.

Los valores predeterminados contradictorios siguen sin resolverse

La tabla de la API indica literalmente Default: Enable para MSS, aunque describe el campo como INTEGER con un rango numérico. Para InheritToS indica literalmente Default: off, aunque solo enumera Disable y Enable como valores permitidos. Estos valores contradictorios de la documentación no son valores recomendados para un payload y no se corrigen ni se reinterpretan como otros tokens.

Además, la API indica 1500 como valor predeterminado de MTU y describe la herencia de ToS desde la interfaz local. En cambio, la ayuda de WebAdmin para 4in6 indica la MTU de la interfaz física menos 48 bytes, MSS igual a MTU menos 40 bytes y herencia de ToS desde el paquete interno. La correspondencia entre ambas interfaces sigue sin aclararse; las fórmulas correctas y los controles opcionales de WebAdmin descritos arriba no cambian.

Se excluyen las instrucciones de automatización ejecutables que dependan de estos valores predeterminados, reglas de herencia o prioridades entre campos. Por eso no se proporciona aquí un payload de API ejecutable. Se necesita una aclaración de Sophos o una prueba expresamente autorizada en la versión de SFOS correspondiente; los datos documentados del esquema y del estado no son una prueba del producto.

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.

Para añadir rutas IPv6 después de guardar 6to4 o 6rd, SFOS 23 identifica en la ventana emergente los campos Destination IP (IPv6) y Gateway (IPv6). Introducir el destino y el gateway según el diseño y pulsar Save; si no hace falta otra ruta, seleccionar Cancel. Estos campos IPv6 no se aplican a la ruta IPv4 interna de un túnel 4in6. Sigue siendo importante la advertencia de SFOS 22 sobre la configuración guardada al utilizar Cancel.

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.

Para el ejemplo 6in4, ir a Rules and policies > Firewall rules, seleccionar IPv6 y después Add firewall rule > New firewall rule. Configurar Action: Accept, los valores reales de Source zones, Source networks and devices, Destination zones, Destination networks y Services, y activar Log firewall traffic. Colocar la regla de forma que ninguna regla más amplia coincida antes. Las respuestas que pertenecen a una conexión permitida con seguimiento de estado no necesitan una segunda regla. Solo se crea una regla propia e igualmente restringida si el peer debe poder iniciar conexiones nuevas.

En una conexión normal entre sedes se conserva la dirección de origen original. Dejar desactivado Create linked NAT rule; no se activa MASQ para sustituir una ruta de retorno ausente. SFOS deja pasar sin traducir el tráfico permitido cuando ninguna regla NAT coincide. Si el diseño necesita realmente traducción, se planifica y prueba por separado con los flujos original y traducido. 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. En Diagnostics > Tools > Route lookup, introducir la dirección interna 2001:db8:200::20 y confirmar la interfaz de túnel 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. En Diagnostics > Packet capture > Configure, introducir host 192.0.2.10 and host 198.51.100.20 en Enter BPF string para la comprobación externa y guardar. Iniciar la captura, generar una sola prueba y detenerla. Para una captura interna separada, borrar el BPF string en Configure y guardar; después, definir Ethernet type: IPv6 y Destination IP: 2001:db8:200::20 en Display filter y guardar. Iniciar la captura solo durante una prueba y volver a detenerla.
7. En el peer, comprobar entrada, desencapsulación, ruta de retorno y dirección de origen real.
8. Probar una conexión nueva iniciada por el peer solo si una regla propia la permite; la regla con seguimiento de estado ya cubre el tráfico de respuesta.

Una entrada de túnel no demuestra la ruta ni la accesibilidad 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.

Según la ayuda de SFOS 23, eliminar un túnel 6to4 o 6rd también elimina su ruta unicast IPv6 estática creada automáticamente. Esta expectativa no sustituye las comprobaciones de dependencias ni la comparación anterior y posterior. No abarca todas las rutas añadidas manualmente ni se extiende a SFOS 22 basándose únicamente en la ayuda de SFOS 23.

Para el rollback, primero se detiene el tráfico de prueba y se desactiva la nueva regla de firewall. Se eliminan únicamente las rutas manuales creadas para este túnel o se restauran las rutas modificadas al estado inicial anotado. Las rutas automáticas de 6to4 o 6rd se comparan expresamente con el registro anterior y posterior. El túnel solo se elimina cuando ya no queda ninguna dependencia productiva; después se elimina individualmente cualquier ruta automática que permanezca. Finalmente, se confirma la ruta anterior con Route lookup y se vuelve a probar 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