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 Central, um grupo de ligações SD-WAN 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. Nas versões atuais do SFOS, estes termos estão separados de forma mais clara do que em instruções antigas, que por vezes ainda falam de Site-to-Site ou Tunnel Interface.

• IPsec policy-based: adequado para ligações simples entre localizações com redes locais e remotas bem definidas. O controlo é feito principalmente através das sub-redes locais e remotas na ligação IPsec e através das regras de firewall. A Sophos cria túneis Phase 2 individuais para cada combinação de sub-redes locais e remotas.
• IPsec route-based com Traffic Selectors: também utiliza sub-redes locais e remotas, mas cria uma interface XFRM própria. A Sophos gera a rota automaticamente; não podem ser atribuídos à interface XFRM um endereço IP nem rotas próprias. WAF não é suportado com esta variante.
• IPsec route-based Any-to-Any: é a variante mais flexível para redes em crescimento, SD-WAN, routing dinâmico e designs dual-stack. As rotas e regras de firewall decidem então que pacotes entram no túnel, e não as sub-redes da ligação IPsec.

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.

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.

⚠️ 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.

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.

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. Uma CA pública não deve ser usada de forma genérica como Remote CA Certificate, pois concederia demasiada confiança a certificados externos. RSA key é um Authentication type separado: as duas firewalls trocam as chaves públicas e têm de usar o mesmo formato PKCS1 ou DNS.

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.

Se a CA revogar certificados antes de expirarem, a lista de revogação atual também deve fazer parte do plano operacional. O procedimento separado descreve a importação da CRL, 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 IPsec_IKEv2_AES256_G14. 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.

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

Em IPsec policy-based, no máximo um lado dos Traffic Selectors pode estar definido como Any. Com várias redes locais e remotas específicas, a Sophos cria uma Phase 2 SA para cada combinação.

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.

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.

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.

Configurar IPsec route-based

IPsec route-based separa a negociação VPN e o caminho de dados através de uma interface XFRM própria. A atribuição de endereço e routing manual a esta interface depende da variante escolhida.

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

A Sophos mostra a interface XFRM criada sob a interface física usada em:

Network > Interfaces

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

Any-to-Any e Dual

Se ambas as sub-redes estiverem definidas como Any ou for usado Dual, a interface XFRM recebe um endereço IP de transferência. Depois é necessária uma rota estática, SD-WAN Route ou rota dinâmica via BGP ou OSPF. Com Dual, são necessárias regras de firewall IPv4 e IPv6 separadas.

As rotas e regras de firewall decidem 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 do peer e utiliza-se numa SD-WAN Route.

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.

Depois de guardar, verificar três pontos:

1. A interface XFRM está visível em Network > Interfaces e configurada com 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. As regras de firewall permitem apenas as direções e os serviços planeados.

Traffic Selectors

Com Local subnet e Remote subnet específicas, a Sophos também cria uma interface XFRM, mas não podem ser-lhe atribuídos um endereço IP nem rotas próprias. A rota estática é criada automaticamente quando o túnel fica established. Any apenas de um lado e um Selector específico do outro não são suportados.

Esta variante é adequada para redes pequenas e claramente definidas e facilita o diagnóstico XFRM. WAF através de IPsec route-based com Traffic Selectors não é, contudo, suportado.

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.

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 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 tem de ser claramente justificado. Casos típicos são redes sobrepostas, requisitos cloud ou terceiros que só aceitam determinados endereços de origem.

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.

⚠️ Em IPsec route-based com Traffic Selectors, a interface XFRM não tem endereço IP. Se este tráfego corresponder a uma regra MASQ-SNAT, a firewall descarta os pacotes. Por isso, para redes sobrepostas, use a definição NAT na ligação IPsec e assegure que nenhuma regra MASQ-SNAT abrange este tráfego.

Desde o SFOS 22, o IPsec policy-based cria a rota VPN no backend. Uma ipsec_route manual só é relevante para tráfego traduzido e encaminhado específico e não é um passo padrão; o tráfego gerado pelo sistema não precisa dela. Mais fundamentos sobre NAT estão 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.

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.

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.

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: não configurar IP nem rota manual na interface XFRM. Verificar rota automática, Selectors, regras da zona VPN e uma possível regra MASQ.
• Vários túneis influenciam-se: provavelmente existem redes sobrepostas ou configurações Selector semelhantes. Verificar objetos de túnel, Failover Group e rotas.

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, não estão planeados IP ou rotas manuais na interface XFRM.
• 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.
• Está definida uma matriz de aceitação com pelo menos um teste para cada direção necessária.
• 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