Configurar e testar L2TP Remote Access na Sophos Firewall

O L2TP Remote Access continua disponível na Sophos Firewall, mas não deve ser automaticamente a primeira escolha para novos endpoints geridos. Sophos Connect com IPsec ou SSL VPN é mais fácil de operar centralmente e oferece o percurso de cliente Sophos mais completo. O L2TP continua a ser útil quando um sistema operativo tem de utilizar o cliente VPN nativo ou quando é necessário manter de forma controlada um ambiente compatível existente.

Avaliação para novos ambientes: A ajuda atual do SFOS 22 continua a documentar o L2TP como um tipo de acesso remoto configurável. A Sophos não publicou qualquer aviso de descontinuação para esta funcionalidade. No entanto, isso não garante suporte numa futura versão principal. A Avanet não recomenda o L2TP como novo padrão para clientes geridos. Não se deve implementar um novo acesso L2TP sem uma necessidade concreta de compatibilidade ou de continuidade de um ambiente existente.

O L2TP, por si só, define o túnel, não a segurança necessária. Na Sophos Firewall, uma política IPsec protege a ligação. Por isso, o perfil IPsec, a autenticação, a preshared key ou o certificado e a configuração do cliente têm de corresponder. Um estado Active verde também significa apenas que a política está ativa; só o estado Connection e o tráfego real confirmam o túnel.

⚠️ A Route Precedence exigida pela Sophos para L2TP coloca globalmente vpn antes de Static e SD-WAN Policy Routes. Uma nova política L2TP com um peer wildcard também pode afetar preshared keys existentes. Antes da alteração, é necessário documentar a ordem atual, um acesso de gestão independente e todos os outros percursos VPN, Static e SD-WAN.

L2TP em oito passos

1. Confirmar que o L2TP é realmente necessário e que o cliente, o perfil IPsec e a autenticação são compatíveis.
2. Planear um intervalo privado de leases sem sobreposição, servidores DNS internos e um grupo de utilizadores restrito.
3. Em Remote access VPN > L2TP > L2TP global settings, ativar o L2TP e adicionar os utilizadores.
4. Criar uma política L2TP com o perfil IPsec, porta WAN, autenticação e NAT Traversal adequados.
5. Em Administration > Device access, permitir o serviço IPsec para a acessibilidade WAN necessária.
6. Guardar a Route Precedence atual e colocar vpn em primeiro lugar através de uma alteração controlada.
7. Criar uma regra de firewall restrita e com logging da zona VPN para os destinos internos realmente necessários.
8. Com um cliente piloto externo, validar a autenticação, o endereço atribuído, DNS, a regra, o percurso de retorno e um teste negativo.

Quando o L2TP é adequado

O L2TP pode ser útil para clientes nativos do sistema operativo ou dispositivos existentes nos quais não está previsto o Sophos Connect. É também uma escolha compreensível quando um pequeno ambiente L2TP já documentado deve continuar a funcionar sem software de cliente adicional.

Para um novo rollout padrão, o Sophos Connect com IPsec ou SSL VPN é normalmente mais adequado. A distribuição de perfis, o diagnóstico do cliente e o percurso de suporte específico da Sophos são mais claros. O PPTP não é uma alternativa moderna: o próprio protocolo não define encriptação e não deve continuar a ser planeado para novos acessos remotos.

Antes da configuração, três limites devem estar claros:

• Na Sophos Firewall, o L2TP utiliza um único pool global de endereços partilhado e definições DNS comuns para todas as políticas L2TP.
• Os grupos importados de Active Directory ou Microsoft Entra ID não são ativados automaticamente para L2TP. Têm de ser adicionados explicitamente através de Add members.
• O L2TP e o PPTP consideram apenas a Main Group relevante ao avaliar a pertença a grupos. Por isso, uma pertença adicional, por si só, não comprova autorização. Gerir corretamente grupos de utilizadores e Main Group explica o contexto.

Exemplo e preparação

O exemplo liga um cliente externo a uma rede de aplicações interna. Os valores são deliberadamente valores de documentação e têm de ser adaptados ao ambiente local:

• pool L2TP: 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
• nome da política: L2TP_Remote_Access
• perfil IPsec: DefaultL2TP como ponto de partida para o teste de compatibilidade
• rede de destino interna: 10.10.10.0/24
• serviço de exemplo: HTTPS

O intervalo 10.250.30.0/24 é apenas uma rede privada de exemplo. Não pode sobrepor-se a redes LAN, VLAN, Site-to-Site ou domésticas, nem aos intervalos de leases utilizados por Remote Access IPsec, SSL VPN ou PPTP. A Sophos permite no máximo 254 endereços em Assign IP from, dentro de uma sub-rede /24 ou menor.

Antes de começar, verificar também o seguinte:

• Um perfil IPsec adequado corresponde às definições suportadas pelo cliente nativo.
• O endereço público ou FQDN da porta WAN selecionada está acessível a partir do cliente.
• A hora do sistema, DNS e a cadeia de certificados estão corretos quando é utilizado um certificado.
• O utilizador ou grupo existe e o método de autenticação correto está configurado em Authentication > Services > VPN (IPsec/dial-in/L2TP/PPTP) authentication methods.
• O resultado atual de system route_precedence show e um comando de rollback correspondente estão documentados.
• O WebAdmin ou a consola continua acessível através de um percurso de gestão independente.

A origem de autenticação e o cliente têm de suportar o mesmo método: o SFOS enumera PAP, CHAP ou MSCHAPv2 para Local e RADIUS, apenas PAP para Active Directory e LDAP, e PAP ou CHAP para TACACS+. Antes da implementação, verificar o método comum com o cliente nativo. A proteção IPsec exterior continua a ser obrigatória para L2TP; esta matriz de compatibilidade não é uma recomendação para PPTP nem para a utilização de PAP sem proteção.

Configurar as definições globais de L2TP

Em Remote access VPN > L2TP > L2TP global settings, ativar Enable L2TP. Neste exemplo, introduzir 10.250.30.10 a 10.250.30.100 em Assign IP from. Selecionar 10.10.10.10 como Primary DNS server se este servidor conseguir resolver os nomes internos. Configurar DNS secundário e WINS apenas quando o ambiente realmente necessita deles.

A opção Allow leasing IP address from RADIUS server for L2TP, PPTP, and Sophos Connect client só é útil quando o servidor RADIUS fornece de forma fiável um endereço adequado. Se não devolver um endereço, a firewall utiliza primeiro um endereço estático configurado para o utilizador ou depois o pool global. Tanto a atribuição RADIUS como o percurso de fallback têm, por isso, de ser planeados sem sobreposições. Configurar RADIUS na Sophos Firewall explica a configuração do servidor.

Em seguida, adicionar o grupo L2TP_Users através de Add members e verificá-lo com Show members. Para um utilizador de diretório, uma importação bem-sucedida do grupo não é suficiente. Um utilizador piloto tem de pertencer realmente ao grupo permitido, e esse grupo tem de ser a Main Group utilizada na avaliação L2TP.

Criar a política L2TP

Em Remote access VPN > L2TP, utilizar Add para criar a política L2TP_Remote_Access.

Perfil e comportamento no arranque

Em Profile, selecionar o perfil IPsec que corresponde aos clientes. No exemplo, o perfil existente DefaultL2TP serve como ponto de partida para o teste de compatibilidade. Os algoritmos e lifetimes continuam a ter de ser comparados com os valores suportados pelo cliente; um nome que contém Default não é uma garantia de segurança permanente. Os dois valores de Gateway type têm consequências operacionais diferentes:

• Respond only mantém a política pronta após um reinício, para que possa responder a pedidos recebidos.
• Disable mantém-na inativa até ser ligada manualmente através do estado Active.

Para um serviço Remote Access produtivo, Respond only é normalmente o ponto de partida mais compreensível. Esta escolha deve ser verificada explicitamente após um reinício da firewall ou do serviço, para não confundir ativação com estado da ligação.

Autenticação e preshared key

Os valores disponíveis de Authentication type são Preshared key e Digital certificate. Os certificados evitam um PSK partilhado, mas exigem uma cadeia de confiança totalmente planeada e suporte adequado no cliente. Um PSK tem de ser longo, aleatório, transmitido separadamente e renovado de forma controlada.

A Sophos utiliza o PSK configurado mais recentemente para todas as ligações com a mesma interface de escuta e o mesmo peer remoto. Em Remote Access, Remote host é normalmente definido como *. Uma política wildcard nova ou alterada pode, por isso, substituir o PSK de configurações Remote Access existentes. Antes de guardar, devem ser revistas todas as políticas que utilizam a mesma porta WAN e o mesmo gateway wildcard.

Com um PSK, definir valores correspondentes para Local ID e Remote ID. O tipo de ID DER ASN1DN (X.509) não é aceite com PSK. Os ID têm de corresponder ao cliente nativo e não devem ser definidos com valores arbitrários por conveniência.

Porta WAN, peer e seletores

Em Local WAN port, selecionar a porta WAN que está realmente acessível. Para clientes com endereços variáveis, definir Remote host com o valor wildcard *. Ativar Allow NAT traversal quando os clientes estão atrás de NAT, o que é normal em redes domésticas, móveis e de hotéis.

Para o fluxo Remote Access típico, o exemplo da Sophos utiliza Remote subnet: Any, Local port: 1701 e Remote port: *. 1701 é a porta L2TP na firewall; a porta do cliente pode variar. Estes valores são seletores do túnel e não substituem uma regra de firewall. O acesso posterior continua limitado a zonas, destinos e serviços específicos.

Com Disconnect when tunnel is idle, a firewall pode desligar clientes inativos após o período especificado em Idle session time interval. O valor deve ser adaptado ao padrão de trabalho real e testado com pausas realistas. Um período demasiado curto provoca novas ligações desnecessárias; sem limite, sessões esquecidas podem permanecer ativas durante mais tempo.

Após Save, ativar a política através do ícone vermelho na coluna Active. Verde em Active ainda não significa que um cliente esteja ligado. O estado Connection separado mostra se o túnel foi realmente estabelecido.

Acessibilidade, routing e regra de firewall

Permitir IPsec na WAN

Em Administration > Device access, IPsec tem de estar permitido para a acessibilidade WAN necessária. Esta autorização deve ser implementada de forma tão restrita quanto a topologia permitir. Um PSK forte ou um certificado não justifica acesso desnecessariamente amplo a WebAdmin, User Portal ou SSH. Device Access e Local Service ACL explica a separação entre acessibilidade do serviço e autorização do utilizador.

Definir Route Precedence de forma controlada

A Sophos exige que, para L2TP, as rotas VPN sejam avaliadas antes de Static e SD-WAN Policy Routes. Primeiro, guardar o estado inicial na Device Console:

system route_precedence show

Em seguida, definir a ordem L2TP documentada e verificá-la novamente:

system route_precedence set vpn static sdwan_policyroute
system route_precedence show

Esta alteração é global e não é um interruptor isolado para a nova política L2TP. Antes e depois, devem ser testados os percursos Static, SD-WAN e VPN que se sobrepõem, bem como o acesso de gestão. Ajustar Route Precedence na Sophos Firewall explica o efeito e o rollback seguro.

Permitir acesso aos destinos internos

Em Rules and policies > Firewall rules, criar uma regra IPv4 com logging. O exemplo da Sophos com Any para origem, destino e serviço é simples para uma primeira verificação funcional, mas não é um bom padrão de segurança permanente. Este exemplo é mais restrito:

• Source zone: VPN
• Source network: o pool L2TP 10.250.30.0/24 ou um objeto IP host correspondente
• Destination zone: a zona que contém a rede de aplicações
• Destination network: 10.10.10.0/24 ou, de preferência, os servidores necessários
• Services: HTTPS ou apenas os serviços realmente necessários
• Log firewall traffic: ativado

O tráfego de internet através da firewall exige uma regra separada de VPN para WAN e um design deliberado de NAT e segurança. Este acesso não é criado automaticamente apenas porque o túnel L2TP está estabelecido.

Validar a ligação

A validação é feita a partir de uma rede externa real. Um teste na mesma LAN ou através de um percurso VPN já existente pode ocultar problemas de routing, NAT e acessibilidade pública.

1. Estabelecer a ligação com um utilizador piloto autorizado e a configuração de cliente documentada.
2. Em Remote access VPN > L2TP, verificar separadamente os estados Active e Connection.
3. Confirmar que o cliente recebe um endereço entre 10.250.30.10 e 10.250.30.100, bem como os servidores DNS previstos.
4. Resolver um nome interno e aceder por HTTPS a um destino expressamente permitido.
5. No Log Viewer, verificar a Firewall Rule ID esperada, o IP de origem do pool L2TP, o destino, o serviço e a ação.
6. Verificar o percurso de retorno da rede de destino para o pool L2TP e repetir o mesmo acesso após uma nova ligação.
7. Executar um teste negativo com um utilizador que não foi adicionado; não deve obter um túnel utilizável.
8. Testar o comportamento idle, a desconexão, a nova ligação e, em HA, um failover controlado com um novo início de sessão.

Uma autenticação bem-sucedida não comprova o percurso de dados. Da mesma forma, um túnel verde não comprova que DNS, a regra, NAT e o percurso de retorno estão corretos. Testar regras da Sophos Firewall explica como separar as evidências do Log Viewer e Packet Capture.

Resolver problemas de forma sistemática

A política está ativa, mas o túnel permanece down

Primeiro, comparar a porta WAN, a acessibilidade pública, IPsec em Device Access, NAT Traversal, o endereço do cliente, o PSK ou certificado, Local/Remote ID e o perfil IPsec. Depois, verificar se uma política wildcard guardada mais recentemente substituiu o PSK esperado.

Para a primeira separação, utilizar l2tpd.log para L2TP e strongswan.log ou charon.log para a negociação IPsec. Serviços e ficheiros de log da Sophos Firewall fornece a correspondência completa. Correlacionar os logs com a hora exata, o utilizador, o IP público do cliente e o nome da política; reiniciar um serviço não é o primeiro passo de diagnóstico.

O início de sessão falha ou o utilizador não obtém acesso

Em Authentication > Services, verificar o método para VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Depois, confirmar se o utilizador ou grupo consta de Add members e qual o grupo apresentado como Main Group no objeto do utilizador. Com RADIUS, verificar adicionalmente e de forma separada a autenticação e a atribuição opcional de lease.

O túnel está up, mas os destinos internos estão inacessíveis

Verificar, por esta ordem, o endereço lease, Route Precedence, Firewall Rule ID, a rota de destino e o percurso de retorno. Uma rota SD-WAN ampla ou uma Static Route concorrente pode alterar o percurso. O pool L2TP tem de estar acessível a partir da rede interna sem que uma segunda rota idêntica ou uma rede sobreposta assuma o retorno.

Se o Log Viewer mostrar Rule 0, uma Rule ID inesperada ou nenhuma entrada correspondente, é necessário identificar a regra real antes de alargar qualquer coisa para Any. Se o pacote de saída estiver visível mas não regressar qualquer resposta, a verificação seguinte deve ser feita no host de destino, no seu gateway, na firewall local ou na rota de retorno.

A ligação é lenta ou instável

Verificar latência, packet loss, MTU ou fragmentação, alterações de WAN e utilização de CPU durante um teste reproduzível. Uma única transferência SMB não é um teste limpo do throughput VPN. Vários fluxos TCP controlados em ambas as direções ajudam a separar túnel, transporte e aplicação.

Se apenas as ligações L2TP estiverem instáveis, comparar os timestamps de l2tpd.log, dos logs IPsec, dos eventos WAN e do log do cliente. Alterar perfil, MTU ou idle time individualmente e numa janela de manutenção apenas depois de demonstrar uma relação concreta.

Efetuar um rollback seguro

Durante o rollback, manter aberto o acesso de gestão independente. Primeiro, restaurar exatamente a Route Precedence guardada e testar os percursos de gestão, Static, SD-WAN e VPN. Depois, desativar a política L2TP e confirmar com um cliente piloto que não resta qualquer dependência de produção.

Em seguida, podem ser removidas as regras de firewall e a autorização IPsec, se nenhum outro serviço depender delas. Só depois se removem os utilizadores de Add members e se desativa Enable L2TP. A Preshared Key não deve ser reposta às cegas num valor anterior; todas as políticas com a mesma porta WAN e o mesmo gateway wildcard devem ser verificadas em conjunto.

FAQ