Migrar Legacy Remote Access IPsec antes do SFOS 22 MR1

Com o SFOS 22.0 MR1, a Sophos descontinuou o Legacy Remote Access IPsec VPN. A simples existência de uma configuração legacy na firewall bloqueia o upgrade para o SFOS 22.0 MR1 e versões posteriores. Esta configuração tem de ser eliminada antes do upgrade, mesmo que já ninguém a utilize para estabelecer ligações.

Este artigo descreve como identificar a configuração antiga antes de um upgrade de firmware, documentá-la corretamente, substituí-la por uma solução atual de Remote Access e só depois removê-la. Para a verificação geral do upgrade, consulte também Verificar a Sophos Firewall antes do upgrade para SFOS 22.

O que é Legacy Remote Access IPsec

Ao longo dos anos, a Sophos suportou várias formas de Remote Access. Por isso, em muitos ambientes não é imediatamente claro se está em causa uma configuração IPsec atual, uma entrada legacy antiga, SSL VPN ou Sophos Connect.

Para o upgrade para o SFOS 22 MR1, os pontos mais importantes são:

Legacy Remote Access IPsec é o tipo de configuração antigo que pode bloquear o upgrade.
Remote Access IPsec atual é o caminho de destino quando se pretende continuar a utilizar IPsec.
SSL VPN pode ser uma alternativa quando o IPsec é regularmente bloqueado em hotéis, redes de convidados ou redes móveis.
ZTNA pode ser adequado quando já não é necessário um VPN completo no cliente, mas apenas acesso a aplicações específicas.

Esta diferença é importante para a operação. Um estado VPN verde ou um Sophos Connect Client funcional não prova automaticamente que já não existe uma configuração legacy na firewall.

Os ficheiros de cliente também ajudam a distinguir as configurações:

Numa ligação legacy, era extraído um ficheiro .tgb de um arquivo .tar descarregado e importado num cliente VPN de terceiros.
A configuração atual de Remote Access IPsec pode exportar um ficheiro .scx para o Sophos Connect. Além das definições gerais, este ficheiro também contém as definições avançadas.
Atualmente, um ficheiro .tgb por si só não prova que existe uma configuração legacy, porque a página IPsec atual continua a poder exportá-lo para clientes de terceiros. A entrada em Remote access VPN > IPsec (legacy) é o elemento determinante.

Um caso importante de restore é facilmente ignorado: backups ou configurações importadas podem conter Legacy Remote Access IPsec. A Sophos restaura ou importa esta configuração, mas não a migra para o modelo atual de Remote Access IPsec. Por isso, após um restore, uma substituição de hardware ou uma importação de configuração, é necessário voltar a verificar o bloqueio do upgrade.

Quando se deve migrar

A migração deve estar concluída antes do upgrade planeado para o SFOS 22 MR1. Esta alteração não deve ser deixada para a janela de manutenção do upgrade de firmware, porque o Remote Access envolve frequentemente utilizadores, certificados, MFA, DNS, regras de firewall e configurações de clientes.

Motivos típicos:

A Sophos Firewall deve ser atualizada para o SFOS 22.0 MR1 ou uma versão posterior.
A página de firmware ou a documentação da Sophos indica Legacy Remote Access IPsec.
Existem no ambiente perfis antigos do Sophos Connect que não são revistos há anos.
Os utilizadores comunicam problemas recorrentes de Remote Access após alterações de perfil ou de cliente.
O Remote Access deve ser reavaliado com MFA, Entra ID SSO, SSL VPN ou ZTNA.

Se o Remote Access for crítico para o negócio, a migração deve ser tratada como um projeto de change separado. O upgrade de firmware é apenas o motivo, não todo o âmbito do trabalho.

Documentar antes da migração

Primeiro, deve documentar-se o estado atual. Este passo é mais importante do que parece, porque muitas configurações VPN não consistem apenas num perfil de túnel. Frequentemente, existem grupos de utilizadores, pools de IP, definições DNS, regras de firewall, exceções NAT e ficheiros de cliente associados.

Verificar a configuração legacy no WebAdmin

Antes de planear o destino, é necessário determinar com precisão se Legacy Remote Access IPsec está realmente envolvido. Esta verificação não deve ser feita apenas antes do upgrade de firmware, mas também após um restore, uma substituição de hardware ou uma importação de configuração.

Procedimento prático:

Abrir Remote access VPN > IPsec (legacy) na versão de origem ainda suportada.
Verificar se existe uma ligação legacy. Para o bloqueio do upgrade, não é relevante se está atualmente a ser utilizada.
Abrir Remote access VPN > IPsec e documentar separadamente a configuração atual de Remote Access IPsec.
Verificar Authentication > Users e os grupos de utilizadores se tiverem sido utilizados endereços IP estáticos, utilizadores locais ou associações antigas a grupos.
Procurar em Rules and policies > Firewall rules regras da zona VPN para LAN, DMZ ou WAN.
Verificar em Administration > Device access se IPsec, VPN Portal, DNS ou Ping estão acessíveis a partir das zonas necessárias.
Abrir novamente a página de firmware e confirmar se continua a ser apresentado um bloqueio do upgrade.

Se a área legacy já não estiver visível, mas o upgrade continuar bloqueado, não se devem eliminar objetos com base em suspeitas. Nesse caso, uma captura de ecrã da mensagem, um backup atual e uma lista de objetos compreensível são mais importantes do que uma limpeza apressada durante a janela de manutenção.

Devem ser documentados, no mínimo, os seguintes pontos:

Utilizadores e grupos: Que utilizadores podem utilizar Remote Access? São utilizados utilizadores locais, AD, RADIUS ou Entra ID?
Autenticação: Palavra-passe, MFA, certificado, Preshared Key ou dependências de SSO.
Pool de IP: Que endereços recebem os clientes VPN? Existem conflitos com LAN, WLAN, VLAN ou outros VPNs?
DNS: Que servidores DNS e domínios são distribuídos aos clientes?
Acesso: Que redes internas, servidores e serviços têm de estar acessíveis?
Regras de firewall: Que regras permitem tráfego de VPN para LAN, DMZ ou WAN?
Distribuição de clientes: Onde se encontram os ficheiros .tgb antigos, os perfis atuais do Sophos Connect (.scx ou .pro) ou as configurações SSL VPN?
Operação: Quem pode informar os utilizadores, distribuir perfis e receber comunicações de erros?

Se já existirem problemas de routing ou de tráfego através do túnel, estes não devem ser transferidos para a nova configuração sem serem analisados. Para a análise, consulte Troubleshooting de IPsec VPN na Sophos Firewall.

Escolher o caminho de destino

Não existe um único substituto correto para Legacy Remote Access IPsec. A escolha depende do que os utilizadores realmente precisam e de como o ambiente é operado.

Remote Access IPsec atual

Remote Access IPsec atual é a escolha mais óbvia quando se pretende continuar a utilizar o Sophos Connect com IPsec e o ambiente funciona bem com esta solução. O IPsec oferece frequentemente um bom desempenho, mas pode apresentar problemas em redes externas restritivas devido ao bloqueio de portas UDP ou a situações NAT específicas.

Este caminho é adequado quando:

o Sophos Connect já está distribuído
os utilizadores trabalham com Windows 10/11 ou macOS 13 e versões posteriores
o IPsec tem sido estável na utilização atual
as redes internas devem estar acessíveis através de regras de firewall clássicas

O próprio Sophos Connect suporta Remote Access IPsec atual nestas versões de Windows e macOS. Para Linux e outras plataformas móveis, é necessário um cliente de terceiros adequado; o iOS pode instalar um perfil IPsec próprio a partir do VPN Portal. O guia existente Configurar o Sophos Connect Client na Sophos Firewall descreve a configuração completa.

SSL VPN

SSL VPN é adequado quando o Remote Access deve funcionar da forma mais robusta possível através de diferentes redes externas. Dependendo do ambiente, SSL VPN pode ser mais simples, mas levanta outras questões relacionadas com o desempenho e os clientes. Para Windows, consulte Instalar o Sophos Connect SSL VPN Client.

Este caminho é adequado quando:

os utilizadores trabalham frequentemente em hotéis, WLANs de convidados ou redes de outras empresas
as ligações IPsec falham repetidamente devido a restrições de rede
já existem processos SSL VPN estabelecidos
as plataformas móveis ou os clientes OpenVPN de terceiros são relevantes

ZTNA ou Clientless Access

Se os utilizadores precisarem apenas de aplicações Web internas específicas ou de aplicações definidas, deve verificar-se se um VPN clássico de túnel completo continua a ser a solução correta. ZTNA não substitui diretamente todos os cenários VPN, mas pode ser a melhor arquitetura em casos de utilização claramente delimitados.

Para apoiar a decisão, consulte primeiro O que é Zero Trust Network Access? Fundamentos, vantagens e limites. Se pretender utilizar Sophos ZTNA, o artigo Sophos ZTNA Gateway Connector descreve o componente concreto. Clientless Access só é uma alternativa para serviços adequados baseados no browser e não substitui o acesso geral à rede.

Criar a nova configuração de Remote Access

A nova configuração deve ser preparada em paralelo antes de a antiga ser removida. O objetivo não é transferir todos os utilizadores ao mesmo tempo para uma configuração que ainda não foi testada.

Para Remote Access IPsec atual, não basta criar apenas um novo nome de perfil. O processo de migração deve adotar ou redefinir deliberadamente as definições essenciais:

Definir a variante de destino: Remote Access IPsec atual, SSL VPN, ZTNA ou uma combinação.
Em Remote access VPN > IPsec, ativar Remote Access e selecionar a Interface externa.
Utilizar um IPsec profile adequado. Remote Access aceita perfis IKEv1 nos quais Dead Peer Detection está desativado ou definido como Disconnect.
Definir Authentication type, ID local e remoto, bem como Allowed users and groups.
Em Assign IP from, escolher um intervalo privado de, pelo menos, uma sub-rede /24. Este intervalo não pode sobrepor-se a SSL VPN, L2TP, PPTP, LAN, WLAN ou redes Site-to-Site.
Definir DNS server 1 e, opcionalmente, DNS server 2, bem como os recursos internos necessários.
Decidir deliberadamente entre Split Tunnel e Use as default gateway e configurar Prompt users for 2FA token de acordo com o método MFA.
Em Authentication > Groups, verificar se Remote Access IPsec está permitido para o grupo de utilizadores efetivamente aplicável. Esta opção não fica automaticamente ativa em grupos AD importados e grupos migrados.
Em Administration > Device access, permitir IPsec a partir da zona WAN. O VPN Portal só é necessário se os clientes ou o aprovisionamento acederem através dele; DNS e Ping só devem ser permitidos se forem necessários para o desenho concreto.
Criar regras de firewall separadas e com nomes claros para o tráfego VPN de entrada e de saída e ativar o logging.
Utilizar Export connection para gerar um ficheiro .scx para o Sophos Connect ou atualizar um aprovisionamento .pro existente.
Distribuir o perfil de teste por um pequeno número de utilizadores piloto, testar em pelo menos dois acessos de rede diferentes e só depois planear o rollout.

MFA não deve ser tratado como um detalhe opcional no Remote Access. Se o VPN estiver acessível mundialmente, MFA, grupos de utilizadores bem definidos, logging e uma revisão das definições de Device Access devem ser tratados em conjunto. O artigo Configurar MFA na Sophos Firewall aborda os fundamentos.

Planear coexistência e caminho de retorno

A nova solução de Remote Access deve ser testada primeiro em paralelo com a configuração antiga. Desta forma, é possível migrar os utilizadores por fases e, em caso de erro, regressar de forma controlada, sem alterar simultaneamente Remote Access, regras de firewall, DNS, MFA e distribuição de clientes na mesma janela de manutenção.

No entanto, é importante planear corretamente a coexistência. A nova configuração não deve utilizar o mesmo pool de IP, as mesmas regras de firewall com nomes pouco claros ou os mesmos nomes de perfil da configuração legacy antiga. Caso contrário, mais tarde deixará de ser possível identificar no Log Viewer que acesso estabeleceu realmente a ligação de um utilizador.

Antes do piloto, devem estar definidos os seguintes pontos:

Grupo piloto: um pequeno número de utilizadores tecnicamente acessíveis, com diferentes dispositivos e redes.
Pool de IP: um intervalo próprio sem sobreposição com LAN, WLAN, Site-to-Site VPN ou o Remote Access antigo.
Regras de firewall: regras próprias e claramente identificadas para o novo pool VPN.
Perfis de cliente: um novo nome de ligação para que os utilizadores possam distinguir a ligação legacy da ligação de destino.
Critério de retorno: definir antecipadamente quando se deve regressar à ligação antiga.
Janela de suporte: o helpdesk ou o administrador tem de estar disponível durante o piloto.

Um caminho de retorno não significa continuar a operar permanentemente a configuração legacy. Serve apenas para cancelar o piloto de forma controlada caso a autenticação, MFA, DNS, routing ou as aplicações centrais não funcionem. Assim que a nova solução estiver estável, a configuração antiga deve ser removida e o bloqueio do upgrade deve ser verificado novamente.

Testes antes de remover a configuração legacy

A configuração antiga só deve ser removida depois de a solução de substituição ter sido testada. Caso contrário, o problema do upgrade fica resolvido, mas o Remote Access pode deixar de funcionar em produção.

Teste funcional

Verificar, no mínimo:

a autenticação com um utilizador de teste funciona
MFA ou SSO é solicitado como esperado
o cliente recebe um IP VPN adequado
os nomes DNS internos são resolvidos
os servidores centrais estão acessíveis
o comportamento da Internet corresponde ao desenho: Split Tunnel ou Full Tunnel
o logout e uma nova autenticação funcionam

Teste de firewall e routing

No Log Viewer, verificar se o tráfego da zona VPN corresponde às regras esperadas. Se o tráfego for rejeitado, não se deve verificar apenas a configuração VPN, mas também a regra de firewall, NAT, Route Precedence e o caminho de retorno. Para ligações específicas, é útil o artigo Testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture.

Teste de cliente

No Sophos Connect, os perfis existentes não devem ser substituídos sem aviso. É preferível realizar um pequeno piloto com feedback claro:

O cliente importa a nova configuração?
A ligação antiga é substituída de forma compreensível para os utilizadores?
O estabelecimento da ligação funciona após um reinício?
Os sufixos DNS, as rotas e as ligações guardadas estão corretos?
Existem diferenças entre Windows e macOS?

Na distribuição de ficheiros .scx, uma alteração posterior tem de ser novamente exportada e importada. Um aprovisionamento .pro já configurado pode obter automaticamente alterações posteriores, desde que o endereço do gateway e a porta do VPN Portal estejam acessíveis e permaneçam inalterados.

Antes de um rollout alargado, também deve ser verificada a versão do cliente em utilização. Para isso, consulte Verificar a versão do Sophos Connect Client e atualizá-la em segurança.

Remover a configuração legacy

Quando a nova solução tiver sido testada em produção, a configuração legacy pode ser removida. Antes disso, deve ser criado novamente um backup atual. Isto é especialmente importante se, no mesmo change, também forem ajustadas regras de firewall, grupos de utilizadores ou servidores de autenticação.

Procedimento prático:

Criar um backup recente.
Informar os utilizadores ativos sobre a janela de manutenção.
Manter ativa a nova configuração de Remote Access.
Remover Legacy Remote Access IPsec no WebAdmin.
Verificar as dependências dos perfis antigos, pools de IP e regras que já não são necessários.
Abrir novamente a página de firmware e confirmar se o bloqueio do upgrade desapareceu.
Documentar o resultado.

Não se deve eliminar imediatamente tudo o que parece antigo. Regras de firewall, hosts ou grupos antigos também podem ser utilizados para Site-to-Site VPN, SSL VPN ou outros fins. Primeiro devem verificar-se as dependências e só depois proceder à limpeza.

Após um restore ou uma importação de configuração, a verificação deve ser repetida. Um backup pode conter objetos legacy antigos sem que daí resulte automaticamente uma configuração atual de Remote Access IPsec. Para a operação e a documentação, é por isso essencial confirmar se a configuração de destino produtiva foi realmente criada de novo, testada e distribuída.

Troubleshooting

O upgrade continua bloqueado

Se o upgrade continuar bloqueado apesar de a configuração legacy visível ter sido removida, deve abrir-se novamente a área de firmware e voltar a verificar Remote access VPN > IPsec (legacy). Não se devem eliminar hosts, grupos ou perfis IPsec atuais com base em suspeitas. Se continuar a não ser claro que configuração legacy está a ser detetada, deve ser preparado um Sophos Support Case com uma captura de ecrã da mensagem de upgrade, a versão de origem e um backup atual.

A questão legacy reaparece após um restore

Após um restore, uma substituição de hardware ou a importação de uma configuração antiga, o Remote Access deve ser verificado novamente. O que importa não é se o change anterior foi concluído uma vez, mas sim o que existe na configuração atualmente em execução. Backups antigos podem voltar a introduzir objetos históricos de Remote Access ou desencadear uma nova verificação do caminho de upgrade.

Os utilizadores não conseguem autenticar-se

Em caso de problemas de autenticação, verificar primeiro a autenticação, MFA, o grupo de utilizadores e a VPN-Policy. Se estiverem envolvidos RADIUS, AD ou Entra ID, a ligação ao servidor deve ser testada separadamente do VPN. Um problema de VPN nem sempre é um problema de IPsec.

A ligação está estabelecida, mas os sistemas internos não estão acessíveis

Neste caso, a causa encontra-se frequentemente nas regras de firewall, em NAT, DNS ou routing. Verificar se o cliente recebe um IP VPN adequado, se os nomes internos são resolvidos corretamente e se o tráfego corresponde à regra esperada no Log Viewer.

Algumas redes funcionam, outras não

Neste caso, estão frequentemente envolvidos redes Split-Tunnel, rotas IPsec, rotas estáticas ou rotas de retorno em falta. Em cenários IPsec, Rota IPsec na Sophos Firewall é um artigo complementar adequado.

Checklist

Antes do rollout

Legacy Remote Access IPsec identificado
utilizadores, grupos, pool de IP, DNS e regras de firewall documentados
caminho de destino escolhido: IPsec atual, SSL VPN, ZTNA ou uma combinação
MFA e autenticação verificados
Device Access verificado de acordo com as necessidades: IPsec na WAN, VPN Portal para distribuição ou aprovisionamento, DNS e Ping apenas quando necessários
coexistência e critério de retorno definidos
utilizador de teste definido
backup criado

Durante o rollout

nova configuração testada com utilizadores piloto
perfis de cliente distribuídos
Log Viewer e regras de firewall afetadas verificados
caminho de retorno comunicado
feedback dos utilizadores recolhido

Após a migração

configuração legacy removida
bloqueio do upgrade verificado novamente
cenário de restore e importação documentado
perfis e regras antigos verificados quanto a dependências
documentação atualizada
upgrade de firmware planeado apenas depois disso

FAQ

É necessário remover Legacy Remote Access IPsec antes do SFOS 22 MR1?

Sim. Se esta configuração legacy ainda existir, a firewall não pode ser atualizada para o SFOS 22.0 MR1 ou uma versão posterior.

Remote Access IPsec atual também é afetado?

Não. O bloqueio do upgrade refere-se a Legacy Remote Access IPsec. Ainda assim, a configuração atual de Remote Access deve ser testada e documentada antes de um Major Upgrade.

SSL VPN é a melhor alternativa?

Não em todos os casos. SSL VPN é frequentemente mais tolerante em redes externas restritivas. Em contrapartida, IPsec pode oferecer um melhor desempenho. Os fatores determinantes são os dispositivos dos utilizadores, os ambientes de rede, a autenticação, MFA e os processos operacionais.

É possível simplesmente eliminar a configuração antiga?

Tecnicamente, pode ser removida. Na prática, deve testar-se primeiro uma solução de substituição e criar um backup. Caso contrário, o Remote Access pode deixar de funcionar para os utilizadores.

O que acontece após um restore com uma configuração legacy antiga?

Após um restore ou uma importação de configuração, deve verificar-se novamente Legacy Remote Access IPsec. A Sophos pode restaurar ou importar a configuração antiga, mas não a migra para a configuração atual de Remote Access IPsec. Por isso, esta configuração pode continuar a bloquear o upgrade.