Configurar y probar un túnel GRE en Sophos Firewall

Un túnel GRE conecta dos endpoints IP y transporta tráfico enrutado en su interior. En Sophos Firewall se crea en Device Console con system gre. Es adecuado, por ejemplo, para un on-ramp de proveedor, una ruta overlay sencilla o un transporte que requiera GRE expresamente.

Respuesta rápida

Para una configuración segura, primero se documentan los endpoints WAN exteriores, las IP interiores del túnel y las redes remotas. Después:

1. Comprobar la conectividad underlay entre ambos endpoints WAN y el protocolo IP 47.
2. Crear el túnel GRE de forma simétrica en ambos firewalls con system gre tunnel add.
3. Verificar nombres, endpoints, IP del túnel y estado con system gre tunnel show.
4. Asignar las redes remotas al túnel con system gre route add.
5. Crear reglas de firewall restrictivas y con logging entre LAN y VPN.
6. Probar por separado GRE en la ruta WAN, la ruta interior, Rule ID, el tráfico de aplicación y la ruta de retorno.

⚠️ GRE no proporciona cifrado ni autenticación por sí mismo. En una red no fiable solo se utiliza GRE si el diseño de seguridad acepta expresamente el transporte sin cifrar. Si se necesita confidencialidad o autenticación del peer, normalmente es más adecuada una VPN IPsec site-to-site.

Diferenciar endpoints GRE, IP del túnel y rutas

Un diseño GRE consta de varias capas:

• Local gateway: la interfaz WAN local de Sophos Firewall, por ejemplo Port2.
• Remote gateway: la dirección IPv4 exterior del peer.
• Local IP y Remote IP: las direcciones punto a punto interiores del túnel GRE.
• Ruta GRE: asigna un host o una red de destino remotos al túnel.
• Regla de firewall: permite el flujo de datos concreto entre zonas y redes.
• Ruta de retorno: devuelve los paquetes de respuesta por el túnel simétrico.

GRE sobre IPv4 utiliza el protocolo IP 47. No es TCP ni UDP y no debe confundirse con el puerto 47. Por tanto, un router anterior, un filtro del proveedor o una lista de seguridad cloud debe poder transportar este protocolo IP entre los dos endpoints exteriores.

El estado visible Enabled confirma que la configuración GRE está guardada y activada. Todavía no demuestra que el peer responda, que la ruta sea correcta o que una aplicación funcione.

Cuándo utilizar GRE y cuándo es preferible IPsec

GRE es ligero y transporta tráfico enrutado entre dos endpoints definidos. Es adecuado cuando un proveedor o una plataforma requiere GRE, cuando solo se necesita encapsulación o cuando una ruta underlay fiable ya está protegida por separado.

GRE no sustituye una interconexión de sedes cifrada. Para conexiones normales a través de Internet público, IPsec route-based suele ser el mejor punto de partida. Combinar GRE e IPsec requiere un diseño independiente probado en ambos dispositivos; este procedimiento básico no crea una ruta GRE-over-IPsec sin verificar.

Este artículo trata un túnel IPv4 punto a punto estático. Multicast, PIM-SM, BGP sobre GRE y los túneles anycast específicos de un proveedor son ampliaciones posibles, pero solo se planifican después de que funcione la ruta unicast básica.

Planificar la topología de ejemplo

El ejemplo conecta dos Sophos Firewalls:

• WAN de la sede A: Port2 con 192.0.2.10
• LAN de la sede A: 10.10.10.0/24
• IP del túnel de la sede A: 10.255.255.1
• WAN de la sede B: Port2 con 198.51.100.20
• LAN de la sede B: 10.20.20.0/24
• Servidor de prueba de la sede B: 10.20.20.10
• IP del túnel de la sede B: 10.255.255.2
• Red del túnel: 10.255.255.0/30
• Servicio de prueba: HTTPS o TCP 443

192.0.2.0/24 y 198.51.100.0/24 son redes de documentación y no se utilizan en producción. Las dos direcciones WAN, las interfaces, las IP del túnel, las redes LAN y el servidor de prueba se sustituyen conjuntamente por los valores reales. Las IP del túnel deben formar una red punto a punto propia, planificada de forma idéntica en ambos lados, y no pueden solaparse con redes existentes.

El ejemplo utiliza los nombres de túnel gre_branch en la sede A y gre_hq en la sede B. Los nombres se pueden elegir libremente, pero la API actual de SFOS 22 los limita a 15 caracteres.

Antes del cambio se preparan una copia de seguridad de la configuración, una ventana de mantenimiento y un acceso de administración independiente para la recuperación. También se registran las rutas estáticas y SD-WAN, las reglas NAT, las reglas de firewall y las redes solapadas existentes.

Comprobar los requisitos de la ruta exterior

Ambos endpoints WAN deben poder alcanzarse a través del underlay. El diseño básico utiliza direcciones IPv4 estáticas en ambos lados. Si la dirección WAN local se obtiene mediante PPPoE o DHCP, no se continúa con este procedimiento: las instrucciones oficiales antiguas de Sophos para GRE excluyen las interfaces WAN locales dinámicas, mientras que la API actual de SFOS 22 solo documenta DDNS para Remote Gateway. Por tanto, debe aclararse la compatibilidad para el build y la conexión concretos.

Antes de configurar el túnel se comprueba lo siguiente:

• La dirección WAN remota se enruta por el gateway WAN previsto.
• Los routers anteriores, los proveedores y las ACL cloud permiten el protocolo IP 47 entre ambos endpoints.
• No existe un diseño CGNAT o NAT cuyo comportamiento con GRE no esté aclarado.
• Las IP interiores del túnel y las redes LAN no se solapan ni local ni remotamente.
• El peer utiliza los mismos valores exteriores e interiores de forma inversa.
• Existe una ruta de retorno planificada hacia ambas redes LAN.

Un ping al peer público puede respaldar la prueba del underlay, pero no demuestra compatibilidad con GRE. Del mismo modo, permitir el puerto TCP o UDP 47 no sirve porque GRE no es un protocolo de transporte basado en puertos.

Crear el túnel GRE en ambos firewalls

La configuración se realiza en el menú de CLI 4. Device Console. La página de ayuda actual de Sophos contiene fragmentos de sintaxis mal renderizados. Antes del cambio se utiliza Tab o ? en el build instalado para confirmar que se ofrecen los parámetros siguientes.

Configurar la sede A

En el firewall A se introducen el puerto WAN local Port2, el peer exterior 198.51.100.20 y el par interior del túnel:

system gre tunnel add name gre_branch local-gw Port2 remote-gw 198.51.100.20 local-ip 10.255.255.1 remote-ip 10.255.255.2

Después se realiza esta comprobación de solo lectura:

system gre tunnel show

La entrada debe mostrar correctamente gre_branch, Port2, la dirección WAN remota y las dos IP del túnel. Un error tipográfico no se oculta creando una segunda configuración con un nombre parecido.

Configurar la sede B de forma simétrica

En el firewall B se intercambian los valores locales y remotos:

system gre tunnel add name gre_hq local-gw Port2 remote-gw 192.0.2.10 local-ip 10.255.255.2 remote-ip 10.255.255.1

También aquí se realiza la comprobación de solo lectura:

system gre tunnel show

En este momento, Enabled solo es una comprobación intermedia. La validación termina únicamente con un flujo de datos LAN a LAN real.

Enrutar las redes remotas a través de GRE

Para la ruta fija sencilla se añade una ruta GRE en cada firewall. La sede A envía la LAN de la sede B por gre_branch:

system gre route add net 10.20.20.0/255.255.255.0 tunnelname gre_branch

La sede B recibe la ruta de retorno simétrica:

system gre route add net 10.10.10.0/255.255.255.0 tunnelname gre_hq

Después se leen las asignaciones configuradas en ambos dispositivos:

system gre route show

La ruta no debe competir con una ruta estática, SD-WAN, VPN o directamente conectada de igual longitud o más específica. No se modifica Route Precedence global por sospecha. Primero se demuestra qué ruta coincide realmente y cuál es la ruta de los paquetes.

Custom Gateway y SD-WAN como alternativa

Algunos diseños de proveedor utilizan un Custom Gateway en la ruta GRE en lugar de la ruta GRE sencilla y lo seleccionan en una ruta SD-WAN. Esto encaja cuando Source, Service, failover o un estado de gateway definido deben influir en la decisión de enrutamiento.

La IP remota del túnel es el next hop. Health Check, Zone y Probe Target deben corresponder al diseño concreto del proveedor; que una guía de fabricante desactive la monitorización no constituye un estándar universal. Crear y comprobar un Custom Gateway en Sophos Firewall explica cómo se relacionan el objeto, la prueba y el test de tráfico real. La selección de ruta se describe en Configurar una ruta SD-WAN en Sophos Firewall.

No se activan sin control una ruta GRE y una ruta SD-WAN para las mismas redes. Antes del cambio se documenta qué mecanismo debe ganar y cómo volver a la ruta anterior.

Crear reglas de firewall sin NAT innecesario

El túnel GRE y su ruta todavía no permiten tráfico de aplicación. Una conexión HTTPS iniciada desde la sede A necesita una regla restrictiva y con logging en ambos firewalls.

En el firewall A:

• Source zone: LAN
• Source network: 10.10.10.0/24
• Destination zone: VPN
• Destination network: 10.20.20.10
• Services: HTTPS
• Action: Accept
• Log firewall traffic: activado

En el firewall B se permite el tráfico entrante del túnel hacia el servidor de prueba:

• Source zone: VPN
• Source network: 10.10.10.0/24
• Destination zone: LAN
• Destination network: 10.20.20.10
• Services: HTTPS
• Action: Accept
• Log firewall traffic: activado

Estas dos reglas cubren la conexión iniciada desde la sede A y su tráfico de retorno stateful. Si los hosts de la sede B pueden iniciar nuevas conexiones hacia la sede A, se crea además el par de reglas simétrico de LAN a VPN en el firewall B y de VPN a LAN en el firewall A, solo con las redes y servicios realmente necesarios. No se necesita una regla amplia Any para la validación.

En una interconexión de sedes normal se conserva la IP de origen original. No se activa MASQ como aparente solución de routing. Si falta la ruta de retorno, se corrige en el peer. Crear y comprobar de forma segura reglas de Sophos Firewall explica el diseño general de reglas.

Validar conjuntamente el túnel y el tráfico de aplicación

La comprobación sigue la ruta de los paquetes y separa la configuración del funcionamiento real:

1. Ejecutar system gre tunnel show en ambos firewalls y comparar endpoints e IP del túnel.

2. Utilizar system gre route show para verificar la LAN remota correspondiente y el nombre de túnel correcto.

3. Desde un cliente en 10.10.10.0/24, iniciar una nueva conexión HTTPS a 10.20.20.10.

4. En Log viewer de ambos firewalls, comprobar Source, Destination, Service, Firewall Rule ID, NAT Rule ID y Zone.

5. En Diagnostics > Packet capture de la sede A, filtrar la ruta GRE exterior:

   host 198.51.100.20 and ip proto 47
   

6. Filtrar por separado el flujo de prueba interior:

   host 10.20.20.10 and tcp port 443
   

7. Comparar la entrada y salida en ambos firewalls y comprobar la IP de origen real en el servidor de destino.

8. Realizar una prueba de retorno solo con un servicio permitido para ello.

La captura exterior muestra la encapsulación entre los endpoints WAN. La captura interior y Rule ID muestran si el paquete útil sigue la regla y la ruta esperadas. Solo el funcionamiento correcto de la aplicación confirma toda la ruta. El procedimiento combinado se explica con más detalle en Probar reglas de firewall y Utilizar Packet Capture.

Delimitar errores según el síntoma

Ningún paquete GRE sale de la interfaz WAN

• Comprobar Remote Gateway y el local-gw local del túnel.
• Comprobar la ruta underlay hacia la dirección WAN remota y el gateway WAN seleccionado.
• Asegurarse de que el flujo de prueba coincide realmente con la ruta GRE o la ruta SD-WAN prevista.
• Comparar nombres y asignaciones con system gre tunnel show y system gre route show.
• No crear una regla de puerto TCP o UDP como sustituto del protocolo IP 47.

GRE sale de la sede A pero no llega a la sede B

• Comprobar el protocolo IP 47 en proveedores, routers anteriores, ACL cloud y posibles rutas NAT.
• Capturar simultáneamente en la sede B con el filtro WAN exterior.
• Comparar las direcciones de origen y destino exteriores con la configuración del peer.
• Con una WAN dinámica, CGNAT o un diseño NAT no aclarado, detenerse en lugar de ocultar el problema con reglas amplias.

GRE es visible en ambos lados WAN, pero falta el tráfico interior

• Local IP y Remote IP deben estar invertidas simétricamente en ambos firewalls.
• Comparar carácter por carácter la ruta GRE, la red de destino y el nombre del túnel.
• Comprobar la regla de firewall y la Rule ID esperada en ambos lados.
• Descartar redes solapadas, NAT y una ruta de retorno ausente.
• No considerar Enabled una prueba de la ruta interior o de la aplicación.

Solo funciona una dirección

• Comprobar la ruta GRE de la red de retorno en la sede B.
• Determinar si la sede B debe iniciar nuevas conexiones y, por tanto, necesita su propia regla de firewall.
• Comprobar el gateway predeterminado, el firewall local del host y la IP de origen real en el servidor de destino.
• Comparar rutas SD-WAN o estáticas asimétricas en ambos lados.

Los paquetes pequeños funcionan, pero las conexiones grandes se bloquean

GRE añade una cabecera IP exterior y una cabecera GRE. Esto reduce el tamaño útil de los paquetes respecto al underlay. No se adopta un valor fijo de MTU o MSS sin comprobarlo: primero se miden la MTU del underlay, Path MTU Discovery, la fragmentación y la aplicación afectada. Comprobar MTU y MSS en problemas de VPN explica el procedimiento controlado.

Probar HA y la operación con precaución

La documentación pública actual de Sophos no promete un failover HA sin interrupciones ni un estado del túnel GRE sincronizado. Por tanto, un cambio de roles controlado solo se realiza en una ventana de mantenimiento con acceso de administración independiente.

Después del cambio se vuelven a comprobar system gre tunnel show, system gre route show, la captura GRE exterior, una nueva conexión de cliente, Rule ID y la ruta de retorno. Una conexión TCP existente no demuestra continuidad.

En la operación se documentan el responsable, ambos endpoints WAN, las IP del túnel, los nombres de túnel, las redes remotas, el mecanismo de routing, las reglas de firewall, el límite de MTU esperado y la última prueba de tráfico real. Después de cambios en WAN, proveedor, NAT, SD-WAN, Route Precedence o peer, se vuelve a validar toda la ruta.

Realizar un rollback seguro

El rollback se coordina en ambos firewalls:

1. Detener el tráfico de prueba y guardar el último estado con system gre tunnel show y system gre route show.

2. Desactivar las nuevas reglas de firewall y cualquier ruta SD-WAN creada para la prueba.

3. Si se utiliza, retirar el Custom Gateway de la ruta solo después de comprobar Object usage.

4. En la sede A, eliminar la ruta GRE concreta:

   system gre route del net 10.20.20.0/255.255.255.0 tunnelname gre_branch
   

5. En la sede B, eliminar la ruta de retorno:

   system gre route del net 10.10.10.0/255.255.255.0 tunnelname gre_hq
   

6. Comprobar con system gre route show que solo han desaparecido las entradas previstas.

7. Después, eliminar el túnel de la sede A por su nombre exacto:

   system gre tunnel del name gre_branch
   

8. En la sede B, eliminar únicamente el túnel configurado allí:

   system gre tunnel del name gre_hq
   

9. Finalizar con system gre tunnel show y una prueba de la ruta anterior.

No se utiliza del All. Si la sintaxis o el nombre del objeto no están claros en el build instalado, se comprueban con Tab o ? antes de eliminar y no se adivinan.

Preguntas frecuentes