Configurar y probar el acceso remoto L2TP en Sophos Firewall

El acceso remoto L2TP continúa disponible en Sophos Firewall, pero no debería ser automáticamente la primera opción para nuevos endpoints administrados. Sophos Connect con IPsec o SSL VPN se gestiona mejor de forma centralizada y ofrece la ruta de cliente Sophos más completa. L2TP sigue siendo útil cuando un sistema operativo debe usar su cliente VPN nativo o cuando se necesita mantener de forma controlada un entorno compatible existente.

Criterio para nuevos entornos: La ayuda actual de SFOS 22 sigue documentando L2TP como un tipo de acceso remoto configurable. Sophos no ha publicado ningún aviso de retirada para esta función. Sin embargo, esto no garantiza su compatibilidad en una futura versión principal. Avanet no recomienda L2TP como nuevo estándar para clientes administrados. No se debería implementar un nuevo acceso L2TP sin una necesidad concreta de compatibilidad o de continuidad de un entorno existente.

L2TP por sí solo define el túnel, no la seguridad necesaria. En Sophos Firewall, una política IPsec protege la conexión. Por eso deben coincidir el perfil IPsec, la autenticación, la clave precompartida o el certificado y la configuración del cliente. Un estado Active en verde solo significa que la política está habilitada; únicamente el estado Connection y el tráfico real confirman el túnel.

⚠️ La Route Precedence que Sophos exige para L2TP coloca globalmente vpn por delante de Static y SD-WAN Policy Routes. Una nueva política L2TP con un peer comodín también puede afectar a claves precompartidas existentes. Antes de realizar el cambio, hay que documentar el orden actual, una vía de administración independiente y todas las demás rutas VPN, Static y SD-WAN.

L2TP en ocho pasos

1. Confirmar que L2TP es realmente necesario y que el cliente, el perfil IPsec y la autenticación son compatibles.
2. Planificar un rango privado de leases sin solapamientos, servidores DNS internos y un grupo de usuarios restringido.
3. En Remote access VPN > L2TP > L2TP global settings, habilitar L2TP y añadir los usuarios.
4. Crear una política L2TP con el perfil IPsec, el puerto WAN, la autenticación y NAT Traversal correspondientes.
5. En Administration > Device access, permitir el servicio IPsec para la accesibilidad WAN necesaria.
6. Guardar la Route Precedence actual y colocar vpn en primer lugar mediante un cambio controlado.
7. Crear una regla de firewall restringida y con logging desde la zona VPN hacia los destinos internos realmente necesarios.
8. Con un cliente piloto externo, validar la autenticación, la dirección asignada, DNS, la regla, la ruta de retorno y una prueba negativa.

Cuándo encaja L2TP

L2TP puede resultar útil para clientes nativos del sistema operativo o dispositivos existentes en los que no se prevé usar Sophos Connect. También es una opción razonable cuando se desea mantener un entorno L2TP pequeño y ya documentado sin software cliente adicional.

Para un nuevo despliegue estándar suele ser más adecuado Sophos Connect con IPsec o SSL VPN. La distribución de perfiles, el diagnóstico del cliente y la vía de soporte específica de Sophos son más claros. PPTP no es una alternativa moderna: el propio protocolo no define cifrado y ya no debería planificarse para nuevos accesos remotos.

Antes de configurar, deben quedar claros tres límites:

• En Sophos Firewall, L2TP utiliza un único rango global compartido y ajustes DNS comunes para todas las políticas L2TP.
• Los grupos importados desde Active Directory o Microsoft Entra ID no quedan habilitados automáticamente para L2TP. Deben añadirse explícitamente mediante Add members.
• L2TP y PPTP solo tienen en cuenta el grupo principal relevante al evaluar la pertenencia a grupos. Por tanto, una pertenencia adicional no demuestra por sí sola la autorización. Gestionar correctamente los grupos de usuarios y el grupo principal explica el contexto.

Ejemplo y preparación

El ejemplo conecta un cliente externo con una red interna de aplicaciones. Los valores son ejemplos de documentación y deben adaptarse al entorno real:

• rango L2TP: de 10.250.30.10 a 10.250.30.100 dentro de 10.250.30.0/24
• servidor DNS interno: 10.10.10.10
• grupo permitido: L2TP_Users
• nombre de la política: L2TP_Remote_Access
• perfil IPsec: DefaultL2TP como punto de partida de la prueba de compatibilidad
• red de destino interna: 10.10.10.0/24
• servicio de ejemplo: HTTPS

El rango 10.250.30.0/24 solo es una red privada de ejemplo. No debe solaparse con redes LAN, VLAN, Site-to-Site o domésticas ni con los rangos de leases de Remote Access IPsec, SSL VPN o PPTP. Sophos permite como máximo 254 direcciones en Assign IP from, dentro de una subred /24 o más pequeña.

Antes de empezar, comprobar también lo siguiente:

• Un perfil IPsec adecuado coincide con los ajustes compatibles con el cliente nativo.
• La dirección pública o el FQDN del puerto WAN seleccionado es accesible desde el cliente.
• La hora del sistema, DNS y la cadena de certificados son correctos cuando se utiliza un certificado.
• El usuario o grupo existe y el método de autenticación correcto está configurado en Authentication > Services > VPN (IPsec/dial-in/L2TP/PPTP) authentication methods.
• Se han documentado la salida actual de system route_precedence show y un comando de rollback correspondiente.
• WebAdmin o la consola sigue siendo accesible mediante una vía de administración independiente.

La fuente de autenticación y el cliente deben admitir el mismo método: SFOS enumera PAP, CHAP o MSCHAPv2 para Local y RADIUS, solo PAP para Active Directory y LDAP, y PAP o CHAP para TACACS+. Antes del despliegue, comprobar el método común con el cliente nativo. La protección IPsec exterior sigue siendo obligatoria para L2TP; esta matriz de compatibilidad no es una recomendación para PPTP ni para el uso de PAP sin protección.

Configurar los ajustes globales de L2TP

En Remote access VPN > L2TP > L2TP global settings, activar Enable L2TP. En este ejemplo, introducir de 10.250.30.10 a 10.250.30.100 en Assign IP from. Seleccionar 10.10.10.10 como Primary DNS server si este servidor puede resolver los nombres internos. Configurar DNS secundario y WINS solo cuando el entorno los necesite realmente.

La opción Allow leasing IP address from RADIUS server for L2TP, PPTP, and Sophos Connect client solo es útil si el servidor RADIUS proporciona de forma fiable una dirección adecuada. Si no entrega ninguna, el firewall utiliza primero una dirección estática configurada para el usuario o después el rango global. Por tanto, tanto la asignación RADIUS como la ruta de respaldo deben planificarse sin solapamientos. Configurar RADIUS en Sophos Firewall explica la configuración del servidor.

A continuación, añadir el grupo L2TP_Users mediante Add members y comprobarlo con Show members. Para un usuario de directorio, una importación correcta del grupo no es suficiente. Un usuario piloto debe pertenecer realmente al grupo autorizado, y ese grupo debe ser el grupo principal que interviene en la evaluación L2TP.

Crear la política L2TP

En Remote access VPN > L2TP, utilizar Add para crear la política L2TP_Remote_Access.

Perfil y comportamiento de inicio

En Profile, seleccionar el perfil IPsec que coincida con los clientes. En el ejemplo, el perfil existente DefaultL2TP sirve como punto de partida de la prueba de compatibilidad. Aun así, sus algoritmos y lifetimes deben compararse con los valores admitidos por el cliente; que el nombre contenga Default no es una garantía de seguridad permanente. Los dos valores de Gateway type tienen consecuencias operativas distintas:

• Respond only mantiene la política preparada después de un reinicio para responder a solicitudes entrantes.
• Disable la deja inactiva hasta que se encienda manualmente mediante el estado Active.

Para un servicio de acceso remoto productivo, Respond only suele ser el punto de partida más comprensible. Esta elección debe comprobarse expresamente después de reiniciar el firewall o el servicio para no confundir activación con estado de conexión.

Autenticación y clave precompartida

Los valores disponibles de Authentication type son Preshared key y Digital certificate. Los certificados evitan un PSK compartido, pero requieren una cadena de confianza completamente planificada y soporte adecuado en el cliente. Un PSK debe ser largo, aleatorio, transmitirse por separado y renovarse de forma controlada.

Sophos utiliza el último PSK configurado para todas las conexiones con la misma interfaz de escucha y el mismo peer remoto. En Remote Access, Remote host suele configurarse como *. Por tanto, una política comodín nueva o modificada puede sustituir el PSK de configuraciones Remote Access existentes. Antes de guardar, hay que revisar todas las políticas que utilizan el mismo puerto WAN y gateway comodín.

Con un PSK, definir valores coincidentes para Local ID y Remote ID. El tipo de ID DER ASN1DN (X.509) no se acepta con PSK. Los ID deben coincidir con el cliente nativo y no deben establecerse en valores arbitrarios por comodidad.

Puerto WAN, peer y selectores

En Local WAN port, seleccionar el puerto WAN que sea realmente accesible. Para clientes con direcciones cambiantes, configurar Remote host con el comodín *. Activar Allow NAT traversal cuando los clientes estén detrás de NAT, algo habitual en redes domésticas, móviles y de hoteles.

Para el flujo típico de Remote Access, el ejemplo de Sophos utiliza Remote subnet: Any, Local port: 1701 y Remote port: *. 1701 es el puerto L2TP del firewall; el puerto del cliente puede variar. Estos valores son selectores del túnel y no sustituyen una regla de firewall. El acceso posterior sigue limitado a zonas, destinos y servicios concretos.

Con Disconnect when tunnel is idle, el firewall puede desconectar clientes inactivos después del periodo indicado en Idle session time interval. El valor se adapta al patrón de trabajo real y se prueba con pausas realistas. Un intervalo demasiado corto provoca reconexiones innecesarias; sin límite, las sesiones olvidadas pueden permanecer establecidas más tiempo.

Después de Save, activar la política mediante el icono rojo de la columna Active. El color verde en Active todavía no significa que haya un cliente conectado. El estado Connection independiente muestra si el túnel se ha establecido realmente.

Accesibilidad, routing y regla de firewall

Permitir IPsec en WAN

En Administration > Device access, IPsec debe estar permitido para la accesibilidad WAN necesaria. Esta autorización se aplica de la forma más restringida que permita la topología. Un PSK robusto o un certificado no justifica un acceso innecesariamente amplio a WebAdmin, User Portal o SSH. Device Access y Local Service ACL explica la separación entre accesibilidad del servicio y autorización del usuario.

Establecer Route Precedence de forma controlada

Sophos exige que las rutas VPN se evalúen antes que Static y SD-WAN Policy Routes para L2TP. Primero se guarda el estado inicial en Device Console:

system route_precedence show

Después se establece el orden documentado para L2TP y se comprueba de nuevo:

system route_precedence set vpn static sdwan_policyroute
system route_precedence show

Este cambio es global y no es un interruptor aislado para la nueva política L2TP. Antes y después deben probarse las rutas Static, SD-WAN y VPN que se solapen, además del acceso de administración. Ajustar Route Precedence en Sophos Firewall explica el efecto y el rollback seguro.

Permitir el acceso a destinos internos

En Rules and policies > Firewall rules, crear una regla IPv4 con logging. El ejemplo de Sophos con Any para origen, destino y servicio es sencillo para una primera prueba funcional, pero no es un buen estándar de seguridad permanente. Este ejemplo es más restrictivo:

• Source zone: VPN
• Source network: el rango L2TP 10.250.30.0/24 o un objeto IP host correspondiente
• Destination zone: la zona que contiene la red de aplicaciones
• Destination network: 10.10.10.0/24 o, preferiblemente, los servidores necesarios
• Services: HTTPS o solo los servicios realmente necesarios
• Log firewall traffic: activado

El tráfico de internet a través del firewall requiere una regla independiente de VPN a WAN y un diseño deliberado de NAT y seguridad. Este acceso no se crea automáticamente solo porque el túnel L2TP esté establecido.

Validar la conexión

La validación se realiza desde una red externa real. Una prueba desde la misma LAN o a través de una ruta VPN existente puede ocultar problemas de routing, NAT y accesibilidad pública.

1. Conectar con un usuario piloto autorizado y la configuración de cliente documentada.
2. En Remote access VPN > L2TP, comprobar por separado los estados Active y Connection.
3. Verificar que el cliente recibe una dirección entre 10.250.30.10 y 10.250.30.100, además de los servidores DNS previstos.
4. Resolver un nombre interno y acceder mediante HTTPS a un destino autorizado expresamente.
5. En Log Viewer, comprobar la Firewall Rule ID esperada, la IP de origen del rango L2TP, el destino, el servicio y la acción.
6. Verificar la ruta de retorno desde la red de destino hacia el rango L2TP y repetir el mismo acceso después de volver a conectar.
7. Realizar una prueba negativa con un usuario que no se haya añadido; no debe obtener un túnel utilizable.
8. Probar el comportamiento idle, la desconexión, la reconexión y, en HA, un failover controlado con un nuevo inicio de sesión.

Una autenticación correcta no demuestra la ruta de datos. Del mismo modo, un túnel en verde no demuestra que DNS, la regla, NAT y la ruta de retorno sean correctos. Probar reglas de Sophos Firewall explica cómo separar las evidencias de Log Viewer y Packet Capture.

Diagnosticar los fallos de forma sistemática

La política está activa, pero el túnel permanece down

Primero comparar el puerto WAN, la accesibilidad pública, IPsec en Device Access, NAT Traversal, la dirección del cliente, el PSK o certificado, Local/Remote ID y el perfil IPsec. Después comprobar si una política comodín guardada más recientemente ha sustituido el PSK esperado.

Para la primera separación, usar l2tpd.log para L2TP y strongswan.log o charon.log para la negociación IPsec. Servicios y archivos de log de Sophos Firewall ofrece la relación completa. Correlacionar los logs con la hora exacta, el usuario, la IP pública del cliente y el nombre de la política; reiniciar el servicio no es el primer paso de diagnóstico.

Falla el inicio de sesión o el usuario no obtiene acceso

En Authentication > Services, comprobar el método para VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Después verificar si el usuario o grupo está incluido en Add members y qué grupo aparece como grupo principal en el objeto de usuario. Con RADIUS, comprobar además por separado la autenticación y la asignación opcional del lease.

El túnel está up, pero los destinos internos son inaccesibles

Comprobar por este orden la dirección asignada, Route Precedence, Firewall Rule ID, la ruta al destino y la ruta de retorno. Una ruta SD-WAN amplia o una Static Route competidora puede cambiar el recorrido. El rango L2TP debe ser accesible desde la red interna sin que una segunda ruta idéntica o una red solapada se apodere del retorno.

Si Log Viewer muestra Rule 0, una Rule ID inesperada o ninguna entrada coincidente, hay que identificar la regla real antes de ampliar nada a Any. Si el paquete de ida es visible pero no vuelve ninguna respuesta, continuar en el host de destino, su gateway, firewall local o ruta de retorno.

La conexión es lenta o inestable

Comprobar latencia, pérdida de paquetes, MTU o fragmentación, cambios de WAN y uso de CPU durante una prueba reproducible. Una única transferencia SMB no es una prueba limpia del rendimiento VPN. Varios flujos TCP controlados en ambas direcciones ayudan a separar túnel, transporte y aplicación.

Si solo son inestables las conexiones L2TP, comparar las marcas de tiempo de l2tpd.log, los logs IPsec, los eventos WAN y el log del cliente. Modificar el perfil, MTU o idle time de uno en uno y dentro de una ventana de mantenimiento solo cuando se haya demostrado una relación concreta.

Realizar un rollback seguro

Durante el rollback se mantiene abierta la vía de administración independiente. Primero se restaura exactamente la Route Precedence guardada y se prueban las rutas de administración, Static, SD-WAN y VPN. Después se deshabilita la política L2TP y se confirma con un cliente piloto que ya no queda ninguna dependencia productiva.

A continuación, se pueden retirar las reglas de firewall y la autorización IPsec si ningún otro servicio depende de ellas. Solo entonces se eliminan los usuarios de Add members y se desactiva Enable L2TP. El Preshared Key no se restablece a ciegas a un valor anterior; todas las políticas que usan el mismo puerto WAN y gateway comodín se revisan en conjunto.

FAQ