Regra da Sophos Firewall não é aplicada: verificar causas

Quando uma regra da Sophos Firewall não é aplicada, não se devem começar por mover regras ou alargar objetos. Primeiro reproduz-se e observa-se um único fluxo de dados: o pacote chega, que Firewall Rule ID e NAT Rule ID o processam, é encaminhado e regressa uma resposta?

Na maioria dos casos, uma condição é diferente do esperado, uma regra mais geral acima é aplicada ou o problema só surge depois da decisão da regra. A própria firewall é muito menos frequentemente a causa do que um teste definido de forma imprecisa.

Decisão rápida: Se um Packet Capture corretamente iniciado e filtrado não mostrar qualquer pacote, verificam-se primeiro o cliente, VLAN, gateway ou o caminho anterior à firewall. Um Rule ID diferente conduz à ordem e ao matching. Se Rule ID e NAT ID estiverem corretos, a análise prossegue para routing, caminho de retorno, sistema de destino ou módulo de segurança.

Caminho rápido: seguir um fluxo concreto

Para o primeiro diagnóstico bastam seis passos:

1. Definir o fluxo de teste: Registar Source IP, Source zone, User, Destination, protocolo, porta e hora.
2. Comprovar a entrada: Iniciar Packet Capture com um Capture Filter restrito e acionar o mesmo fluxo.
3. Verificar a Firewall Rule ID: Comparar no Log Viewer ou Packet Capture com a regra esperada.
4. Verificar a NAT Rule ID: Se houver NAT, controlar a regra NAT efetiva e a respetiva tradução.
5. Verificar encaminhamento e resposta: Procurar Forwarded, a interface de saída e pacotes de resposta.
6. Só depois aprofundar: Analisar routing, SD-WAN, User Matching, TLS Inspection, IPS, Web Policy ou sistema de destino.

Este processo mantém as camadas separadas. Uma regra de firewall decide o acesso e as funções de proteção, NAT traduz endereços ou portas, routing seleciona o caminho seguinte e o sistema de destino tem de conhecer o caminho de retorno. Se todas as camadas forem alteradas ao mesmo tempo, o sintoma pode desaparecer, mas a causa permanece incerta.

Se o teste se destinar ao WebAdmin, User Portal, VPN Portal, SSH, DNS, SNMP ou outro serviço da própria firewall, aplicam-se regras diferentes das do tráfego em trânsito. Nesse caso, o diagnóstico segue diretamente para Administration > Device access e Local Service ACL.

Definir um caso de teste reproduzível

Uma afirmação como “a internet não funciona” ou “a regra VPN não é aplicada” é demasiado ampla. Um caso de teste útil tem, por exemplo, este formato:

• Source IP: 10.10.20.35
• Source zone: LAN
• User: admin@example.com ou deliberadamente sem User Matching
• Destination: app.example.net, atualmente resolvido para 203.0.113.20
• Service: TCP 443
• Regra de firewall esperada: LAN-App-HTTPS, Rule ID 37
• Regra NAT esperada: NAT Rule ID 12 ou explicitamente nenhuma regra NAT
• Hora do teste: 2026-08-08 10:15:00

Os endereços IP, IDs, nomes e hora são valores de exemplo e devem ser substituídos pelos valores do próprio ambiente. O formato é importante: durante o diagnóstico, Source, IP de destino, porta e utilizador permanecem iguais. Se a resolução DNS, o cliente ou a aplicação mudarem entretanto, já não se está a comparar o mesmo fluxo.

Interpretar as primeiras observações

• Packet Capture ativo não mostra pacotes apesar de um filtro adequado: Verificar primeiro o estado da captura, o filtro e o buffer. Se estiverem corretos, a causa está provavelmente antes da firewall, por exemplo no cliente, VLAN, switch, gateway, fornecedor ou Cloud Security Group.
• Log Viewer mostra outra Rule ID: Uma regra mais geral, criada automaticamente ou com outro matching é avaliada primeiro.
• Firewall Rule ID está correto, NAT Rule ID não: Verificar a ordem NAT e Original source, destination e service.
• Rule ID e NAT ID estão corretos, mas Forwarded não é visível: Verificar a ação da regra, Reason, routing ou um módulo de segurança.
• Forwarded é visível, mas não chega uma resposta: Verificar a rota de retorno, o sistema de destino, a firewall local do servidor ou um bloqueio externo.
• Apenas determinados utilizadores são afetados: Verificar separadamente a autenticação e o User Matching do fluxo de dados real.

O processo combinado detalhado encontra-se em Testar uma regra de firewall com Log Viewer, Policy Tester e Packet Capture. Este artigo concentra-se em explicar um matching de regra inesperado.

Verificar a ordem e o matching das regras

Uma regra de firewall só é aplicada se todos os critérios relevantes corresponderem e nenhuma regra anterior já tiver processado o mesmo tráfego.

A primeira regra correspondente prevalece

A Sophos Firewall avalia as regras de cima para baixo e termina a procura na primeira regra correspondente. Por isso, a posição na lista é decisiva; a Rule ID é apenas um identificador fixo e não corresponde à posição.

Também se deve ter em conta o seguinte:

• Uma regra geral acima pode ocultar completamente uma regra específica abaixo.
• Rule Groups melhoram a visão geral, mas não criam uma lógica de matching própria. São avaliadas as regras incluídas.
• Regras criadas automaticamente, por exemplo para MTA, IPsec ou hotspots, podem ser inseridas acima e verificadas primeiro.
• Um filtro ativo na tabela de regras pode ocultar regras relevantes. Antes da análise deve usar-se Reset filter.
• A regra Default Drop imutável tem a Rule ID 0, encontra-se no fim e não possui um Usage Counter normal. Os filtros da tabela não se aplicam a esta regra.

A lógica fundamental é explicada integralmente em Compreender e configurar corretamente regras da Sophos Firewall.

Ler em conjunto todos os critérios de matching

Uma regra visualmente correta pode falhar devido a um único campo:

• Source zones: O cliente chega de outra zona, por exemplo VPN em vez de LAN, ou o VLAN está atribuído de outra forma.
• Source networks and devices: O objeto IP, grupo de hosts ou sub-rede não contém o Source IP real.
• Destination zones: A zona de destino está errada, sobretudo com DNAT, VPN ou redes encaminhadas.
• Destination networks: O IP efetivamente contactado não corresponde ao objeto ou confundiram-se as perspetivas antes e depois de NAT.
• Services: Falta a porta, TCP e UDP foram trocados ou a aplicação abre ligações adicionais.
• Users or groups: A firewall não consegue associar o utilizador ao Source IP ou o grupo importado não corresponde.
• Schedule: O horário não está ativo no momento do teste.
• Exclusions: O fluxo é excluído da regra e depois verificado em relação às regras seguintes.

No tráfego web, o protocolo também faz parte do teste. Os browsers podem usar QUIC através de UDP 443, enquanto a regra ou inspeção web esperada abrange apenas HTTPS clássico através de TCP 443. As consequências são explicadas em Controlar QUIC na Sophos Firewall.

Repor de forma controlada o volume de dados transferido

A opção Reset data transfer count pode ajudar no teste, mas é frequentemente interpretada de forma incorreta. Repõe o volume de dados transferido através da regra; não é um contador de sessões nem de correspondências.

1. Abrir Rules and policies > Firewall rules.
2. Localizar a regra afetada e abrir o menu de três pontos.
3. Selecionar Reset data transfer count.
4. Acionar novamente o fluxo de teste definido.
5. Avaliar em conjunto o volume de dados, Rule ID e Packet Capture.

Se o valor aumentar depois do teste controlado, isso indica tráfego transferido através desta regra. Se permanecer inalterado, isso por si só não prova que a regra nunca correspondeu. Para uma conclusão fiável, verificam-se a Rule ID real no Log Viewer e o caminho dos pacotes no Packet Capture. Na regra Default Drop com a ID 0, este contador de dados não está disponível.

Ler corretamente Log Viewer, Policy Tester e Packet Capture

As ferramentas respondem a perguntas diferentes:

• Log Viewer: Que sessão registada, regra, regra NAT, ação e utilizador foram reconhecidos?
• Policy Tester: Que lógica de policy seria aplicada aos valores introduzidos?
• Packet Capture: Que pacotes chegam realmente, como são processados pela firewall e voltam a sair?

Nenhuma das ferramentas substitui completamente as outras. Se a simulação e o fluxo real de pacotes forem contraditórios, os dados de log e pacotes do teste reproduzível têm maior peso.

Log Viewer: Rule ID e NAT Rule ID reais

Na regra de firewall, Log firewall traffic tem de estar ativado. Além disso, em System services > Log settings, o tipo de log adequado tem de estar ativo para visualização local, Sophos Central ou Syslog.

Para o teste são úteis filtros nos seguintes campos:

• Source IP e Destination IP
• porta ou Service
• Rule ID e Rule name
• NAT rule ID
• Action e User
• a hora de teste registada

A ausência de um registo ainda não prova que a firewall não viu nada. As sessões de firewall são registadas, entre outros momentos, quando a ligação termina com um evento Destroy. Em interrupções abruptas, o registo esperado pode não aparecer ou surgir mais tarde. Nesse caso, Packet Capture fornece uma indicação mais direta. Os serviços e ficheiros de log correspondentes são descritos em Troubleshooting da Sophos Firewall: serviços e logs.

Policy Tester: lógica de policy sem fluxo real de pacotes

Em Diagnostics > Tools > Policy tester, URL, User, hora, Source IP e Source zone são definidos deliberadamente. O protocolo e a porta devem resultar do URL completo, por exemplo https://app.example.net:8443/. Sem protocolo, a ferramenta testa HTTP; em HTTPS é usada por predefinição a porta 443, e uma porta diferente tem de ser indicada no URL.

O Policy Tester é útil, mas tem limites claros:

• Não gera um fluxo real de pacotes nem verifica o sistema de destino ou o caminho de retorno.
• Os resultados não representam rotas SD-WAN.
• Regras com endereços MAC em Source networks and devices não podem ser correspondidas.
• Problemas no fornecedor, switch, gateway e perda de pacotes permanecem invisíveis.

⚠️ No SFOS 22.0 GA Build 411, NC-177587 e NC-176083 podiam causar resultados incorretos no Policy Test. O tráfego parecia bloqueado ou associado à regra errada, embora na realidade circulasse corretamente. O MR1 Build 490 contém as correções documentadas. Em resultados contraditórios, verificar primeiro a versão do firmware, Log Viewer e Packet Capture antes de alterar regras de produção.

Packet Capture: verificar o caminho real dos pacotes

Em Diagnostics > Packet capture, define-se primeiro um BPF Capture Filter restrito, por exemplo com Source IP, Destination IP e porta do fluxo de teste. Em seguida, ativa-se Trace On, limpa-se a lista e aciona-se exatamente o fluxo definido.

Um Packet Capture vazio só é significativo quando estes requisitos estão cumpridos:

1. Trace On está ativo.
2. O BPF Capture Filter corresponde ao destino real e não exclui o fluxo.
3. O buffer ainda não substituiu o tráfego de teste relevante. Sem Wrap capture buffer once full, a gravação para quando o buffer de 2048 KB fica cheio e continua depois de Clear. Com a opção Wrap ativa, a gravação continua e substitui os pacotes mais antigos.

Um Display Filter adicional não altera o que foi gravado, mas pode ocultar entradas existentes. Por isso, Capture Filter e Display Filter devem ser verificados separadamente.

Os valores de estado significam:

• Incoming: O pacote foi recebido numa interface.
• Forwarded: A firewall encaminha o pacote por uma interface de saída.
• Consumed: O pacote destina-se à própria firewall ou é utilizado por ela.
• Generated: A firewall gerou o pacote.
• Violation: Uma violação da policy causa o bloqueio; o campo Reason explica o motivo em maior detalhe.

Rule ID, NAT ID, Reason e interfaces de entrada e saída são sempre analisados em conjunto. Consumed e Generated são resultados normais e não representam automaticamente erros.

⚠️ No SFOS 22.0 MR1 Build 490, NC-178387 pode mostrar bloqueios pela regra Default com a ID 0 apenas como Incoming. A entrada esperada Violation Firewall e a entrada em drppkt não aparecem, embora a firewall continue a rejeitar o fluxo. Nesta versão afetada, ajudam o Policy Tester ou uma regra Drop deliberadamente colocada e registada no fim da própria lista de regras. A informação atual de Known Issues não indica uma versão de correção.

Um processo de captura detalhado encontra-se em Usar Packet Capture no WebAdmin da Sophos Firewall. Os bloqueios e uma regra final controlada são abordados em Analisar pacotes bloqueados pela Sophos Firewall.

Verificar NAT, DNAT, routing e caminho de retorno

NAT não permite tráfego. Traduz endereços ou portas para tráfego permitido por uma regra de firewall. Por isso, Firewall Rule ID e NAT Rule ID têm de estar corretos separadamente.

Avaliar Firewall Rule ID e NAT Rule ID em conjunto

• Firewall Rule ID está correto, NAT Rule ID está errado: Verificar a ordem NAT, os campos Original e regras NAT mais gerais.
• NAT Rule ID está correto, Firewall Rule ID está errado: Comparar a ordem das regras de firewall, zonas, Source, Destination, Service e Schedule.
• Ambos os IDs estão corretos, mas a ligação falha: Verificar routing, caminho de retorno, servidor de destino, módulo de segurança ou aplicação.
• Não é visível qualquer NAT Rule ID apesar de se esperar NAT: Verificar a direção, Inbound/Outbound Interface e os critérios Original da regra NAT.

Em Rules and policies > NAT rules também prevalece a primeira regra correspondente. Uma regra SNAT ou MASQ geral pode, por isso, ocultar uma regra específica abaixo. As Linked NAT Rules também só são consideradas para tráfego que corresponda à respetiva regra de firewall; uma regra NAT independente anterior pode, ainda assim, ser aplicada primeiro.

A lógica completa das IDs é explicada em Compreender NAT na Sophos Firewall.

Compreender DNAT nas perspetivas antes e depois de NAT

Para tráfego DNAT de entrada, aplica-se uma regra importante:

A regra de firewall usa a zona de destino depois de NAT, mas como Destination Network o endereço originalmente contactado antes de NAT.

Exemplo de encaminhamento de porta:

• O cliente externo liga-se a 198.51.100.10 através de TCP 8888.
• A regra NAT traduz para o servidor 10.10.50.20 na zona DMZ e para TCP 4444.
• Na regra NAT, TCP 8888 é o Original service e TCP 4444 é o Translated service (PAT).
• A regra de firewall usa WAN como Source zone, DMZ como Destination zone e 198.51.100.10 como Destination network.
• No exemplo oficial Sophos de PAT, a regra de firewall associada contém tanto o serviço original como o traduzido.

O teste externo continua a ser efetuado na porta 8888; o servidor interno recebe a ligação na porta 4444. Se apenas uma das duas portas for considerada, a regra pode parecer correta apesar de o matching do serviço e a tradução não coincidirem. Uma publicação completa é descrita em Publicar um servidor por DNAT na Sophos Firewall.

Criar uma nova ligação depois de alterações NAT

A Sophos Firewall avalia uma regra NAT apenas para o primeiro pacote de uma ligação. As sessões existentes continuam a usar a tradução anterior, mesmo que a regra NAT já tenha sido alterada.

Depois de uma correção NAT, cria-se portanto uma nova ligação: termina-se o teste em curso, fecha-se a sessão existente do browser ou da aplicação e inicia-se novamente o fluxo. Um reload dentro da mesma sessão TCP não comprova de forma fiável a nova configuração NAT.

Analisar routing apenas depois de confirmar o matching

Se Rule ID e NAT Rule ID estiverem corretos e Packet Capture mostrar Forwarded, o Rule Matching está fundamentalmente comprovado. Depois verificam-se:

• uma rota estática adequada ou Default Route
• SD-WAN route e gateway ativo
• interface de saída efetiva
• rota no sistema de destino e em redes remotas
• caminho de retorno simétrico através de VPN, MPLS ou WAN
• firewall local do servidor de destino

O Policy Tester não representa SD-WAN. Para a decisão real contam Gateway ID, interface e caminho dos pacotes. A ordem das rotas estáticas, SD-WAN e VPN é explicada em Ajustar a prioridade de routing na Sophos Firewall.

Casos especiais depois da primeira conclusão

Só depois de classificar o fluxo básico vale a pena aprofundar serviços locais, utilizadores, resolução de nomes ou módulos de segurança.

Tráfego para a própria firewall: Device Access em vez de regra de firewall

WebAdmin, User Portal, VPN Portal, SSH, IPsec, SSL VPN, DNS e SNMP terminam na firewall. O estado no Packet Capture pode, por isso, ser Consumed. O acesso é controlado em Administration > Device access e através de Local Service ACL Exception Rules, não por uma regra normal de tráfego em trânsito.

Devem verificar-se a zona, rede de origem fidedigna, serviço permitido, autorização do utilizador e MFA. A interação relevante para a segurança é explicada em Proteger Sophos Firewall Device Access e Local Service ACL; as várias interfaces web são classificadas em Visão geral dos portais da Sophos Firewall.

Separar login do utilizador e User Matching

Um login bem-sucedido no VPN Portal, User Portal, Captive Portal ou através de Entra ID SSO confirma inicialmente apenas a autenticação. Para a regra de utilizador prevista ser aplicada, a firewall também tem de associar o utilizador ao fluxo de dados real e ao respetivo Source IP.

Resultados típicos:

• O campo User no Log Viewer está vazio: Verificar STAS, AD SSO, Captive Portal, Entra ID SSO ou Clientless User. Para um IP fixo de dispositivo, configurar e testar Clientless Users mostra a associação com a verificação em Live Users e o teste negativo.
• O utilizador está visível, mas é aplicada outra regra: Comparar a posição da regra, condição de grupo ou regra mais geral acima.
• Apenas utilizadores VPN são afetados: Verificar a zona VPN, pool VPN, Source network e matching do grupo.
• Apenas utilizadores individuais são afetados: Comparar UPN, endereço de e-mail, grupo importado do diretório e grupo da Sophos Firewall.

Em ambientes AD locais, ajudam Configurar STAS na Sophos Firewall e Adicionar Active Directory à Sophos Firewall. Consoante o caminho de login Entra, aplicam-se Entra ID SSO para Sophos Connect e VPN Portal ou Entra ID SSO para Captive Portal. Com muitos utilizadores reconhecidos ou Clientless Users, o limite de User ID da Sophos Firewall também pode ser relevante.

Verificar DNS, FQDN, CDN e IPv6

Para o Rule Matching conta o IP de destino efetivamente utilizado, não apenas o nome do host introduzido. Cache DNS, Split DNS, serviços CDN, outro resolver, destinos API adicionais ou IPv6 podem direcionar o fluxo para outro endereço.

Os FQDN Hosts normais são resolvidos pela própria firewall, que atualiza a associação de acordo com o DNS TTL. Wildcard FQDNs funcionam de forma diferente: a firewall aprende endereços IP de subdomínios correspondentes a partir de respostas DNS observadas. Se o cliente usar um resolver externo, o respetivo tráfego UDP DNS na porta 53 tem de passar pela firewall. Se a resposta em causa não estiver visível para a firewall, o IP do subdomínio pode faltar no objeto Wildcard e a regra não corresponder apesar de o nome parecer correto.

Além disso, FQDN Hosts não suportam resolução IPv6. Antes de expandir um objeto, deve comparar-se a resposta DNS, IP de destino e versão IP com Log Viewer ou Packet Capture. Os detalhes sobre TTL, Wildcards e comportamento de aprendizagem encontram-se em FQDN Hosts e Wildcard FQDNs na Sophos Firewall. Para resolução interna ajudam DNS Request Routes; um ambiente IPv6 ativo requer regras próprias e um conceito IPv6 consciente.

Distinguir módulos de segurança e Traffic Shaping

Se Firewall Rule ID, NAT Rule ID e routing estiverem corretos, um módulo atribuído à regra pode afetar a aplicação:

• Web Policy e Application Control
• SSL/TLS inspection rule e Decryption Profile
• IPS Policy e Malware Scan
• Zero-Day Protection
• Security Heartbeat

É sempre isolado apenas um módulo para o fluxo concreto e durante um período de teste curto. Uma exceção permanece limitada a Source, destino e Service; depois restaura-se a proteção original ou documenta-se a exceção necessária. Em problemas HTTPS ajuda uma implementação controlada de TLS Inspection.

Traffic Shaping, pelo contrário, é uma função QoS. Garante, prioriza ou limita a largura de banda e pode assim provocar baixo throughput, perda de pacotes em congestionamentos ou timeouts. Não é o mesmo que a decisão de acesso Drop ou Reject. Para um bloqueio real, verificam-se o estado do Packet Capture, Reason e o módulo de segurança responsável. Em transferências grandes ou ligações VPN, MTU e MSS também fazem parte da análise.

Testar e documentar alterações de forma controlada

Em problemas de regras deve alterar-se apenas uma variável por teste:

1. Registar o estado inicial com Source, Destination, Service, User, hora, Rule ID e NAT ID.
2. Alterar exatamente uma posição de regra, objeto, Service ou módulo.
3. Com NAT, criar uma nova ligação; nos restantes casos, acionar novamente o mesmo fluxo de teste.
4. Comparar Log Viewer e Packet Capture com os mesmos filtros.
5. Documentar sucesso ou falha e só depois verificar a alteração seguinte.

Regras temporárias Allow, Drop ou de exceção recebem um nome compreensível, um owner e uma data de validade. Caso contrário, uma ajuda de diagnóstico de curto prazo permanece rapidamente no conjunto de regras.

Se a ligação ainda funcionava ontem, as últimas alterações de configuração também devem ser verificadas. Audit Trail Logs mostram quem alterou regras ou objetos. Config Studio ajuda a comparar configurações maiores. Se a alteração veio do Sophos Central, verifica-se adicionalmente a Central Firewall Task Queue.

Checklist para troubleshooting de regras

• Fluxo de teste concreto definido com Source, Destination, Service, User e hora.
• Verificado se se trata de tráfego em trânsito ou de um serviço local da firewall.
• Controladas a posição da regra, regras automáticas e filtros ocultos da tabela.
• Comparados todos os campos de matching com o fluxo real.
• Volume de dados usado apenas como indicação e não como contador de correspondências.
• Log Viewer mostra a Firewall Rule ID efetiva e, quando aplicável, a NAT Rule ID.
• Resultado do Policy Tester comparado com a versão do firmware e dados reais dos pacotes.
• Packet Capture funciona com Capture Filter adequado e buffer livre.
• Incoming, Forwarded, Consumed, Generated, Violation, Reason e interfaces corretamente interpretados.
• Em DNAT, verificadas a zona de destino depois de NAT, Destination Network antes de NAT e ambos os serviços PAT.
• Criada uma nova ligação depois de alterações NAT.
• Verificados a resposta DNS, IP de destino, comportamento de aprendizagem FQDN e versão IP.
• User Login e User Matching do fluxo de dados verificados separadamente.
• Routing, SD-WAN, gateway e caminho de retorno analisados apenas depois de confirmar o matching da regra.
• Módulos de segurança verificados individualmente e Traffic Shaping como QoS.
• Todas as alterações documentadas; regras de teste têm owner e data de validade.

FAQ