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: As páginas de ajuda comparadas para o SFOS 22 e 23 apresentam o L2TP como um tipo de acesso remoto configurável. Isto comprova as funcionalidades documentadas, não a disponibilidade em todos os builds nem uma garantia para futuras versões principais. 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 continuidade de um ambiente antigo ou de compatibilidade.

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 uma nova implementação 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. Para aplicações individuais, o Clientless SSL VPN pode disponibilizar acesso através do navegador sem um túnel de rede completo. O PPTP não é uma alternativa moderna: o próprio protocolo não define encriptação nem autenticação; os métodos de início de sessão selecionáveis não o tornam uma arquitetura de destino segura para novas implementações.

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.

As páginas completas de ajuda do L2TP para o SFOS 22 e 23 descrevem as mesmas definições globais, campos de política e passos de configuração. Esta comparação da documentação não constitui um teste de appliance ou de cliente, nem transforma o exemplo do SFOS 22 numa configuração validada para o SFOS 23. A matriz de plataformas para Sophos Connect, IPsec e SSL VPN na FAQ de acesso remoto também não é uma matriz de compatibilidade L2TP; para uma mudança, seguir a comparação de clientes acima indicada e o respetivo procedimento de IPsec ou SSL VPN.

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. DNS é um campo opcional: selecionar o servidor na lista ou introduzir o seu endereço através de Other. Configurar Secondary DNS server, Primary WINS server e Secondary WINS server apenas quando forem realmente necessários no ambiente; o WINS não substitui o DNS.

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, selecionar o grupo L2TP_Users através de Add members, adicioná-lo com Add e verificá-lo com Show members. Para um utilizador de diretório, uma importação bem-sucedida do grupo, por si só, não é suficiente. Um utilizador piloto tem de pertencer realmente ao grupo autorizado, e esse grupo tem de ser utilizado como grupo principal 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.

Limites da automatização através da API XML

Os passos na interface não constituem um pedido à API XML pronto a enviar. As páginas da API comparadas para o SFOS 22 e 23 separam, sob L2TPConfiguration, os valores globais em L2TPSettings dos membros em L2TPMembers com UserName. Ao contrário da interface, a tabela assinala PrimaryDNSServer como um campo obrigatório com um endereço IPv4. O campo DNS opcional na interface não prova, por isso, que este parâmetro da API possa ser omitido. L2TPGeneralSettings e LeaseIPFromRadiusServer são aí apresentados como opcionais, com Disable como valor predefinido documentado; isto não estabelece um comportamento testado em caso de omissão. Antes de automatizar, é necessário esclarecer o contrato da API do build instalado, sem adivinhar uma codificação de DNS vazio. Depois, voltar a consultar os valores globais pretendidos e as pertenças; o procedimento na interface e o mecanismo de fallback do RADIUS descritos acima continuam separados.

Para a política guardada descrita abaixo, o exemplo da API apresenta L2TPConnection com Configuration; ao lado encontram-se os ramos de controlo Connection, DisConnection, Active e DeActive, cada um com Name. Guardar, ligar, desligar e ativar não correspondem, portanto, à mesma identidade nem à mesma ação. Os ícones da interface não comprovam um pedido executável à API. Além disso, o exemplo e a tabela de campos contradizem-se: RemoteHost contém um nome de host ou um endereço IP no exemplo, enquanto a tabela permite IPv4 ou *; AliasLocalWANPort representa apenas um alias WAN no exemplo, mas é obrigatório na tabela. Para DisconnectOnIdleInterval, a tabela indica o valor predefinido 0, mas também um intervalo de 120 a 999; 600 é apenas o valor do exemplo. Não deduzir daí um significado para zero nem valores de substituição seguros. Antes de efetuar alterações através da API, esclarecer estes pontos para o build específico e verificar o acesso de gestão independente e os efeitos nos PSK partilhados das políticas wildcard, conforme descrito acima.

Também na posterior desativação do serviço é necessário distinguir a eliminação de uma ligação guardada da sua desativação e da desativação global de L2TP. Primeiro, inventariar a configuração existente, desativar a ligação pretendida e verificar as dependências. Delete L2TP Connection exige o Name guardado exato (primeira letra A-Za-z, seguida de A-Za-z0-9_, no máximo 50 caracteres); a página não fornece nenhum exemplo de pedido. As correspondências de estado 200/L2TPDeleteSuccess, 203/L2TPConnInUse e 500/L2TPDeleteFail remetem para identificadores Message não resolvidos, não para textos de mensagem confirmados nem para uma classificação HTTP. Em particular, não considerar 203 como um sucesso genérico de eliminação da classe 2xx. Depois de esclarecer o pedido de eliminação, voltar a verificar o nome exato do alvo e confirmar que os acessos de produção ainda necessários são preservados; não adivinhar um envelope para o pedido de eliminação nem uma limpeza posterior automática.

Endereço estático do utilizador e dependências PPTP existentes

Os campos de atribuição de endereços por utilizador encontram-se em Authentication > Users > [utilizador], na área das definições de acesso remoto. L2TP permite o acesso L2TP e aceita um endereço IP a atribuir ao utilizador remoto. PPTP tem um controlo de ativação próprio e um campo separado para o endereço IP a atribuir. São duas definições de conta distintas, não o pool global nem uma atribuição de IP para SSL VPN. Gerir o utilizador local e a respetiva palavra-passe de acordo com Criar utilizadores locais na Sophos Firewall. Apenas para um acesso existente devidamente justificado, planear um endereço único e sem conflitos, guardá-lo com Save e verificar, na próxima ligação a partir de uma rede externa, o endereço efetivamente atribuído e o percurso de retorno. Com a atribuição de endereços por RADIUS, o endereço do utilizador continua a ser o fallback acima descrito quando o RADIUS não fornece um endereço; um controlo de ativação na conta não substitui a autorização através de Add members nem a regra de firewall.

Primeiro início de sessão antes do túnel: A ajuda de criação de utilizadores para o SFOS 22 e 23 exige que, após a ativação de L2TP ou PPTP, os membros da política iniciem primeiro sessão no VPN portal e criem uma palavra-passe antes de estabelecerem a ligação. Verificar este acesso inicial documentado com uma conta piloto no build e servidor de autenticação utilizados. Não repor palavras-passe existentes por mera suspeita nem substituir indiscriminadamente uma autenticação de diretório funcional por palavras-passe locais. A acessibilidade do portal e VPN portal authentication methods devem ser verificadas separadamente do método do túnel; não é necessário abrir o WebAdmin à WAN para este efeito.

Para inventariar um acesso PPTP já existente, em Remote access VPN > PPTP encontram-se Enable PPTP, Assign IP from, a opção partilhada de atribuição de endereços por RADIUS, o servidor DNS primário e os servidores DNS secundário e WINS opcionais. O endereço é atribuído durante a ligação; o intervalo privado situa-se numa sub-rede /24 ou menor e contém, no máximo, 254 endereços. Não pode sobrepor-se aos intervalos de Remote Access IPsec e SSL VPN. A ajuda descreve Apply para os valores globais e Add members e Show members para a autorização dos utilizadores; também aqui, a importação de grupos de AD ou Entra ID não autoriza automaticamente o acesso. Para migração e diagnóstico, estes campos são apenas consultados na configuração existente, não constituindo uma recomendação para ativar PPTP. Os métodos documentados PAP, CHAP e MS-CHAPv2 não oferecem um padrão de segurança moderno; a substituição deve ser planeada com IPsec, SSL VPN ou acesso específico às aplicações.

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. Digital certificate autentica os endpoints através da troca de certificados assinados localmente ou emitidos por uma autoridade de certificação. 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 regularmente 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.

Remote host também pode conter um endereço IP ou um nome de host para um peer fixo. Remote subnet descreve as redes remotas; verificar o valor face à arquitetura concreta do cliente. A ajuda dos campos permite portas TCP/UDP ou o valor wildcard * em Local port e Remote port; o exemplo com a porta local 1701 não é uma definição universal para todas as arquiteturas de seletores. A ajuda da política designa esta secção, de forma diferente, como QuickHA mode, enquanto o guia de configuração se refere a seletores Quick Mode. Este título não deve ser interpretado como uma funcionalidade HA: o que importa são os dois campos de portas e os seletores IPsec compatíveis.

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; a ajuda descreve a ação de ligação através do respetivo ícone de estado. Para um cliente remoto, a tentativa de ligação a partir de uma rede externa continua a ser determinante. Logs na página L2TP abre os logs de L2TP. Com Active desativado, a política está inativa, independentemente de um estado anterior do túnel.

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. Iniciar sessão na CLI da firewall e selecionar 4. Device Console. Primeiro, guardar aí o estado inicial real:

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 > IPv4 > Add firewall rule > New firewall rule, criar uma regra com logging e guardá-la com Save. Atribuir um Rule name claro, por exemplo VPN-LAN. 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. Neste exemplo, a configuração é mais restrita:

• 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.

Não transpor as regras L2TP ao mudar para Sophos Connect

A FAQ de acesso remoto aborda IPsec e SSL VPN, não uma autorização adicional para clientes L2TP. A sua tabela de plataformas indica, para Windows, .pro ou .scx para IPsec e .pro ou .ovpn para SSL VPN; indica os mesmos tipos de ficheiro para macOS com Sophos Connect a partir da versão 2.1. O macOS com Connect 2.0 utiliza .scx e .ovpn, respetivamente; antes da versão 2.0, o IPsec continua a utilizar Sophos Connect com .scx, enquanto o SSL VPN utiliza um cliente de terceiros com .ovpn. O Android utiliza clientes de terceiros com .tgb para IPsec ou .ovpn para SSL VPN; no iOS, o IPsec não necessita de um cliente adicional e a configuração é descarregada do VPN portal, enquanto o SSL VPN necessita de um cliente de terceiros com .ovpn. Verificar a combinação concreta e atual de cliente e sistema operativo antes da substituição. Verificar a encriptação para IPsec em Remote access VPN > IPsec > IPsec profiles > Encryption algorithm e para SSL VPN em Remote access VPN > SSL VPN > SSL VPN global settings > Cryptographic settings. A afirmação geral da FAQ sobre a ligação de acesso remoto encriptada não deve ser aplicada ao PPTP sem proteção própria do protocolo.

No provisionamento do Sophos Connect, os gateways em .pro servem apenas para obter a configuração do portal, não para selecionar o túnel: o IPsec utiliza a interface configurada, e o SSL VPN utiliza as interfaces de .ovpn existentes em Network > Interfaces e autorizadas pela Local Service ACL. Override hostname define o endereço público pretendido para SSL VPN; quando a firewall está atrás de um router, o FQDN público ou IP WAN desse router deve constar de .pro, deve ser configurado no router um encaminhamento DNAT adequado e, para IPsec, o IP WAN do router deve ser definido como gateway em .scx. O certificado privado predefinido do WebAdmin e VPN Portal pode causar um erro de confiança durante o provisionamento; corrigir a cadeia de certificados, em vez de desativar a verificação. A configuração da firewall para Sophos Connect e o procedimento de SSL VPN substituem aqui a configuração L2TP.

Para alterações de IPsec, a FAQ exige Edit connection > Update policy e uma nova obtenção da configuração do portal; no SSL VPN, as atualizações manuais dizem respeito sobretudo à porta, ao protocolo, ao gateway e ao certificado do servidor SSL. .pro obtém automaticamente algumas alterações de SSL VPN; uma nova importação pode voltar a obter ambas as configurações. Para distinguir uma atualização de perfil de um erro de download, seguir Descarregar novamente o perfil SSL VPN. O Sophos Connect utiliza os gateways SSL VPN de .ovpn por ordem de prioridade inversa, não necessariamente pela ordem de .pro. O SSL VPN distribui o pool por instâncias dependentes da CPU com sub-redes tun0 próprias: intervalos menores do que /24 reduzem a capacidade de atribuição de endereços; com /27 e oito instâncias, a FAQ indica apenas um endereço restante disponível para atribuição. Isto não é um limite do pool L2TP. A ausência de downloads de .ovpn também pode estar relacionada com IDs de utilizador acima do limite comum de IDs de utilizadores e grupos de 65535; Verificar com segurança o limite de IDs de utilizador descreve a limpeza controlada, em vez da eliminação indiscriminada.

Planear a MFA para o acesso de substituição em Authentication > Multi-factor authentication, com as opções necessárias User portal, SSL VPN remote access e IPsec remote access. O campo OTP separado exige, para IPsec, Prompt users for 2FA token e Apply, ou, no provisionamento, otp: true e 2fa: 1. O Sophos Connect envia a palavra-passe e o OTP combinados como passwordotp e, segundo a FAQ, não suporta um fluxo de autenticação OTP por desafio; suporta métodos por chamada e push, e o WebAdmin suporta adicionalmente MFA por desafio. Verificar esta diferença no piloto de provisionamento, sem a transpor para um cliente L2TP nativo. A FAQ também limita o Remote Access IPsec a uma interface WAN; isto não implica o mesmo limite para L2TP nem uma garantia de Multi-WAN para o acesso de substituição.

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

O rollback consiste em repor apenas os estados alterados durante este procedimento no estado inicial documentado, não em desmantelar um ambiente L2TP existente. Por isso, antes da primeira alteração, são registados os valores globais de L2TP, incluindo Enable L2TP, o estado Active de cada política afetada, a lista completa em Add members, as permissões dos utilizadores, as regras de firewall e a autorização IPsec em Administration > Device access; os novos elementos e as alterações aos elementos existentes são registados separadamente. Se faltarem valores iniciais ou um método confirmado para a reposição exata no build instalado, a alteração em causa não é efetuada; esclarecer primeiro a situação com o Sophos Support. Um valor predefinido documentado não substitui um valor inicial efetivamente consultado.

Durante o rollback, o acesso de gestão independente mantém-se aberto. Primeiro, se a Route Precedence tiver sido alterada durante este procedimento, é reposta exatamente na ordem anteriormente guardada, consultada novamente com system route_precedence show e são verificados os percursos de gestão, Static, SD-WAN e VPN. Se a ordem não tiver sido alterada, mantém-se.

Numa configuração existente, são repostos exatamente apenas os valores, estados das políticas, pertenças e permissões que foram alterados. As políticas, os membros, as regras e as autorizações já existentes são preservados no seu estado original; se Enable L2TP já estava ativado, mantém-se ativado. Reverter uma única alteração na Device Console não justifica remover estes acessos nem desativar globalmente o L2TP.

O desmantelamento de uma implementação criada inteiramente durante este procedimento é tratado separadamente: antes de qualquer desativação ou remoção, são verificadas as dependências e confirmado que nenhum acesso de produção ainda necessário é afetado. Só então se desativa a política L2TP recém-criada e se verificam os efeitos com um cliente piloto. Em seguida, revertem-se exclusivamente as regras de firewall e as autorizações IPsec recém-criadas que já não são necessárias, e removem-se de Add members apenas os membros adicionados durante este procedimento. Desativar Enable L2TP apenas se estava desativado antes deste procedimento e se não existe nenhuma dependência ainda necessária. Os elementos partilhados existentes não são eliminados como parte da limpeza.

Após a reversão, comparar os valores globais guardados, Show members, o estado das políticas, as permissões dos utilizadores, as regras e Device Access com o estado inicial documentado. Confirmar com um cliente piloto externo que os acessos de produção anteriormente necessários continuam a funcionar e que as autorizações de teste revertidas já não permitem acesso. A Preshared Key não é reposta às cegas num valor anterior; todas as políticas com a mesma porta WAN e o mesmo gateway wildcard são verificadas em conjunto.

FAQ