Configurar VPN IPsec Site-to-Site Sophos Firewall

Uma VPN IPsec Site-to-Site liga duas localizações ou uma Sophos Firewall a uma firewall de terceiros através de um túnel cifrado. Na prática, um túnel deste tipo raramente falha por causa de uma única opção na interface. As causas mais frequentes são redes pouco claras, perfis IPsec diferentes, regras de firewall em falta, casos especiais de NAT ou um caminho de retorno esquecido num dos lados.

Procedimento resumido: escolher o tipo de túnel, alinhar perfil e IDs, criar a ligação, encaminhar a interface XFRM em route-based Any-to-Any, definir regras de firewall e NAT e testar o túnel com tráfego real, logs e Packet Capture.

O procedimento aplica-se a ligações Sophos-to-Sophos e a terceiros entre sede, filial ou cloud gateway. Para Microsoft Azure e AWS aplicam-se detalhes adicionais do fornecedor: ligar a Sophos Firewall ao Azure VPN Gateway e ligar a Sophos Firewall ao AWS Site-to-Site VPN. Para o Remote Access de utilizadores individuais, consulte antes a escolha entre Sophos Connect e SSL VPN. Se um túnel existente já está verde, mas não passa tráfego, use Sophos Firewall IPsec VPN Troubleshooting.

Quando são ligadas exclusivamente duas Sophos Firewalls e a filial deve estabelecer o túnel como cliente para uma sede acessível através de um endereço estático, a SSL Site-to-Site VPN é uma alternativa mais simples. Para equipamentos de outros fabricantes, redundância, routing dinâmico ou redes em crescimento, o IPsec route-based continua a ser a opção mais flexível.

Para várias firewalls geridas pelo Sophos Fusion (anteriormente Sophos Central), um SD-WAN Connection Group pode gerar automaticamente túneis baseados em rotas, interfaces XFRM, rotas e regras opcionais. Isto não substitui o planeamento da topologia nem a validação local do tráfego.

Escolher policy-based ou route-based

Antes da configuração, é necessário decidir se o túnel será criado como policy-based ou route-based. Fora da interface Sophos, route-based também é frequentemente designado tunnel-based. Ambos os termos descrevem um túnel com a sua própria interface XFRM. O termo “root-based”, usado ocasionalmente, não é um modo de VPN.

A Sophos recomenda VPN route-based para novos designs. Any-to-Any é especialmente flexível para redes em crescimento, porque alterações às rotas não interrompem o túnel. Alterações às sub-redes ou aos Traffic Selectors interrompem, por outro lado, as ligações existentes. As duas extremidades do túnel têm de usar o mesmo tipo: policy-based num lado e route-based no outro não é suportado.

Para OSPF ou BGP através do túnel, route-based Any-to-Any com interfaces XFRM endereçadas é o design compreensível. Antes de atualizar uma solução policy-based mais antiga, deve verificar-se se as redes VPN são anunciadas através de redistribute kernel; SFOS 22: rotas IPsec e redistribute kernel explica a alteração da versão e o enquadramento seguro da migração.

O que um túnel verde confirma realmente

Um estado como Established confirma que as contrapartes negociaram IKE e pelo menos uma Child SA. Não confirma que foi selecionada uma rota, que a regra de firewall corresponde, que o NAT está correto, que a contraparte conhece o caminho de retorno ou que o host de destino responde. Assim, um túnel pode estar verde sem transportar tráfego útil entre localizações.

A Sophos Firewall utiliza ESP em modo túnel. ESP protege a integridade dos dados, autentica a origem dos dados transportados e oferece proteção anti-replay contra a repetição de pacotes.

O caminho dos dados pode ser entendido através do seguinte modelo:

Policy-based
Origem -> Regra de firewall -> Selector Local/Remote -> Child SA -> Peer -> Rota de retorno e regra -> Destino

Route-based Any-to-Any
Origem -> Rota ou SD-WAN Route -> Regra de firewall -> XFRM -> Child SA -> Peer -> Rota de retorno e regra -> Destino

Este é um modelo de diagnóstico, não uma representação completa da ordem de processamento interna do SFOS. A distinção é, ainda assim, essencial para a validação: em policy-based, o par de redes na ligação IPsec determina o tráfego que pertence ao túnel. Em route-based Any-to-Any, essa seleção é feita pelo routing ou pelo SD-WAN.

Requisitos e dados de planeamento

Antes da configuração, devem ser documentados pelo menos estes dados:

• Endpoint local: interface WAN da Sophos Firewall e o endereço através do qual a contraparte alcança esta interface.
• Remote Gateway: IP público ou hostname DNS da contraparte.
• Gateway type: normalmente Respond only na sede e Initiate the connection na filial.
• IP version: IPv4, IPv6 ou Dual. Dual só está disponível para interfaces de túnel route-based com Any-to-Any como sub-redes local e remota. Com Dual, as regras de firewall IPv4 e IPv6 têm de ser planeadas separadamente.
• Redes locais: por exemplo 172.16.10.0/24 e 172.16.20.0/24.
• Redes remotas: por exemplo 10.20.30.0/24.
• Tipo de VPN: policy-based ou route-based. O Connection type Host-to-host também existe, mas não é o foco deste guia para ligações entre localizações.
• Listening interface: interface WAN da firewall local. Não pode ser usada uma bridge interface.
• Versão IKE: preferencialmente IKEv2, se a contraparte a suportar.
• Authentication type: Preshared key, Digital certificate ou RSA key.
• Local ID e Remote ID: especialmente importantes com FQDN, contrapartes dinâmicas, NAT-T ou Wildcard Gateway.
• Perfil IPsec: Encryption, Authentication, DH Group, PFS e Key life.
• Regras de firewall: origens, destinos e serviços permitidos.
• NAT: sem NAT ou SNAT/DNAT devido a redes sobrepostas ou requisitos do fornecedor.
• Operação: owner, janela de manutenção, plano de testes, monitoring e caminho de fallback.

Exemplo consistente para ambos os firewalls

Os seguintes valores de documentação facilitam o acompanhamento dos passos seguintes. Substitua-os integralmente pelos seus próprios endereços WAN, redes e nomes:

Criar primeiro ambas as redes LAN como objetos de rede em Hosts and services > IP host. Na sede, 10.10.10.0/24 é a Local subnet e 10.20.20.0/24 a Remote subnet; na filial, inverter estes valores. O mesmo se aplica aos IDs: a Local ID de um lado tem de corresponder à Remote ID esperada pela contraparte. A rede de transferência 10.255.0.0/30 é utilizada apenas para route-based Any-to-Any e não pode sobrepor-se a nenhuma rede de produção, VPN ou gestão.

Para os IDs do exemplo, definir Local ID type = DNS e Remote ID type = DNS em ambas as firewalls. Na sede, introduzir Local ID vpn-hq.example.invalid e Remote ID vpn-branch.example.invalid; na filial, introduzir exatamente o inverso. Estes valores identificam as contrapartes; não são utilizados para a resolução DNS dos respetivos endereços de gateway. Se for utilizado outro tipo de ID, o tipo e o formato também têm de corresponder de forma cruzada.

Para cada objeto de rede IPv4, selecionar Add, IP version = IPv4, Type = Network, introduzir o endereço de rede e a máscara de sub-rede /24 e guardar. Nomes adequados são HQ_LAN para 10.10.10.0/24 e Branch_LAN para 10.20.20.0/24; ambos os objetos são necessários nas duas firewalls. Um objeto de host destina-se, por sua vez, a um único endereço de teste ou de monitoring.

Utilizar a filial como iniciador distribui as tentativas de restabelecimento pelas filiais e é adequado quando o endereço IP WAN da filial muda. Se um iniciador tiver de alcançar uma contraparte com um IP WAN dinâmico, a respetiva Gateway address tem de conter um hostname DNS que efetivamente resolva para o endereço público atual da contraparte. Configurar e verificar Dynamic DNS na Sophos Firewall descreve o registo e o teste de resolução. Um simples ID DNS não é um endereço de gateway acessível. Configurar DDNS apenas na sede não permite descobrir o endereço dinâmico da filial.

⚠️ Uma VPN Site-to-Site não deve ser implementada sem um caminho de retorno documentado. Se a firewall local envia tráfego para o túnel, mas a contraparte não conhece a rota de retorno ou espera outro NAT, o túnel muitas vezes parece saudável embora as aplicações não funcionem.

Redes, perfil, IDs e certificados

As redes locais e remotas não podem sobrepor-se involuntariamente. Redes predefinidas frequentes como 192.168.0.0/24, 192.168.1.0/24 ou redes de filiais reutilizadas são particularmente problemáticas. Se as redes se sobrepõem, é necessário um design NAT consciente. Usar o mesmo intervalo de endereços dos dois lados e traduzi-lo mais tarde “de alguma forma” cria túneis difíceis de manter.

Para novas localizações, vale por isso a pena definir um plano de endereçamento IP claro. Se VLANs ou zonas ainda não estiverem corretamente modeladas, consulte configurar zonas e interfaces na Sophos Firewall.

Ambos os lados têm de usar parâmetros compatíveis na Phase 1 e Phase 2. Isto inclui cifragem, autenticação, DH Group, PFS e duração. Em ligações a firewalls de terceiros, é muitas vezes mais simples acordar primeiro um perfil comum por escrito e configurar só depois os dois lados.

Com IKEv2, a Sophos pode usar Preshared Keys únicas por combinação de Local ID e Remote ID. Com IKEv1, este comportamento é mais limitado, porque só se aplica uma PSK por combinação de gateway. Em ambientes com vários túneis para a mesma contraparte, deve preferir-se IKEv2 com IDs claros.

⚠️ Com IKEv1, a firewall utiliza a PSK da ligação configurada mais recentemente para a mesma combinação de gateway local e remoto. Isto aplica-se às configurações IPsec site-to-site e de acesso remoto. Configurar posteriormente uma ligação para essa combinação de gateways com uma PSK diferente pode causar uma falha de autenticação das ligações existentes numa negociação posterior. Antes de adicionar uma ligação deste tipo ou alterar uma PSK, verificar todas as configurações IKEv1 afetadas e alinhar a PSK com as respetivas contrapartes antes da próxima negociação.

NAT Traversal está sempre ativo na Sophos Firewall. Se um dos lados estiver atrás de um router ou NAT do fornecedor, os IDs tornam-se mais importantes porque o endereço público do gateway não identifica o peer de forma inequívoca. A Local ID de um lado tem de corresponder à Remote ID esperada pela contraparte. IDs DNS, IP ou e-mail não precisam de ser publicamente resolvíveis, mas o formato e o valor têm de corresponder de forma cruzada.

A Sophos Firewall não oferece um seletor NAT-T separado: Os dispositivos detetam NAT automaticamente. Sem NAT, as negociações IKE usam UDP 500 e o tráfego de dados utiliza ESP através de IP protocol 50. Quando a firewall deteta um dispositivo NAT, encapsula em UDP 4500 as negociações IKE e de fase 2 seguintes, bem como os pacotes ESP.

Se existir um dispositivo NAT no caminho IPsec e a contraparte for uma firewall de outro fabricante, NAT-T também deve estar ativado nessa firewall. A definição é verificada com base na documentação dessa contraparte; a Sophos Firewall não precisa de um seletor adicional.

As contrapartes detetam um dispositivo NAT durante a troca IKE de fase 1 e acordam então a utilização de NAT-T. ESP é um protocolo de camada 3 sem informações de portas de camada 4, enquanto PAT também pode traduzir portas. A encapsulação UDP através da porta 4500 fornece, por isso, um invólucro UDP identificável no caminho NAT; a contraparte remove esse invólucro e processa o pacote IPsec original.

Se a Sophos Firewall estiver atrás de um router, este precisa de uma regra DNAT ou de encaminhamento de portas do endereço público para a Listening interface privada da firewall. No exemplo utilizado ao longo do artigo, o endereço WAN do router da sede pode ser 198.51.100.10, enquanto a WAN da firewall utiliza 172.31.255.2. Nesse caso, a sede seleciona a sua WAN privada como Listening interface; a filial continua a ligar a 198.51.100.10, e não a 172.31.255.2. O router traduz o destino do seu endereço público para 172.31.255.2. Os Selectors das LAN mantêm-se: na sede, Local 10.10.10.0/24 e Remote 10.20.20.0/24; na filial, exatamente o inverso.

Para NAT-T, é necessário permitir UDP 500 e UDP 4500. Os guias do SFOS 22 e do SFOS 23 para uma firewall atrás de um router indicam adicionalmente IP protocol 50, não a porta TCP/UDP 50. Quando NAT-T é negociado, ESP é transportado dentro de UDP 4500; ESP nativo utiliza o protocolo 50. A lista de permissões do router e a explicação de NAT-T não devem, por isso, ser tratadas como caminhos de pacotes idênticos. Antes da alteração, documentar as funcionalidades do router e os encaminhamentos existentes e verificar, através dos logs IKE e de Packet Capture, qual o caminho efetivamente utilizado. Não remover uma permissão ESP existente sem a verificar; limitar permissões adicionais aos endereços das contrapartes planeadas. Se a negociação não ocorrer, restaurar a configuração documentada do router. Este assunto é distinto de SNAT/DNAT para LANs sobrepostas ou tráfego de dados traduzido.

Com Digital certificate, os formatos e as funções dos certificados têm de corresponder exatamente nos dois lados. A Sophos não suporta certificados ECDSA para ligações IPsec; são necessários certificados RSA. Local certificate pertence à firewall local, Remote certificate à contraparte e Remote CA certificate é a base de confiança para o certificado dessa contraparte. Não utilizar uma CA pública como Remote CA certificate: caso contrário, um atacante com um certificado válido dessa CA poderia obter acesso não autorizado. Com o tipo de ID DER.ASN1 DN (X.509), utiliza-se o Distinguished Name do respetivo certificado; como Remote ID, deve ser introduzido o DN do certificado da contraparte.

RSA key é um Authentication type separado, não a seleção de um certificado RSA. A firewall gera automaticamente o par de chaves e mostra apenas a chave pública em Local RSA key. Copiar essa chave para Remote RSA key da contraparte e inserir a chave pública da contraparte no campo Remote RSA key local. Ambos os lados têm de utilizar o mesmo formato PKCS1 ou DNS. As chaves privadas não são transferidas entre as firewalls.

Alterar a CA local Default de um Sophos Firewall é uma alteração do trust anchor, não uma edição estética do certificado. Os peers com um Default.pem importado e os certificados assinados localmente têm de ser migrados de forma controlada. Renovar de forma controlada a Default CA do Sophos Firewall explica o inventário, a janela de manutenção, os testes e a recuperação.

Quando Digital certificate é selecionado, a escolha no formulário da ligação não é suficiente. A confiança na CA, os certificados locais, os certificados da contraparte e os Certificate IDs têm de ser preparados antecipadamente. O procedimento completo está descrito em Configurar IPsec Site-to-Site com certificados. Se a CA revogar certificados antes de estes expirarem, a lista de revogação atual também deve ser incluída no plano de operações. Um procedimento separado descreve a importação da CRL, a verificação de nextUpdate e um teste negativo controlado na Sophos Firewall.

Se um túnel não sobe, NO_PROPOSAL_CHOSEN, erros de ID ou erros de autenticação são indicações típicas. A secção Testar o túnel e resolver problemas começa com o diagnóstico adequado.

Configurar IPsec policy-based

IPsec policy-based é a variante clássica para ligações Site-to-Site simples. As redes locais e remotas são definidas diretamente na ligação IPsec.

1. Verificar ou criar o perfil IPsec

Caminho do menu:

Profiles > IPsec profiles

Primeiro verificar se um perfil existente corresponde à contraparte. Se for necessário um perfil próprio, deve receber um nome claro, por exemplo Branch-Zurich-IKEv2. O nome tem de continuar compreensível quando existirem vários túneis e contrapartes.

Documentar pelo menos:

• Versão IKE
• Phase 1 Encryption e Authentication
• DH Group
• Phase 2 Encryption e Authentication
• PFS
• Key life

Em firewalls de terceiros, a contraparte deve confirmar os mesmos valores por escrito. Uma captura de ecrã, por si só, muitas vezes não basta, porque os campos podem ter nomes diferentes conforme o fabricante.

A interação entre Phase 1, Phase 2, PFS, lifetimes, rekeying e DPD é explicada em Compreender e configurar perfis IPsec na Sophos Firewall. Antes da ativação, verificar Dead peer detection: a Sophos especifica Hold ou Disconnect para a contraparte que responde e Re-initiate para o iniciador. Um grupo de failover IPsec altera este comportamento e não segue a mesma lógica DPD.

2. Adicionar a ligação IPsec

Caminho do menu:

Site-to-site VPN > IPsec

Criar uma nova ligação IPsec e escolher Policy-based como Connection type. Depois definir os dados base:

• Nome do túnel, por exemplo branch-zurich
• IP version, normalmente IPv4
• Gateway type, por exemplo Respond only na sede ou Initiate the connection na filial
• Listening interface como interface WAN local
• Gateway address da contraparte como endereço IP ou hostname DNS
• Authentication type: Preshared key, Digital certificate ou RSA key
• Local ID e Remote ID, se necessário
• IPsec profile
• Local subnet
• Remote subnet

Neste exemplo policy-based, são selecionadas redes específicas nos dois lados. A documentação do SFOS 22 e do SFOS 23 não utiliza uma formulação uniforme relativamente a Any: a visão geral de Policy-based afirma que Any não pode ser selecionado para as sub-redes locais e remotas; o guia Add an IPsec connection permite Any em, no máximo, um dos lados. Não deduzir daqui uma configuração policy-based Any-to-Any. Se for necessário utilizar Any num só lado, verificar, antes da implementação, a opção no build instalado, os Selectors da contraparte e o routing pretendido numa configuração de teste isolada. Se ocorrer uma SA inesperada ou uma associação inesperada do tráfego, desativar a nova ligação e restaurar os Selectors específicos documentados. Com várias redes locais e remotas específicas, é criada uma Phase 2 SA por combinação: duas redes locais e duas redes remotas originam quatro SAs. Todas as ligações policy-based partilham uma interface IPsec; uma captura apenas nessa interface não identifica, por isso, o túnel.

Com Respond only, um endereço wildcard * pode ser útil quando várias filiais ou contrapartes dinâmicas ligam à sede. Nesse caso, deve estar definida pelo menos uma Local ID ou Remote ID; para uma atribuição inequívoca, normalmente são úteis ambas. A Local ID de um lado corresponde à Remote ID esperada pelo outro. Initiate the connection não suporta um endereço wildcard, pelo que a contraparte é definida como endereço IP ou hostname DNS.

Para Preshared Keys, deve ser usada uma chave forte e única, documentada de forma segura. Uma chave predefinida antiga partilhada entre várias localizações representa um risco operacional desnecessário.

Com Authentication type = Preshared key, introduzir a PSK acordada e repeti-la no campo de confirmação. Na contraparte, introduzir exatamente a mesma PSK e confirmá-la também; os IDs espelhados não alteram a chave partilhada. Trocar a PSK apenas através do canal seguro previsto, sem a incluir em capturas de ecrã ou tickets públicos.

Em seguida, criar a ligação na contraparte com definições espelhadas. Neste exemplo, a sede aguarda 203.0.113.20 com Respond only; as redes Local/Remote são, respetivamente, 10.10.10.0/24 e 10.20.20.0/24. A filial usa Initiate the connection, Gateway address 198.51.100.10 e inverte as redes e IDs Local/Remote. O perfil, a autenticação e a PSK têm de ser compatíveis. Ativar a ligação apenas depois de ambas as entradas terem sido guardadas e as regras verificadas.

As definições avançadas de User authentication mode pertencem apenas a perfis IKEv1 com lógica XAuth, por exemplo designs client-server muito antigos. Em ligações Site-to-Site normais com IKEv2, isto não deve ser interpretado como um passo adicional de autenticação. Definições Idle Connection obsoletas também não devem fazer parte de um design operacional moderno.

3. Ativar o túnel

Ao guardar, pode ser definido Activate on save. Em ambientes de produção, isto deve acontecer numa janela de manutenção definida, quando a contraparte estiver acessível e ambos os lados puderem verificar os logs.

Sem Activate on save, a ligação guardada é ativada através do respetivo botão Status em Site-to-site VPN > IPsec. Gateway type = Disable é uma definição distinta: a ligação permanece inativa até ser iniciada pelo utilizador. Respond only aguarda pedidos; Initiate the connection inicia a negociação também após um reinício do serviço VPN ou da firewall. Após um simples Disconnect, um iniciador pode voltar a ligar; para reverter a implementação, é necessário, por isso, desativar também a ligação.

Depois de guardar, a lista mostra dois estados relevantes:

• se a ligação está ativa
• se o túnel está realmente established

Uma entrada ativa não significa automaticamente um túnel estabelecido. Com várias redes locais ou remotas, também podem existir várias Security Associations.

API XML: separar configuração e ações de controlo

Para automatizar este procedimento, não basta traduzir os campos da GUI para um pedido XML. A referência API do SFOS 22 e do SFOS 23 apresenta as definições em VPNIPSecConnection/Configuration e, separadamente, os ramos de controlo Active, DeActive, Connection e DisConnection, cada um com Name. O comentário do exemplo indica que estes quatro ramos só funcionam depois de criar a ligação. O exemplo de configuração contém ainda Status com Active/Deactive; a linha de ActivateOnSave indica y/n. Guardar, ativar, o comportamento após um reinício e um túnel efetivamente estabelecido não são, por isso, definições intercambiáveis nem comprovam que um pedido API seja executável.

Esta representação antiga também contém contradições entre o exemplo e as linhas dos parâmetros:

• No exemplo, AliasLocalWANPort surge após um comentário relativo a uma porta WAN alias, mas a tabela define-o como ARRAY obrigatório. Name e RemoteHost também são apresentados como ARRAY; isto não define uma serialização segura de vários valores nem a sua associação aos pares.
• O exemplo de UserAuthenticationMode apresenta AsServer/AsClient, enquanto a linha indica EnableAsServer/EnableAsClient. Em DisconnectOnIdleInterval, o valor predefinido 0 fica fora do intervalo indicado 120..21600; 600 é apenas o valor do exemplo. Não uniformizar silenciosamente estas diferenças nem adotar os valores como predefinições de IKEv2.
• O campo antigo AllowNATTraversal com Enable/Disable não comprova a existência de um seletor NAT-T atual. A linha de RemoteHost proíbe * com RSAKey; trata-se de uma restrição dessa referência, não de uma regra geral de funcionamento da GUI confirmada aqui.

Enquanto a representação API do build instalado não estiver esclarecida, utilizar o procedimento WebAdmin acima e esclarecer as dúvidas antes de o automatizar. Confirmar os campos XML antes de construir um pedido; no procedimento GUI, mantêm-se a deteção automática de NAT-T e as indicações relativas a IKEv2, RSA e IDs.

Configurar IPsec route-based

IPsec route-based separa a negociação VPN da seleção da rota. Com Any-to-Any, o SFOS disponibiliza uma interface XFRM própria e endereçável. Os guias do SFOS 22 e do SFOS 23 descrevem também uma interface XFRM criada para Traffic Selectors específicos; ao contrário de Any-to-Any, esta interface não pode receber um endereço IP nem uma rota atribuída manualmente. Antes de uma migração, documentar a versão SFOS instalada, a associação da interface e a rota efetivamente criada.

1. Criar a ligação como route-based

Caminho do menu:

Site-to-site VPN > IPsec

Na ligação, escolher Route-based (Tunnel interface). Os parâmetros de gateway, autenticação, IDs e perfil IPsec continuam a ter de corresponder à contraparte. Além disso, é necessário compreender que interface XFRM será criada e como será encaminhada.

2. Implementar Any-to-Any ou Traffic Selectors

Para Any-to-Any, a Sophos mostra a interface XFRM criada sob a interface física usada em:

Network > Interfaces

Uma interface XFRM criada permanece sempre atribuída à zona VPN. As duas variantes são configuradas de forma diferente.

Any-to-Any com IPv4, IPv6 ou Dual

Quando Local subnet e Remote subnet estão ambas definidas como Any, o SFOS cria automaticamente a interface XFRM para a ligação IPsec route-based. Não se adiciona uma interface XFRM separada. Em Network > Interfaces, expandir a interface física escolhida como Listening interface e abrir a interface XFRM gerada. Neste exemplo, atribuir 10.255.0.1/30 à sede e 10.255.0.2/30 à filial. Com Dual, também são necessárias regras de firewall IPv4 e IPv6 separadas.

O Name editável é o nome de apresentação. Não deve ser confundido com os valores atribuídos pelo SFOS: Hardware é o nome do registo, IPsec connection é a ligação route-based associada e Network zone é sempre VPN. Configurar apenas os campos de endereço para a versão IP selecionada na ligação IPsec:

• IPv4/netmask: introduzir o endereço IPv4 de transferência planeado e selecionar a subnet.
• IPv6/prefix: introduzir o endereço IPv6 de transferência planeado e o prefixo.
• Com Dual, configurar ambas as famílias. Se a ligação usar apenas IPv4 ou apenas IPv6, o SFOS não aplica os valores introduzidos para a outra versão.

Em Advanced settings > Interface settings, manter o MTU predefinido ou introduzir o valor testado deliberadamente. O SFOS calcula o valor predefinido subtraindo o overhead IPsec máximo ao MTU da interface física. Ativar Override MSS e introduzir um valor apenas se a rede exigir um valor diferente do predefinido da firewall; não presumir um valor numérico predefinido que não esteja documentado.

Antes da alteração, registar o nome, endereços, MTU, estado e valor de Override MSS e as rotas ou gateways dependentes. Depois de guardar, reabrir a interface e verificar que Hardware, IPsec connection e a zona VPN atribuídos não mudaram. Em seguida, executar Route lookup em ambos os peers e testar tráfego real nas duas direções, incluindo uma transferência grande se MTU ou MSS tiver mudado. Para reverter, restaurar os valores registados e as rotas ou gateways anteriores. Numa ligação nova, desativá-la e remover apenas as rotas e regras dependentes; não tentar eliminar ou recriar separadamente a interface XFRM gerada.

Em seguida, criar a rota para a LAN remota em ambos os lados. Para uma configuração estática simples, abrir Routing > Static routes > IPv4 unicast route > Add:

• Sede: Destination 10.20.20.0/24, Interface a interface XFRM local.
• Filial: Destination 10.10.10.0/24, Interface a interface XFRM local.

Em alternativa, utilizar uma SD-WAN Route ou routing dinâmico através de BGP ou OSPF. Numa SD-WAN Route, decidir explicitamente se é permitido outro caminho de fallback. Se o tráfego não puder usar outra rota quando o túnel falhar, ativar Route only through specified gateways e testar este cenário separadamente.

As rotas e regras de firewall determinam que tráfego entra no túnel. Uma rota estática simples pode apontar diretamente para a interface XFRM. Para várias ligações, verificações SLA ou determinados designs de failover, cria-se adicionalmente um Custom Gateway com o endereço IP XFRM da contraparte e utiliza-se numa SD-WAN Route.

Para a alternativa SD-WAN, em Routing > SD-WAN routes, selecionar IPv4 e Add. Na sede, definir Source networks = HQ_LAN, Destination networks = Branch_LAN e, em Link selection settings, selecionar Primary and backup gateways. Em Primary gateway > Add, definir Gateway IP como 10.255.0.2 e Interface como a interface XFRM local com 10.255.0.1/30. Na filial, inverter Source/Destination, utilizar Gateway IP 10.255.0.1 e a interface XFRM local com 10.255.0.2/30. Para Health check, em Monitoring condition, selecionar um host interno da contraparte que efetivamente responda, por exemplo 10.20.20.15 na filial ou 10.10.10.25 na sede. A própria sonda tem de ser permitida e utilizar o túnel previsto. Para seleção baseada em SLA, selecionar um perfil SD-WAN com os gateways dos túneis. A rota estática e a rota SD-WAN são alternativas neste exemplo; não criar ambas sem verificação como caminhos concorrentes. Documentar a Route Precedence e as regras existentes antes da alteração e, ao reverter, restaurar a seleção anterior de rota/gateway.

Os túneis Any-to-Any podem controlar vários gateways XFRM diretamente através de SD-WAN e verificações SLA; não precisam de um grupo de failover VPN adicional. Em contrapartida, túneis policy-based e túneis route-based com Traffic Selectors utilizam um grupo de failover IPsec para ligações redundantes. O procedimento associado explica a ordem, Health Check, Automatic failback e o teste de falha controlado. O grupo desativa DPD nas ligações atribuídas e define Key negotiation tries como 3.

Verificar quatro pontos depois de guardar:

1. A interface XFRM é visível em Network > Interfaces e tem o endereço IP de transferência planeado.
2. A rota para a rede remota aponta diretamente para a interface XFRM ou, num design com gateway/SD-WAN, para o gateway XFRM adequado.
3. Diagnostics > Tools > Route lookup devolve a interface XFRM esperada ou o gateway XFRM para um host real na LAN remota. Efetuar o mesmo teste na contraparte.
4. As regras de firewall permitem apenas as direções e os serviços planeados.

Traffic Selectors

Para sub-redes específicas, os guias do SFOS 22 e do SFOS 23 analisados descrevem uma interface XFRM por configuração IPsec. Em Network > Interfaces, expandir a Listening interface através do indicador azul. Não atribuir à interface criada um endereço IP nem uma rota manual: a rota estática é criada automaticamente quando o túnel fica established. Na sede, selecionar Local HQ_LAN e Remote Branch_LAN; na filial, Local Branch_LAN e Remote HQ_LAN. O gateway, o perfil, a autenticação e os IDs são configurados de forma espelhada, tal como nas outras variantes. Em route-based, não é suportado Any apenas num lado com um Selector específico no outro. Se a interface documentada não aparecer no build instalado, esclarecer primeiro a configuração, a versão e os logs; não tentar forçar uma interface XFRM de substituição nem um endereçamento Any-to-Any.

Esta variante é adequada para redes pequenas e claramente definidas; a Sophos recomenda-a em vez de policy-based, também para ligações compatíveis a equipamentos de terceiros. Utilizar a interface XFRM em Diagnostics > Packet capture para identificar o tráfego de saída; verificar também a rota automática, cada Child SA esperada, os logs e o tráfego nas duas direções. WAF através de IPsec route-based com Traffic Selectors não é suportado; para esse fim, pode utilizar-se uma configuração route-based Any-to-Any adequada. Se a migração falhar, desativar a nova ligação e apenas as suas novas regras e reativar a ligação anterior documentada.

Um túnel Any-to-Any não pode ser convertido diretamente para Traffic Selectors específicos. É necessário clonar ou recriar a ligação e depois efetuar uma comutação controlada.

3. Considerar XFRM e MTU

As VPNs route-based são mais suscetíveis a equívocos relacionados com routing, MTU e MSS. Se testes pequenos funcionam, mas transferências maiores ficam bloqueadas, não se deve alterar imediatamente o perfil IPsec. Primeiro verificar MTU, MSS, fragmentação e o caminho real. O procedimento adequado está em verificar MTU e MSS na Sophos Firewall em problemas de VPN.

Regras de firewall, NAT e Device Access

Regras de firewall e regras automáticas

Depois da configuração IPsec, são necessárias regras para o tráfego de produção. Sem regras adequadas, o túnel pode ficar verde, mas as aplicações não funcionam.

Caminho do menu:

Rules and policies > Firewall rules

Regras típicas:

• Rede local para rede remota: por exemplo, de LAN para VPN.
• Rede remota para rede local de servidores: por exemplo, de VPN para Server.
• Management ou Monitoring: permitir apenas sistemas administrativos ou de monitoring definidos.
• DNS, AD, RDP, HTTPS: permitir apenas os serviços necessários, não Any de forma genérica.

As interfaces XFRM pertencem sempre à zona VPN. Se forem usadas ambas as direções, são necessárias regras inbound e outbound adequadas. Regras separadas com logging mostram com mais clareza, durante o teste de aceitação, que lado pode alcançar cada serviço. A configuração geral está descrita em criar e verificar em segurança regras da Sophos Firewall.

Os pacotes IPsec de entrada são primeiro desencapsulados e desencriptados. Em seguida, a regra de firewall correspondente aplica as suas políticas de segurança ao tráfego de dados antes de este ser encaminhado para o destino. Para o tráfego de saída, a regra de firewall correspondente é aplicada antes da encapsulação e da encriptação.

A opção Create firewall rule cria regras separadas com os prefixos Incoming e Outgoing no início da lista de regras. Depois:

• Verificar a posição das regras.
• Restringir Source e Destination.
• Reduzir Any aos Services necessários.
• Ativar Log firewall traffic para a implementação e análise de erros.
• Escolher conscientemente IPS, Web, Application Control e outras Security Features.
• Dar à regra um nome compreensível, por exemplo LAN_to_Branch_Zurich.

As regras geradas encontram-se no grupo Automatic VPN rules. No exemplo, a sede permite, na direção de saída, Source zone LAN, Source network HQ_LAN, Destination zone VPN e Destination network Branch_LAN; na direção de entrada, as zonas e as redes são invertidas. Na filial, aplica-se a mesma configuração espelhada, com Branch_LAN como rede local. Limitar Services às portas das aplicações autorizadas e ativar Log firewall traffic. As regras existentes adequadas podem ser complementadas com as redes Source/Destination corretas, em vez de criar novas regras para cada túnel. Antes disso, verificar o impacto em todas as outras ligações abrangidas pela regra. O SFOS avalia as regras de cima para baixo e para na primeira correspondência; uma nova regra no início da lista pode, por isso, sobrepor-se às restrições anteriores.

⚠️ As regras de firewall criadas automaticamente são um ponto de partida, não um design de segurança terminado. Especialmente em túneis entre localizações e redes de servidores, deve reduzir-se serviços, origens e destinos depois do primeiro teste.

Para route-based Any-to-Any, a Sophos não pode criar regras automaticamente. Com Dual, as regras IPv4 e IPv6 são criadas separadamente. Se o tráfego Internet de uma filial tiver de passar pela sede, é necessário também um design NAT e de segurança próprio.

Planear NAT conforme o tipo de túnel

NAT não é proibido com IPsec, mas deve ter uma razão clara. Casos típicos são redes sobrepostas, requisitos de nuvem ou terceiros que aceitam apenas endereços de origem específicos. NAT não substitui uma rota e não altera a decisão de routing: independentemente da tradução, o SFOS tem de conseguir selecionar uma rota VPN, estática, SD-WAN ou dinâmica adequada para o destino.

Caminho do menu:

Rules and policies > NAT rules

Antes de uma regra NAT, devem ser respondidas estas perguntas:

• A contraparte espera endereços IP originais ou traduzidos?
• Existem redes sobrepostas?
• O NAT é configurado na ligação IPsec ou através de regras NAT separadas?
• A direção de retorno está documentada?
• Depois do NAT, o Log Viewer mostra Source e Destination esperadas?

A lógica NAT difere conforme o tipo de VPN:

• Em IPsec policy-based e VPN route-based com Traffic Selectors, o NAT para redes sobrepostas pode ser configurado diretamente na ligação IPsec.
• Em route-based Any-to-Any, são usadas regras SNAT e DNAT em Rules and policies > NAT rules.
• Em redes sobrepostas, ambos os lados têm de compreender o mesmo plano de tradução. NAT unilateral sem planeamento do retorno cria muitas vezes túneis verdes sem tráfego utilizável.

Para NAT dentro da ligação IPsec, ativar Network Address Translation (NAT). Translated subnet mostra a rede local traduzida selecionada na ligação; em Original subnet, selecionar a rede local sobreposta real. Para redes sem tradução, manter Not translated. Antes de guardar, comparar numa tabela a rede original, a rede traduzida, o Remote Selector da contraparte e o endereço de destino DNS. Não deduzir a direção apenas a partir dos nomes dos campos; o procedimento NAT associado contém o exemplo completo. Para Any-to-Any, não utilizar estes campos como substitutos de regras SNAT/DNAT separadas.

⚠️ Em IPsec route-based com Traffic Selectors, utilizar a configuração NAT na ligação IPsec e não atribuir endereço IP nem rota manual a uma interface XFRM se o build instalado a mostrar. IPsec com NAT para redes sobrepostas mostra o design completo e espelhado de endereçamento, DNS e NAT.

Se o tráfego de uma VPN route-based com Traffic Selectors corresponder a uma regra SNAT com Translated source = MASQ, a firewall descarta os pacotes porque estas interfaces XFRM não têm endereços IP atribuídos. Isto pode explicar um túnel verde sem tráfego utilizável. Para o fluxo de teste afetado, verificar a regra NAT correspondente e a sua posição e corrigir apenas a regra em conflito; não desativar MASQ de forma generalizada para outras ligações. Depois, verificar novamente o mesmo fluxo nas duas direções com Log Viewer e Packet Capture.

Se o tráfego útil de IPsec policy-based for traduzido por uma regra SNAT separada, a respetiva Outbound interface tem de ser definida como Any. Uma regra que indique apenas portas WAN específicas — normalmente incluindo a regra SNAT predefinida — não corresponde a este tráfego VPN. Com Any, a firewall utiliza o valor de Translated source configurado na regra SNAT correspondente. Este comportamento também se aplica quando Override source translation (SNAT) está ativado para interfaces de saída específicas.

Desde o SFOS 22, o IPsec policy-based cria a rota VPN no backend. Uma ipsec_route manual não é um passo padrão, mas pode ser relevante em determinados cenários de tráfego encaminhado. Para pedidos de autenticação gerados pelo sistema, os textos de ajuda da Sophos para o SFOS 22 e o SFOS 23 contradizem-se: a visão geral de routing/NAT afirma que este tráfego não necessita do comando; o guia de autenticação, por sua vez, descreve uma exceção policy-based quando a Route Precedence selecionada não encaminha o tráfego para o túnel. Isto não implica uma rota adicional para todo o tráfego do sistema nem uma alteração generalizada da Route Precedence global.

Antes de qualquer alteração, o endereço de origem, sys-traffic-nat, os Traffic Selectors e o caminho de retorno têm de ser compatíveis com o fluxo de pacotes efetivamente observado. O guia existente sobre rotas IPsec e o procedimento para pedidos de autenticação gerados pelo sistema explicam as verificações específicas com um pedido real e Packet Capture, bem como o rollback separado para NAT e para a rota. Se o comportamento no build instalado continuar pouco claro, é necessário esclarecê-lo com o Sophos Support antes de efetuar uma alteração em produção. Confirmar a aplicabilidade desta exceção na versão SFOS utilizada. Outros fundamentos de NAT são abordados em Compreender as regras NAT da Sophos Firewall.

Device Access para IPsec de entrada

Para pedidos IPsec de entrada, a firewall tem de poder aceitar tráfego IPsec na zona WAN adequada. Isto não se resolve com uma regra LAN-to-WAN normal, mas através dos serviços locais da firewall.

Caminho do menu:

Administration > Device access

Aqui, IPsec tem de ser permitido para WAN quando a firewall aceita pedidos de entrada, por exemplo com Respond only. Isto não substitui regras para o tráfego útil através do túnel. Ao mesmo tempo, deve verificar-se se WebAdmin, SSH, User Portal ou VPN Portal estão acessíveis de forma desnecessariamente ampla. Para proteger estes serviços locais, proteger o acesso à Sophos Firewall: configurar Device Access corretamente é o artigo central.

Se uma contraparte tiver de enviar ping à própria firewall através do túnel, permitir a zona VPN em Ping/Ping6 e selecionar Apply. Este não é um passo global necessário para enviar ping a um host LAN: nesse caso, são relevantes as regras de trânsito adequadas e a firewall do host. Ativar apenas a permissão do serviço local necessária para o teste, documentar a definição original e restaurá-la após o teste, salvo se for necessária permanentemente. Além disso, um ping a partir da shell da firewall utiliza um endereço de origem diferente do de um cliente LAN; não tratar ambos os testes como verificações equivalentes da regra do cliente.

Testar o túnel e resolver problemas

Um bom teste de aceitação não verifica apenas o estado verde, mas o fluxo real de dados.

Definir a matriz de aceitação

Antes do primeiro teste, deve definir-se uma pequena matriz de aceitação. Assim fica claro que ligações têm realmente de funcionar e quais devem ser deliberadamente bloqueadas.

Casos de teste úteis:

• Rede local de clientes para rede remota de servidores: teste típico de aplicação, por exemplo HTTPS, RDP, SMB, SQL ou ICMP apenas como teste básico.
• Rede remota de clientes para rede local de servidores: verificar a direção oposta se a ligação for usada de forma bidirecional.
• DNS ou AD através do túnel: testar apenas se estes serviços devem realmente passar pelo túnel. Definir concretamente Source, servidor de destino e porta.
• Monitoring ou backup: verificar se os sistemas planeados acedem a partir da direção correta e não precisam acidentalmente de regras Any.
• Teste não permitido: uma porta ou rede deliberadamente não autorizada deve ser bloqueada. Caso contrário, a base de regras é demasiado ampla.
• Transferência grande: em transferências de ficheiros, RDP, VoIP ou problemas de aplicação, observar também MTU/MSS e fragmentação.

Para cada caso de teste, registar Source IP, Destination IP, Service, regra de firewall esperada, regra NAT esperada e direção esperada. Depois de cada teste, comparar Log Viewer, Packet Capture e contadores de bytes. Se só for testado ping, o túnel ainda não foi aceite.

1. Verificar o estado

Na interface WebAdmin:

Site-to-site VPN > IPsec

Verificar:

• A ligação está ativa.
• O estado do túnel é established.
• Com várias redes, todas as Child SA esperadas estão estabelecidas.

Em Current activities > IPsec connections, são apresentadas apenas as ligações efetivamente estabelecidas. Os filtros são Connection name, Local server name, Local subnet, Username, Remote server/host e Remote subnet; Refresh atualiza a vista. Disconnect termina uma SA existente de forma controlada, por exemplo quando ambos os lados estão prontos para uma alteração de configuração; não substitui a desativação nem o rollback da ligação.

Determinar antecipadamente o número esperado: route-based Any-to-Any cria uma ligação Phase 2 por interface XFRM, enquanto Dual cria uma para IPv4 e outra para IPv6. Policy-based e route-based com Traffic Selectors criam uma ligação para cada combinação de Local e Remote subnet.

Antes do primeiro tráfego útil em route-based Any-to-Any, verificar o endereço real do host de destino em Diagnostics > Tools > Route lookup. Em cada firewall, o resultado deve apontar para a interface ou o gateway XFRM previsto.

2. Verificar o Log Viewer

Caminho do menu:

Log viewer

Gerar tráfego de teste com Source, Destination e Service claros. Depois verificar no Log Viewer que regra de firewall corresponde e se NAT, Webfilter, IPS ou outros módulos influenciam o tráfego. O procedimento está em testar uma regra de firewall com Log Viewer, Policy Test e Packet Capture. Rekeys, disconnects e erros de ligação recorrentes são verificados nos logs IPsec e não inferidos do estado SA atual.

3. Packet Capture e Advanced Shell

Se o Log Viewer não for suficiente, deve usar-se Packet Capture com um filtro específico:

Diagnostics > Packet capture

Exemplo de filtro:

host 172.16.10.25 and host 10.20.30.15

No troubleshooting de VPN, é importante verificar ambas as direções. Apenas pacotes de saída sem resposta indicam normalmente um problema no caminho de retorno, NAT ou contraparte.

Para o exemplo utilizado ao longo do artigo, testar, a partir do cliente LAN 10.10.10.25, um host da filial que efetivamente exista, 10.20.20.15, e não o endereço de rede 10.20.20.0. No Windows, ping 10.20.20.15 -t inicia um teste contínuo; terminar com Ctrl+C. Em Diagnostics > Packet capture > Configure, definir BPF string como host 10.10.10.25 and host 10.20.20.15 and proto ICMP, guardar e ativar a captura. Em route-based, verificar a saída na interface XFRM associada e os pacotes de retorno. No Log viewer, procurar o endereço real do cliente; através da Firewall rule ID e de Filter firewall rule, abrir a regra correspondente. Depois, testar também uma porta de aplicação planeada e a direção oposta. Desativar novamente a captura e remover os filtros e as permissões temporários; uma captura contínua não constitui monitoring operacional. Se existir um router à frente da firewall, verificar adicionalmente nos logs de ambas as contrapartes que NAT foi detetado e NAT-T foi negociado.

Advanced Shell

Para troubleshooting mais aprofundado via SSH, abrir 5. Device Management > 3. Advanced Shell e verificar o estado SA atual:

ipsec statusall

São relevantes, entre outros:

• IKE SA established
• Child SA installed
• Traffic Selectors locais e remotos
• contadores de bytes nas duas direções

Se SSH ainda não estiver preparado, consulte ligar à Sophos Firewall por SSH.

Logs IPsec atuais

A visão geral atual dos logs do SFOS 22 separa as funções:

• strongswan.log: serviço IPsec e ligações.
• charon.log: serviço IPsec e NAT em ligações IPsec.
• ipsec_monitor.log: monitoring do serviço IPsec.
• /log/ipsec_conn/ipsec_<connectionname>.log: ativar, desativar e ligar através do WebAdmin.
• xfrmi.log: interfaces XFRM em IPsec route-based.
• dgd.log: apenas adicionalmente para VPN failover, SD-WAN, DGD ou Link Load Balancing, não como log IPsec geral.

Para um diagnóstico completo de logs e XFRM, siga Sophos Firewall IPsec VPN Troubleshooting.

Erros típicos

• O túnel não sobe: provavelmente não corresponde a versão IKE, perfil, PSK, certificado, Local ID ou Remote ID. Verificar strongswan.log, perfil IPsec e contraparte.
• Phase 1 está ativa, Phase 2 não: provavelmente não correspondem as redes locais ou remotas ou a proposta Phase 2. Verificar Traffic Selectors, sub-redes e PFS.
• Túnel verde, mas sem acesso: provavelmente falta uma regra de firewall, NAT, routing ou caminho de retorno. Verificar Log Viewer, Packet Capture e routing.
• Só uma direção funciona: a contraparte não conhece a rota de retorno ou o NAT está errado. Verificar contraparte, regras NAT e contadores de bytes.
• Pings pequenos funcionam, aplicações ficam bloqueadas: provavelmente estão envolvidos MTU/MSS, fragmentação ou uma Security Feature. Verificar MTU/MSS e Packet Capture.
• Route-based Any-to-Any não funciona: provavelmente não corresponde IP XFRM, gateway, rota ou regra de firewall. Verificar Network > Interfaces, routing e regras da zona VPN.
• Route-based com Traffic Selectors não funciona: verificar a interface XFRM documentada sob a Listening interface, a rota automática, cada Child SA esperada, os Selectors, as regras da zona VPN e uma possível regra MASQ. Utilizar a interface XFRM no Packet Capture, mas não lhe atribuir um endereço IP nem uma rota manual. Se não aparecer, esclarecer o build e a configuração, em vez de criar uma interface de substituição.
• Vários túneis influenciam-se: provavelmente existem redes sobrepostas ou configurações Selector semelhantes. Verificar objetos de túnel, Failover Group e rotas.

Rollback após uma aceitação falhada

Repor a configuração anterior de um novo túnel de forma controlada, em vez de eliminar regras e objetos com base em suposições:

1. Em Current activities > IPsec connections, terminar a SA afetada com Disconnect e desativar a nova ligação IPsec.
2. Desativar apenas as rotas estáticas ou SD-WAN, as regras NAT e as regras de firewall criadas para esta alteração, incluindo as regras VPN geradas automaticamente. Não eliminar separadamente uma interface XFRM gerada se o build a mostrar; a desativação da ligação gere essa interface.
3. Numa migração, voltar a atribuir o perfil anterior à ligação antiga e, em seguida, reativar a ligação e o caminho de routing antigo.
4. Testar novamente o fluxo de teste original e o tráfego de Internet local ou entre localizações com Log Viewer e Packet Capture.
5. Remover os novos objetos apenas quando Object Usage já não mostrar dependências e estiver comprovado que o caminho antigo voltou a funcionar.

Remover uma ligação guardada específica

Eliminar uma ligação IPsec guardada é diferente de Disconnect, da desativação ou da eliminação de um grupo de failover. Antes de uma remoção autorizada separadamente, documentar o Name existente exato, Object Usage, as pertenças a grupos e um acesso de gestão independente do túnel. Não eliminar uma ligação enquanto pertencer a um grupo de failover; o procedimento de failover associado descreve a remoção controlada da atribuição.

A referência de eliminação da API XML do SFOS 22 e do SFOS 23 define Name como ARRAY obrigatório com tipo de dados STRING: primeiro carácter A-Za-z, seguintes A-Za-z0-9_, máximo de 100 caracteres e vários valores permitidos. Não contém, contudo, um exemplo de pedido. Não deduzir um serializador para vários nomes nem um nome de destino a partir do exemplo GUI branch-zurich; não alterar um nome guardado para o tornar aparentemente conforme.

A referência associa o estado da operação XML 200 a Message.IPSecDeleteSuccess, 201 a Message.IPSecConnInUse e 500 a Message.IPSecDeleteFail. Os textos das mensagens são inseridos através de JavaScript e não estão resolvidos aqui: não são códigos de estado HTTP nem textos de resposta apresentados e confirmados. Não contabilizar 201 como eliminação bem-sucedida apenas porque começa por 2; em Edit, o mesmo número corresponde a Message.IPSecUpdated. Após uma remoção autorizada, voltar a consultar exatamente esse alvo e verificar os caminhos de produção restantes. Se o resultado não for claro, esclarecer primeiro o estado do alvo e as dependências antes de tentar novamente; não repetir às cegas.

Checklist

Antes da alteração:

• As redes locais e remotas são inequívocas.
• Policy-based ou route-based foi escolhido conscientemente.
• O perfil IPsec está alinhado com a contraparte.
• Preshared Key, certificados ou chaves RSA estão documentados de forma segura.
• As regras de firewall estão planeadas, incluindo direção, posição, logging e serviços.
• Com Create firewall rule, é claro que regras criadas automaticamente têm de ser ajustadas.
• Em route-based Any-to-Any, IP XFRM, gateway, regras de firewall manuais e rotas estão planeados.
• Em route-based com Traffic Selectors, foi registada a visibilidade XFRM real; não estão planeados IP XFRM nem rotas manuais, quer o build mostre a interface quer não.
• NAT está excluído ou documentado conscientemente.
• Device Access para IPsec de entrada foi verificado.
• Janela de manutenção, contraparte e caminho de fallback são conhecidos.

Depois da alteração:

• O estado do túnel é established.
• Uma matriz de aceitação com pelo menos um teste por direção necessária foi executada e aprovada.
• O Log Viewer mostra a regra de firewall esperada.
• O Packet Capture mostra direção de ida e de retorno.
• Foram testados DNS interno e acessos a aplicações.
• Os contadores de bytes aumentam nas duas direções.
• NAT e caminho de retorno estão alinhados com a contraparte.
• A alteração foi atualizada na documentação de rede.

Perguntas frequentes