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.

Limites de versão e de clientes

Este guia destina-se ao SFOS 22.0 MR2 Build 546 e à interface descrita na ajuda online 22.0. O L2TP está disponível nesta versão. A verificação de upgrade para SFOS 22 da Avanet reúne os bloqueios atuais e os percursos suportados; antes de cada migração, comparar ali o build de origem concreto com o build de destino. Não existe uma matriz de compatibilidade completa para clientes L2TP nativos. O guia 22.0 cita apenas o Windows 10 como exemplo concreto de cliente. Isto não comprova a compatibilidade com outras versões, atuais ou posteriores, dos sistemas operativos.

Por isso, cada versão de OS efetivamente utilizada deve ser testada separadamente com o perfil IPsec, o servidor de autenticação e o tipo de ID previstos. O máximo de 254 endereços do pool é apenas um limite de endereçamento, não a garantia do mesmo número de sessões simultâneas. A ajuda pública 22.0 não indica um limite geral de sessões L2TP. A capacidade e a estabilidade devem ser validadas no modelo de firewall real com a simultaneidade esperada.

A ajuda atual descreve os valores selecionáveis, mas não identifica um valor predefinido universal para Gateway type, Authentication type, Allow NAT traversal ou Disconnect when tunnel is idle em configurações existentes ou migradas. Registar estes campos antes e depois de um upgrade, em vez de os reconstruir a partir de um valor presumido.

Configurar e verificar o cliente nativo do Windows

No Windows, criar a ligação em Definições > Rede e Internet > VPN > Adicionar VPN. Selecionar Windows (incorporado) como fornecedor de VPN, introduzir o FQDN público ou o endereço WAN da firewall em Nome ou endereço do servidor e escolher como tipo de VPN L2TP/IPsec com chave pré-partilhada ou a opção de certificado correspondente ao perfil da firewall. A chave pré-partilhada tem de corresponder ao PSK da política L2TP. Como informações de início de sessão, utilizar o nome e a palavra-passe de uma conta autorizada em Add members; documentar em conjunto o tipo de VPN, o método de início de sessão, os ID e a versão do cliente.

Executar o primeiro teste a partir de uma rede externa. Depois da ligação, utilizar ipconfig /all para verificar o endereço do pool L2TP e os servidores DNS previstos e, em seguida, testar a resolução de nomes interna e o acesso HTTPS permitido. Se o próprio estabelecimento do túnel falhar, comparar primeiro o nome do servidor, o modo PSK ou certificado, o método de início de sessão e o perfil IPsec acordado e, depois, correlacionar a hora com l2tpd.log e os logs IPsec. Cada versão do Windows utilizada continua a ser uma combinação de cliente que exige validação separada.

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.

Após alterar as definições globais e os membros, clique em Apply. Volte a verificar os valores globais guardados e Show members. A ação Save da política L2TP é um passo separado.

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. Idle session time interval é indicado em segundos.

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.

Com várias sub-redes locais e remotas, é criado um túnel por cada par local/remoto. Connection pode apresentar um estado parcial: a configuração está ativa, mas pelo menos um túnel não foi estabelecido. Teste cada par necessário e o respetivo fluxo de dados separadamente; Active ativado não confirma todos os túneis.

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 ordem predefinida documentada pela Sophos é Static, SD-WAN Policy Routes e depois VPN. Para L2TP, as rotas VPN têm de ser avaliadas primeiro; Static e SD-WAN podem seguir em qualquer ordem. Primeiro, guardar o estado inicial real 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. Com várias sub-redes locais e remotas, é criado um túnel por cada par local/remoto. Connection pode apresentar um estado parcial: a configuração está ativa, mas pelo menos um túnel não foi estabelecido. Teste cada par necessário e o respetivo fluxo de dados separadamente; Active ativado não confirma todos os túneis.
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.

Migrar para o SFOS 22

Planear a migração do firmware separadamente de uma alteração à configuração L2TP. Antes do upgrade, inventariar o firmware e a plataforma exatos, as definições L2TP globais, os utilizadores e Main Groups permitidos, cada política L2TP com perfil, ID e autenticação, Device Access, Route Precedence e as regras de firewall e NAT associadas. Preparar também um backup encriptado e um percurso de gestão independente. Usar a verificação de upgrade para SFOS 22 para comparar o build de origem concreto com a tabela de upgrade atual; a afirmação geral de que as configurações podem migrar para o 22.0 GA não substitui esta verificação do percurso.

Não confundir L2TP com Remote Access IPsec (legacy): L2TP continua disponível no SFOS 22.0 MR2, enquanto a variante IPsec antiga foi descontinuada no 22.0 MR1. Uma firewall que contenha essa configuração antiga não pode ser atualizada para o 22.0 MR1 ou posterior. Além disso, o SFOS 22.0 GA e versões posteriores não suportam appliances de hardware XG ou SG. A plataforma e os tipos de acesso remoto existentes são, portanto, verdadeiras condições de bloqueio, não apenas elementos do inventário.

O SFOS 22.0 MR1 Build 490 corrigiu NC-162171, que impedia a inserção de NAS-Identifier em ligações L2TP com MS-CHAPv2 ou MS-CHAP. Se as regras RADIUS dependerem de NAS-Identifier e a firewall vier de um build anterior, após o upgrade verificar não só o início de sessão, mas também o pedido RADIUS recebido e a política RADIUS que realmente corresponde. Esta correção não comprova a compatibilidade automática de todas as combinações de cliente e autenticação.

Após o reinício, comparar a versão do firmware e todos os campos inventariados. Executar depois a validação completa a partir de uma rede externa, incluindo o teste negativo, DNS, o percurso de dados, o comportamento idle e um novo início de sessão após um failover HA. Manter o método de acesso anterior como fallback controlado até estes testes serem aprovados.

Um rollback do firmware é mais do que desativar L2TP. O firmware ativo e o anterior residem em partições separadas com os respetivos estados de configuração. Arrancar o firmware anterior também ativa o seu estado de configuração anterior, pelo que as alterações efetuadas desde o upgrade não fazem parte da configuração em execução após o rollback. Antes desse passo, guardar separadamente as alterações posteriores necessárias, verificar a versão de destino suportada e confirmar a janela de manutenção para o reinício.

Efetuar um rollback seguro da configuração L2TP

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