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.

Límites de versión y cliente

Esta guía está diseñada para SFOS 22.0 MR2 Build 546 y la interfaz descrita en la ayuda en línea de 22.0. L2TP está disponible en esta versión. La comprobación de actualización a SFOS 22 de Avanet reúne los bloqueos actuales y las rutas compatibles; antes de cada migración, hay que comparar allí el build de origen concreto con el de destino. No existe una matriz de compatibilidad completa para clientes L2TP nativos. La guía 22.0 solo cita Windows 10 como ejemplo de cliente concreto. Esto no demuestra la compatibilidad con otras versiones, actuales o posteriores, de los sistemas operativos.

Por tanto, cada versión de sistema operativo utilizada debe probarse por separado con el perfil IPsec, el servidor de autenticación y el tipo de ID previstos. El máximo de 254 direcciones del rango solo es un límite de direccionamiento, no una promesa del mismo número de sesiones simultáneas. La ayuda pública de 22.0 no indica un límite general de sesiones L2TP. Hay que validar capacidad y estabilidad en el modelo de firewall real con la concurrencia prevista.

La ayuda actual describe los valores seleccionables, pero no identifica un valor predeterminado universal para Gateway type, Authentication type, Allow NAT traversal o Disconnect when tunnel is idle en configuraciones existentes o migradas. Se deben registrar estos campos antes y después de una actualización en lugar de reconstruirlos a partir de un valor supuesto.

Configurar y verificar el cliente nativo de Windows

En Windows, crear la conexión en Configuración > Red e Internet > VPN > Agregar VPN. Seleccionar Windows (integrado) como proveedor de VPN, introducir el FQDN público o la dirección WAN del firewall como Nombre de servidor o dirección y elegir como tipo de VPN L2TP/IPsec con clave previamente compartida o la opción de certificado que corresponda al perfil del firewall. La clave compartida debe coincidir con el PSK de la política L2TP. Como información de inicio de sesión se usan el nombre y la contraseña de una cuenta autorizada en Add members; documentar conjuntamente el tipo de VPN, el método de inicio de sesión, los ID y la versión del cliente.

Realizar la primera prueba desde una red externa. Después de conectar, usar ipconfig /all para verificar la dirección del rango L2TP y los servidores DNS previstos y, a continuación, probar la resolución de nombres interna y el acceso HTTPS permitido. Si falla el propio establecimiento del túnel, comparar primero el nombre del servidor, el modo PSK o certificado, el método de inicio de sesión y el perfil IPsec acordado, y correlacionar después la marca de tiempo con l2tpd.log y los logs IPsec. Cada versión de Windows utilizada sigue siendo una combinación de cliente que debe validarse por separado.

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.

Después de modificar los ajustes globales y los miembros, pulse Apply. Compruebe de nuevo los valores globales guardados y Show members. La acción Save de la política L2TP es un paso independiente.

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. Idle session time interval se expresa en segundos.

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.

Con varias subredes locales y remotas, se crea un túnel por cada pareja local/remota. Connection puede mostrar un estado parcial: la configuración está activa, pero al menos un túnel no se ha establecido. Pruebe cada pareja necesaria y su flujo de datos por separado; Active habilitado no confirma todos los túneles.

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

El orden predeterminado documentado por Sophos es Static, SD-WAN Policy Routes y después VPN. Para L2TP, las rutas VPN deben evaluarse primero; Static y SD-WAN pueden seguir en cualquier orden. Primero se guarda el estado inicial real 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. Con varias subredes locales y remotas, se crea un túnel por cada pareja local/remota. Connection puede mostrar un estado parcial: la configuración está activa, pero al menos un túnel no se ha establecido. Pruebe cada pareja necesaria y su flujo de datos por separado; Active habilitado no confirma todos los túneles.
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.

Migrar a SFOS 22

La migración del firmware se planifica por separado de cualquier cambio en la configuración L2TP. Antes de actualizar, hay que inventariar el firmware y la plataforma exactos, los ajustes L2TP globales, los usuarios y grupos principales permitidos, cada política L2TP con su perfil, ID y autenticación, Device Access, Route Precedence y las reglas de firewall y NAT asociadas. También se preparan una copia de seguridad cifrada y una vía de administración independiente. La comprobación de actualización a SFOS 22 permite comparar el build de origen concreto con la tabla de actualización vigente; la afirmación general de que las configuraciones pueden migrarse a 22.0 GA no sustituye esta comprobación de ruta.

No hay que confundir L2TP con Remote Access IPsec (legacy): L2TP sigue disponible en SFOS 22.0 MR2, mientras que la variante IPsec heredada se retiró en 22.0 MR1. Un firewall que contenga esa configuración heredada no puede actualizarse a 22.0 MR1 ni a versiones posteriores. Además, SFOS 22.0 GA y posteriores no admiten appliances de hardware XG o SG. Por tanto, la plataforma y los tipos de acceso remoto existentes son condiciones de bloqueo reales, no simples datos de inventario.

SFOS 22.0 MR1 Build 490 corrigió NC-162171, por el que NAS-Identifier no se insertaba en conexiones L2TP con MS-CHAPv2 o MS-CHAP. Si las reglas RADIUS dependen de NAS-Identifier y el firewall procede de un build anterior, después de actualizar hay que verificar no solo el inicio de sesión, sino también la solicitud RADIUS recibida y la política RADIUS que realmente coincide. Esta corrección no demuestra que todas las combinaciones de cliente y autenticación sean automáticamente compatibles.

Después del reinicio, se comparan la versión del firmware y todos los campos inventariados. A continuación se realiza la validación completa desde una red externa, incluida la prueba negativa, DNS, la ruta de datos, el comportamiento idle y un nuevo inicio de sesión después de un failover HA. La vía de acceso anterior se mantiene como respaldo controlado hasta superar estas pruebas.

Un rollback del firmware es más que deshabilitar L2TP. Los firmwares activo y anterior residen en particiones separadas junto con sus respectivos estados de configuración. Arrancar el firmware anterior también activa su estado de configuración previo, por lo que los cambios realizados desde la actualización no forman parte de la configuración en ejecución tras el rollback. Antes de hacerlo, hay que conservar por separado los cambios posteriores necesarios, verificar la versión de destino compatible y confirmar la ventana de mantenimiento para el reinicio.

Realizar un rollback seguro de la configuración L2TP

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