Migrar Legacy Remote Access IPsec antes do SFOS 22 MR1
Com o SFOS 22.0 MR1, a Sophos removeu definitivamente o Legacy Remote Access IPsec VPN do caminho de upgrade suportado. Firewalls onde esta antiga configuração de Remote Access IPsec ainda esteja presente não podem ser atualizadas para SFOS 22.0 MR1 ou versões posteriores.
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 validação geral antes do upgrade, também é útil Verificar a Sophos Firewall antes do upgrade para SFOS 22.
O que significa Legacy Remote Access IPsec
Ao longo dos anos, a Sophos suportou vários métodos de Remote Access. Por isso, em muitos ambientes nem sempre é imediatamente claro se se trata de uma configuração IPsec atual, de uma entrada legacy antiga, de SSL VPN ou de Sophos Connect.
Para o upgrade para SFOS 22 MR1, o essencial é:
- Legacy Remote Access IPsec é o tipo de configuração antigo que pode bloquear o upgrade.
- Remote Access IPsec atual é o caminho de destino se o IPsec continuar a ser utilizado.
- SSL VPN pode ser uma alternativa se o IPsec for frequentemente bloqueado em hotéis, redes de convidados ou ambientes móveis.
- ZTNA pode fazer sentido quando já não é necessário um VPN completo por cliente, mas sim acesso a aplicações individuais.
A diferença é importante em operação. Um estado VPN verde ou um Sophos Connect Client funcional não prova automaticamente que já não exista uma configuração legacy na firewall.
Um caso de restore importante é facilmente esquecido: backups ou configurações importadas podem conter Legacy Remote Access IPsec, mas esta configuração legacy não é migrada automaticamente. Após um restore, substituição de hardware ou importação de configuração, deve-se voltar a verificar este ponto, mesmo que a firewall parecesse já estar limpa anteriormente.
Quando se deve migrar
A migração deve estar concluída antes do upgrade planeado para SFOS 22 MR1. Esta alteração não deve ser deixada para a janela de manutenção do 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 SFOS 22.0 MR1 ou versão posterior.
- A página de firmware ou a documentação da Sophos indica Legacy Remote Access IPsec.
- Existem no ambiente perfis antigos de Sophos Connect que não são revistos há anos.
- Os utilizadores reportam problemas recorrentes de Remote Access após alterações de perfil ou cliente.
- O Remote Access deve ser reavaliado de qualquer forma 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 documenta-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, deve-se confirmar de forma limpa se Legacy Remote Access IPsec está realmente envolvido. Esta verificação não pertence apenas ao período antes do upgrade de firmware, mas também após restore, substituição de hardware ou importação de configuração.
Procedimento prático:
- Abrir Remote access VPN > IPsec (legacy), se o ponto de menu estiver visível na versão SFOS instalada.
- Verificar se Legacy Remote Access IPsec está ativo ou se ainda existem objetos de configuração.
- Abrir Remote access VPN > IPsec e documentar separadamente a configuração atual de Remote Access IPsec.
- Verificar Authentication > Users e grupos de utilizadores se foram usados endereços IP estáticos, utilizadores locais ou atribuições antigas de grupos.
- Procurar em Rules and policies > Firewall rules regras da zona
VPNparaLAN,DMZouWAN. - 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 de upgrade.
Se a área legacy já não estiver visível, mas o upgrade continuar bloqueado, não se devem apagar objetos por suspeita. 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 pelo menos:
| Área | O que deve ser verificado |
|---|---|
| Utilizadores e grupos | Que utilizadores podem usar Remote Access? São usados utilizadores locais, AD, RADIUS ou Entra ID? |
| Autenticação | Palavra-passe, MFA, certificado, Preshared Key ou dependências 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 devem estar acessíveis? |
| Regras de firewall | Que regras permitem tráfego de VPN para LAN, DMZ ou WAN? |
| Distribuição de clientes | Onde estão os perfis atuais de Sophos Connect ou as configurações SSL VPN? |
| Operação | Quem pode informar utilizadores, distribuir perfis e receber erros? |
Se já existirem problemas com routing ou tráfego através do túnel, estes não devem ser transferidos para a nova configuração sem análise. Para a análise, ajuda 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 opção mais direta se o Sophos Connect com IPsec continuar a ser usado e o ambiente funcionar bem com essa abordagem. IPsec é muitas vezes performante, mas pode destacar-se em redes externas restritivas devido a portas UDP bloqueadas ou casos especiais de NAT.
Este caminho é adequado quando:
- Sophos Connect já está distribuído
- os utilizadores trabalham principalmente com Windows ou macOS
- IPsec tem sido estável na utilização atual
- as redes internas devem estar acessíveis através de regras clássicas de firewall
O guia existente Configurar o Sophos Connect Client na Sophos Firewall pode servir de base, mas deve ser comparado com as versões SFOS atuais e com o próprio desenho de autenticação.
SSL VPN
SSL VPN faz sentido 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 traz outras questões de performance e cliente. Para Windows existe o guia Instalar Sophos Connect SSL VPN Client.
Este caminho é adequado quando:
- os utilizadores trabalham frequentemente em hotéis, WLANs de convidados ou redes empresariais externas
- ligações IPsec falham repetidamente devido a restrições de rede
- processos SSL VPN existentes já estão estabelecidos
- plataformas móveis ou clientes OpenVPN de terceiros têm relevância
ZTNA ou Clientless Access
Se os utilizadores precisarem apenas de aplicações web internas específicas ou de aplicações definidas, deve-se verificar se um VPN clássico de túnel completo ainda é a solução correta. ZTNA não substitui diretamente todos os cenários VPN, mas pode ser a melhor arquitetura em casos de uso bem delimitados.
O artigo existente Sophos ZTNA Gateway Connector é um bom ponto de partida. Para acessos web simples, Clientless Access também pode ser relevante, se os requisitos forem adequados.
Criar a nova configuração de Remote Access
A nova configuração deve ser preparada em paralelo antes de remover a antiga. O objetivo não é mover todos os utilizadores ao mesmo tempo para uma configuração não testada.
Procedimento recomendado:
- Definir a variante de destino: Remote Access IPsec atual, SSL VPN, ZTNA ou combinação.
- Escolher um novo pool de IP e verificar sobreposições.
- Definir a fonte de autenticação e MFA.
- Atribuir os utilizadores ou grupos necessários.
- Definir servidores DNS e domínios internos.
- Criar regras de firewall para as novas origens VPN.
- Criar um perfil de teste para poucos utilizadores.
- Testar a ligação em pelo menos dois acessos de rede diferentes.
- Só depois planear a comunicação aos utilizadores e o rollout.
MFA não deve ser tratado como um detalhe opcional em Remote Access. Se o VPN estiver acessível globalmente, MFA, grupos de utilizadores limpos, logging e uma revisão das definições de Device Access pertencem ao mesmo conjunto. O artigo Configurar MFA na Sophos Firewall cobre os fundamentos.
Planear coexistência e caminho de retorno
A nova solução de Remote Access deve ser primeiro testada ao lado da configuração antiga. Isto permite migrar utilizadores por fases e, em caso de erro, voltar atrás de forma direcionada, sem alterar Remote Access, regras de firewall, DNS, MFA e distribuição de clientes na mesma janela de manutenção.
Mas a coexistência deve ser planeada corretamente. A nova configuração não deve usar 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 no Log Viewer deixa de ser possível perceber que acesso ligou realmente um utilizador.
Antes do piloto, estes pontos devem estar definidos:
| Ponto | Recomendação |
|---|---|
| Grupo piloto | poucos utilizadores tecnicamente acessíveis com diferentes dispositivos e redes |
| Pool de IP | intervalo próprio sem sobreposição com LAN, WLAN, Site-to-Site VPN ou Remote Access antigo |
| Regras de firewall | regras próprias, claramente nomeadas, para o novo pool VPN |
| Perfis de cliente | novo nome de perfil, para que os utilizadores consigam distinguir a ligação antiga da nova |
| Critério de retorno | definir previamente quando se volta para a ligação antiga |
| Janela de suporte | Helpdesk ou administrador deve estar disponível durante o piloto |
Um caminho de retorno não significa continuar a operar a configuração legacy de forma permanente. Serve apenas para cancelar o piloto de forma controlada se login, MFA, DNS, routing ou aplicações centrais não funcionarem. Assim que a nova solução estiver estável, a configuração antiga deve ser removida e o bloqueio de upgrade deve ser verificado novamente.
Testes antes de remover a configuração legacy
A configuração antiga só deve ser removida quando o substituto tiver sido testado. Caso contrário, o problema de upgrade fica resolvido, mas o Remote Access pode falhar em produção.
Teste funcional
Verificar pelo menos:
- login com utilizador de teste funciona
- MFA ou SSO é solicitado como esperado
- o cliente recebe um IP VPN adequado
- nomes DNS internos são resolvidos
- servidores centrais estão acessíveis
- o comportamento de Internet corresponde ao desenho: Split Tunnel ou Full Tunnel
- logout e novo login funcionam
Teste de firewall e routing
No Log Viewer, verificar se o tráfego da zona VPN acerta nas regras esperadas. Se o tráfego for descartado, não se deve verificar apenas a configuração VPN, mas também regra de firewall, NAT, Route Precedence e caminho de retorno. Para ligações individuais, o artigo Testar regra de firewall com Log Viewer, Policy Test e Packet Capture é útil.
Teste de cliente
No Sophos Connect, os perfis existentes não devem ser substituídos silenciosamente. É melhor 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 reinício?
- Sufixos DNS, rotas e ligações guardadas estão corretos?
- Existem diferenças entre Windows e macOS?
Antes de um rollout alargado, a versão do cliente em uso também deve ser verificada. Para isso, serve 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 mais uma vez um backup atual. Isto é especialmente importante se no mesmo change forem ajustadas regras de firewall, grupos de utilizadores ou servidores de autenticação.
Procedimento prático:
- Criar um backup recente.
- Informar utilizadores ativos sobre a janela de manutenção.
- Manter a nova configuração de Remote Access ativa.
- Remover Legacy Remote Access IPsec no WebAdmin.
- Verificar perfis, pools de IP e regras antigas que já não são necessários.
- Abrir novamente a página de firmware e confirmar se o bloqueio de upgrade desapareceu.
- Documentar o resultado.
Não apagar imediatamente tudo o que parece antigo. Regras de firewall, hosts ou grupos antigos também podem ser usados para Site-to-Site VPN, SSL VPN ou outros fins. Primeiro verificar dependências, depois limpar.
Após um restore ou 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 operação e documentação, é portanto decisivo saber se a configuração produtiva de destino foi realmente criada, testada e distribuída de novo.
Troubleshooting
O upgrade continua bloqueado
Se o upgrade continuar bloqueado apesar de a configuração legacy visível ter sido removida, primeiro deve-se recarregar a firewall ou abrir novamente a área de firmware. Depois, verificar se todos os objetos legacy de Remote Access foram realmente removidos. Se continuar pouco claro que objeto está a bloquear, deve ser preparado um Sophos Support Case com captura de ecrã da mensagem de upgrade e backup atual.
Após restore, a questão legacy volta a aparecer
Após restore, substituição de hardware ou importação de uma configuração antiga, o Remote Access deve ser verificado novamente. O decisivo não é se o change anterior foi concluído uma vez, mas o que existe na configuração atualmente em execução. Backups antigos podem trazer de volta objetos históricos de Remote Access ou desencadear uma nova verificação do caminho de upgrade.
Os utilizadores não conseguem autenticar-se
Em problemas de login, verificar primeiro autenticação, MFA, grupo de utilizadores e VPN-Policy. Se RADIUS, AD ou Entra ID estiverem envolvidos, 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
Nesse caso, a causa está muitas vezes em regras de firewall, NAT, DNS ou routing. Verificar se o cliente recebe um IP VPN adequado, se nomes internos são resolvidos corretamente e se o tráfego no Log Viewer acerta na regra esperada.
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 combinação
- MFA e autenticação verificados
- Device Access para IPsec, VPN Portal, DNS e Ping verificado
- 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 de 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