Saltar para o conteudo
Avanet

Configurar Sophos Connect na Sophos Firewall

Sophos Connect é o cliente padrão para Remote Access com Sophos Firewall em muitos ambientes. No entanto, a qualidade real da solução não se decide apenas no Windows ou no macOS, mas na firewall: autorização de utilizadores, pool IP, DNS, autenticação, MFA, regras firewall e posterior distribuição de perfis têm de estar alinhados.

Este artigo descreve o planeamento e a configuração do lado da firewall para Sophos Connect, sobretudo para IPsec Remote Access e disponibilização de perfis. Para SSL VPN, a Remote Access policy propriamente dita está descrita em Configurar Sophos Firewall SSL VPN Remote Access. Para a decisão base entre IPsec, SSL VPN, clientes móveis e ZTNA, começar por Sophos Connect ou SSL VPN: que solução Remote Access se adequa?.

Que artigo se adequa?

Consoante a tarefa, faz sentido começar por outro ponto:

Esta separação é importante porque Sophos Connect toca várias áreas: configuração IPsec, configuração SSL VPN, VPN Portal, provisioning, autenticação, versão do cliente e regras firewall.

Requisitos

  • Sophos Firewall com versão SFOS suportada
  • acesso admin à interface WebAdmin
  • utilizadores ou grupos definidos para Remote Access
  • intervalo de endereços IP livre para clientes VPN
  • servidores DNS internos, caso seja necessário resolver nomes internos
  • conceito MFA para Remote Access
  • redes e serviços de destino clarificados, que devem estar acessíveis por VPN
  • processo claro para distribuição de perfis, alterações de perfis e atualizações de clientes

Se a firewall tiver de ser atualizada para SFOS 22.0 MR1 ou mais recente, deve verificar-se antes se ainda existe Legacy Remote Access IPsec. Esta configuração antiga pode bloquear o upgrade. O processo está descrito em Migrar Legacy Remote Access IPsec antes do SFOS 22 MR1.

Nas versões SFOS atuais, a configuração IPsec Remote Access está em Remote access VPN > IPsec. Em interfaces antigas ou guias antigos ainda se encontram caminhos como VPN > Sophos Connect Client. Por isso, screenshots existentes e ambientes de cliente mais antigos podem apresentar designações diferentes.

Planear antes da configuração

Antes de ativar, deve documentar-se brevemente como o Remote Access será operado depois. Isto evita erros típicos como pools IP sobrepostos, regras firewall demasiado amplas ou perfis que não são redistribuídos após uma alteração.

Perguntas importantes de planeamento:

  • Utilizadores: Utilizadores locais, grupo AD, RADIUS ou outra autenticação
  • MFA: OTP/MFA ativo, testado e documentado para processos de helpdesk
  • Pool IP: pool próprio sem sobreposição com LAN, WLAN, VLANs, Site-to-Site VPN ou redes domésticas
  • DNS: servidores DNS internos e domínios de pesquisa, se forem usados FQDNs internos
  • Acesso: permitir apenas servidores, redes e serviços necessários
  • Distribuição do cliente: .scx, .tgb, .ovpn, .pro, distribuição de software, estado da versão e caminho de fallback
  • Operação: Log Viewer, processo de suporte, alterações de perfil e saídas

Para bases de MFA, ver Configurar Sophos Firewall MFA. Se o Remote Access passar mais tarde por Microsoft Entra ID SSO, RADIUS ou AD, o percurso de autenticação também deve ser testado separadamente.

Tipos de perfil e disponibilização

Antes da configuração deve estar claro que ficheiro fica em que cliente. Isto evita muitos casos de suporte.

  • .scx: Sophos Connect para IPsec Remote Access também contém definições avançadas do Sophos Connect
  • .tgb: configuração IPsec para clientes antigos ou de terceiros não contém definições avançadas do Sophos Connect
  • .ovpn: SSL VPN para Sophos Connect ou clientes compatíveis com OpenVPN vem da configuração SSL VPN ou do VPN Portal
  • .pro: ficheiro de provisioning para importação automática carrega configurações através do VPN Portal após login bem-sucedido

Para novos rollouts Sophos Connect IPsec, .scx é normalmente o melhor padrão, porque contém as definições avançadas da firewall. .tgb só deve ser usado conscientemente quando um cliente de terceiros ou um processo antigo o exigir.

O provisioning pode simplificar a distribuição, mas aumenta a dependência do VPN Portal. Se os utilizadores tiverem de usar o ficheiro de provisioning a partir da Internet, o VPN Portal tem de estar acessível a partir da zona necessária. Isto pertence a Administration > Device access e deve ser endurecido conscientemente na Local Service ACL, porque um portal acessível por WAN cria superfície de ataque adicional. Para hardening, ver Device Access e Local Service ACL na Sophos Firewall.

Ativar Sophos Connect

Na interface WebAdmin, abrir Remote access VPN > IPsec. Em interfaces antigas, o caminho ainda pode ser VPN > Sophos Connect Client. A apresentação exata pode variar ligeiramente conforme a versão SFOS, mas as decisões fundamentais continuam semelhantes.

Configuração WebAdmin do Sophos Connect Client

1. Ativar Connect Client

Ativar IPsec Remote Access. Só depois definir as restantes opções e não fazer rollout imediato em produção.

2. Escolher a interface externa

Como interface, é normalmente escolhida a interface WAN através da qual as ligações Remote Access chegam à firewall. Com vários acessos WAN, deve decidir-se conscientemente qual é estável para VPN, documentado e acessível a partir da Internet.

A verificar:

  • IP público ou DynDNS/FQDN correto disponível
  • port forwards e routers a montante adequados
  • comportamento de WAN failover conhecido
  • Device Access e ACLs de serviço locais permitem apenas serviços necessários
  • VPN Portal só está acessível onde é realmente necessário para download ou provisioning

Remote Access é um ponto de entrada acessível publicamente. A função por si só não chega; acesso, MFA e logging também têm de ser considerados.

Para hardening dos serviços firewall acessíveis, ver Device Access e Local Service ACL na Sophos Firewall.

3. Escolher autenticação

Para IPsec Remote Access existem diferentes modelos de autenticação conforme a versão SFOS e a configuração. Preshared Key e certificado são opções frequentemente relevantes.

Enquadramento prático:

  • Preshared Key é rápida de configurar, mas deve ser forte, protegida e rodada em caso de suspeita.
  • Certificado é mais limpo para ambientes controlados, mas requer gestão de certificados e processos claros.
  • MFA não substitui PSK nem certificado, mas protege adicionalmente o login do utilizador.

Se a Preshared Key foi distribuída em vários perfis, uma alteração é operacionalmente mais trabalhosa. Por isso, a chave não deve ser tratada como valor descartável.

Nos certificados, deve verificar-se também se tipo de certificado, validade, chaves privadas e cliente de destino combinam. Para IPsec Remote Access, certificados RSA são especialmente relevantes. Alterações de certificado são sempre também tema de perfil e rollout.

4. Verificar Local ID e Remote ID

Local ID e Remote ID são opcionais, mas podem ser importantes com vários túneis ou peers especiais. Se forem definidos, têm de corresponder ao perfil usado e à configuração do cliente.

Valores típicos:

  • nome DNS
  • endereço IP
  • email
  • certificado

Em setups simples, estes campos ficam muitas vezes vazios. Se surgirem depois erros como no IKE config found ou problemas de proposal/ID, esta área deve ser incluída na verificação. Para análise mais profunda, Troubleshooting Sophos Firewall IPsec VPN é o melhor artigo de continuação.

5. Atribuir utilizadores e grupos

Selecionar apenas os utilizadores ou grupos que realmente precisam de Remote Access. Em ambientes produtivos, um grupo VPN dedicado é normalmente melhor do que um grupo padrão amplo.

A verificar:

  • O grupo contém apenas utilizadores autorizados.
  • Utilizadores que saíram são removidos.
  • MFA está ativo e testado para estes utilizadores.
  • Helpdesk sabe como bloquear, desbloquear ou reprovisionar utilizadores.

Guest users não pertencem ao Remote Access. Para ambientes produtivos, um grupo VPN dedicado é melhor do que um grupo padrão amplo do serviço de diretório.

Configurar dados do cliente

6. Atribuir nomes

O nome da ligação deve ser compreensível para utilizadores e suporte. Nomes como homeoffice, remote-access-ipsec ou o nome de uma localização são mais úteis do que abreviações internas.

Se forem distribuídos vários perfis, a nomenclatura deve permanecer consistente. Isto reduz confusões no Sophos Connect Client.

7. Definir pool IP

A firewall atribui aos clientes VPN um endereço do pool definido. Este intervalo não pode sobrepor-se a redes internas, outros pools VPN, redes Site-to-Site ou intervalos domésticos típicos.

Boa prática:

  • intervalo de endereços separado apenas para Remote Access
  • tamanho suficiente para utilizadores simultâneos
  • sem sobreposição com 192.168.0.0/24, 192.168.1.0/24 ou intervalos domésticos frequentes, quando evitável
  • documentação clara em IPAM ou documentação de rede

Se o pool for alterado mais tarde, perfis e testes têm de ser verificados novamente.

Para IPsec Remote Access, o pool deve pelo menos ser planeado corretamente como subnet própria. Além disso, não pode sobrepor-se a outros pools Remote Access como SSL VPN, L2TP ou PPTP.

8. Introduzir servidores DNS

Se os utilizadores tiverem de alcançar sistemas internos por nome, devem ser distribuídos servidores DNS adequados e, se necessário, domínios de pesquisa. Em muitos ambientes, isto é um Domain Controller interno ou um servidor DNS dedicado.

Resolvers externos como Cloudflare, Google, Quad9 ou OpenDNS não resolvem zonas internas. Só fazem sentido se não forem necessários nomes internos através do túnel VPN ou se DNS for resolvido conscientemente de outra forma.

Exemplos de resolvers externos:

  • Cloudflare: 1.1.1.1 e 1.0.0.1
  • Google: 8.8.8.8 e 8.8.4.4
  • Quad9: 9.9.9.9 e 149.112.112.112
  • OpenDNS: 208.67.222.222 e 208.67.220.220

Para Remote Access produtivo, normalmente é mais importante que FQDNs internos funcionem de forma fiável. Se DNS não estiver bem planeado, o túnel parece “ligado” para os utilizadores, embora as aplicações não sejam utilizáveis.

Verificar definições avançadas

9. Definir Session Timeout

Um Session Timeout impede que ligações VPN não utilizadas permaneçam abertas sem limite. Valores demasiado agressivos podem criar casos de suporte, porque os utilizadores têm de voltar a ligar após interrupções curtas.

É útil um valor que corresponda ao modelo de trabalho:

  • timeouts curtos para acessos administrativos esporádicos
  • timeouts mais longos para sessões de trabalho estáveis
  • comunicação clara se os utilizadores tiverem de voltar a ligar após inatividade

Se OTP/MFA for usado, também se deve testar o impacto em reconnects.

Se a firewall desligar um cliente idle, o Sophos Connect Client pode reconstruir a ligação em segundo plano. Se isso falhar, o utilizador tem de desligar conscientemente a ligação no cliente e voltar a ligar. Este comportamento deve ser conhecido no processo de helpdesk.

10. Definir conscientemente Advanced settings

As definições avançadas determinam como o cliente se comporta no dia a dia. Em IPsec Remote Access são incluídas no ficheiro .scx, não no ficheiro .tgb.

Pontos importantes:

  • Use as default gateway: Todo o tráfego de Internet deve passar pela firewall ou apenas recursos internos?
  • Permitted network resources: Que redes internas podem ser alcançadas através do túnel?
  • Send Security Heartbeat through tunnel: É usado Sophos Endpoint/Synchronized Security e Heartbeat deve passar por VPN?
  • Allow users to save username and password: O login guardado é compatível com o conceito MFA e de segurança?
  • Prompt users for 2FA token: OTP deve aparecer como campo separado ou combinado no campo da palavra-passe?
  • Run AD logon script after connecting: Logon scripts como mapeamentos de drives são realmente necessários e testados?
  • Connect tunnel automatically: O túnel deve ser estabelecido automaticamente no login do utilizador?

Com Full Tunnel através de Use as default gateway, é necessária uma regra firewall adicional de VPN para WAN e um desenho consciente de NAT/Security Policy. Com Split Tunnel, os recursos internos permitidos devem estar bem documentados.

Se Prompt users for 2FA token estiver ativo, a utilização é muitas vezes mais clara para os utilizadores. Ao mesmo tempo, deve verificar-se se ferramentas ou automações usadas funcionam com esta definição.

11. Guardar e exportar configuração

Depois de guardar, a configuração da ligação é exportada. Conforme o cliente e a versão SFOS, ficheiros .scx, .tgb ou de provisioning podem ser relevantes. O ficheiro não deve ser guardado abertamente nem entregue a pessoas não autorizadas.

Após alterações em grupo de utilizadores, pool, DNS, perfil, gateway, porta, certificado ou Advanced Settings, os clientes afetados têm de receber a configuração atualizada. Perfis antigos são uma causa comum de problemas VPN difíceis de compreender.

Se for usado provisioning, também se deve verificar se o cliente recarrega as alterações automaticamente ou se os utilizadores têm de atualizar a policy no Sophos Connect Client ou iniciar sessão novamente. Alterações a porta SSL VPN, gateway, certificado do servidor ou protocolo são casos típicos em que pode ser necessário novo login ou um passo de atualização consciente.

Configurar regras firewall

Sophos Connect apenas estabelece o túnel. O acesso a sistemas internos continua a ser controlado por regras firewall. Sem regras adequadas, a ligação pode estar verde, mas nenhum acesso produtivo funcionar.

Para acesso de clientes VPN a sistemas internos, normalmente é criada uma regra de VPN para LAN ou para uma zona de destino específica.

Sophos Connect Client - adicionar regra firewall para VPN/LAN
  • Source Zone: VPN
  • Destination Zone: LAN

Melhor do que uma autorização ampla para toda a LAN é normalmente uma regra para as redes ou serviços realmente necessários. Logging deve ser ativado na fase de introdução para que erros sejam visíveis no Log Viewer.

Se o cliente trabalhar como Full Tunnel e o tráfego de Internet também tiver de passar pela firewall, é necessária ainda uma regra de VPN para WAN e um desenho consciente de NAT/Security Policy.

Sophos Connect Client - adicionar regra firewall para VPN/WAN
  • Source Zone: VPN
  • Destination Zone: WAN

Para troubleshooting em regras, Testar regras firewall com Log Viewer, Policy Test e Packet Capture é útil.

As regras firewall não devem apenas “funcionar”, mas ser verificáveis. Para a fase de introdução, logging nas regras Remote Access é útil. Mais tarde pode decidir-se que regras serão registadas permanentemente e que eventos também devem seguir para Sophos Central ou Syslog.

Testar após o rollout

Um estado verde no Sophos Connect não chega como teste de aceitação. Pelo menos estes pontos devem ser verificados com um utilizador de teste:

  • O cliente importa a configuração sem erros.
  • O login funciona com palavra-passe e MFA.
  • O cliente recebe um endereço do pool VPN esperado.
  • Nomes DNS internos são resolvidos corretamente.
  • Sistemas internos centrais estão acessíveis.
  • Log Viewer mostra a regra firewall esperada.
  • Split Tunnel ou Full Tunnel comportam-se como planeado.
  • Reconnect após mudança de rede funciona.
  • Perfis antigos não foram reutilizados.
  • Com Full Tunnel, acesso à Internet através da firewall funciona como planeado.
  • Com Split Tunnel, destinos não permitidos continuam bloqueados.
  • Log Viewer mostra hits nas regras esperadas.
  • Com provisioning, alterações de perfil são atualizadas de forma rastreável.

Depois podem ser usados os guias de instalação para Windows e macOS.

Checklist operacional

Após o rollout técnico, a operação não deve ficar em aberto:

  • Grupo VPN responsável documentado.
  • Processo de saída remove utilizadores de grupos Remote Access.
  • Processo de reset MFA é conhecido.
  • Versão do perfil ou data de alteração é documentada.
  • Helpdesk sabe que perfis estão atuais.
  • Log Viewer e logs de serviço relevantes são conhecidos.
  • Alterações a pool IP, DNS, gateway, certificado e Advanced Settings acionam uma verificação de perfil.
  • Antes de upgrades SFOS, Legacy Remote Access IPsec e perfis de cliente são verificados.

Troubleshooting

A ligação é estabelecida, mas não passa traffic

A causa muitas vezes não está no túnel, mas em regras firewall, NAT, routing, DNS ou no caminho de retorno. Primeiro verificar no Log Viewer se traffic da zona VPN acerta na regra esperada. Depois limitar com Packet Capture ou Policy Test.

O utilizador não consegue iniciar sessão

Verificar grupo de utilizadores, servidor de autenticação, MFA, utilizador bloqueado e estado da palavra-passe. Se AD, RADIUS ou Microsoft Entra ID SSO estiver envolvido, a autenticação deve ser testada separadamente do VPN.

O cliente usa uma configuração antiga

Após alterações a pool IP, DNS, grupo de utilizadores, perfil, gateway, certificado ou Advanced Settings, a configuração tem de ser redistribuída ou reimportada. Ficheiros antigos .tgb, .scx, .ovpn ou de provisioning não devem continuar em circulação em paralelo.

Provisioning não funciona

Primeiro verificar se o VPN Portal está acessível a partir da zona necessária e se Device Access foi definido conscientemente. Depois verificar valor gateway, porta do portal, certificado, login do utilizador, MFA e, com Entra SSO, a atribuição em Authentication > Services.

SSO funciona apenas parcialmente

Com Microsoft Entra ID SSO, VPN Portal, IPsec e SSL VPN têm de corresponder ao servidor Entra ID correto conforme o workflow. Com provisioning, o valor gateway tem de corresponder ao Redirect URI da configuração Entra. Se apenas alguns utilizadores forem afetados, verificar também UPN, endereço de email, mapeamento de grupos e grupos de utilizadores importados.

A ligação está ativa, mas transferências grandes bloqueiam

Se login, DNS e acessos pequenos funcionam, mas transferências de ficheiros maiores ou certas aplicações bloqueiam, deve verificar-se MTU/MSS. O padrão de erro corresponde muitas vezes a fragmentação, PPPoE, ligações em túnel ou caminho assimétrico. O processo está em Verificar MTU e MSS na Sophos Firewall em problemas VPN.

IPsec falha em redes externas

IPsec pode ser bloqueado em hotéis, Wi-Fi de convidados, redes móveis ou redes empresariais fortemente filtradas. Nesses casos deve verificar-se se SSL VPN Remote Access, ZTNA ou outro desenho Remote Access se adequa melhor.

Full Tunnel não tem acesso à Internet

Se Use as default gateway estiver ativo, traffic de VPN para WAN tem de ser permitido e tratado com NAT adequado. Além disso, Web Protection, Application Control, DNS e logging devem ser planeados conscientemente como noutras redes cliente.

FAQ

Sophos Connect é automaticamente seguro quando o túnel funciona?

Não. O túnel é apenas uma parte da solução. MFA, grupos de utilizadores limpos, regras firewall limitadas, logging e manutenção regular de perfis continuam a ser decisivos.

Deve dar-se aos utilizadores VPN acesso a toda a LAN?

Apenas se for realmente necessário. Na maioria dos ambientes, regras mais restritas para servidores, redes ou serviços concretos são melhores.

A configuração do cliente tem de ser redistribuída após alterações?

Sim, se definições relevantes para o cliente mudarem. Isto inclui pool IP, DNS, perfil, gateway, certificados, Advanced Settings ou determinados parâmetros Remote Access.

Deve usar-se .scx ou .tgb?

Para Sophos Connect, .scx é normalmente melhor, porque este ficheiro também contém definições avançadas. .tgb é mais relevante para clientes de terceiros ou processos antigos.

Provisioning é mais seguro do que um ficheiro de configuração?

Provisioning facilita a distribuição, mas não é automaticamente mais seguro. VPN Portal tem de estar acessível e endurecido, MFA tem de atuar, e alterações de perfil continuam a ter de ser testadas.

Sophos Connect precisa de regras firewall próprias?

Sim. A criação do túnel por si só ainda não permite acesso produtivo. Traffic da zona VPN precisa de regras firewall adequadas para as zonas de destino e, com Full Tunnel, regras adicionais para WAN.

O que é especialmente importante antes do SFOS 22 MR1?

Antes do SFOS 22.0 MR1 ou mais recente, Legacy Remote Access IPsec tem de ser excluído ou migrado. Este legado pode bloquear o upgrade.