aprendemos a investigar um programa aparentemente bloqueado pelo Firewall do Windows.
Analisamos:
wf.msc
Get-NetFirewallRule
Get-NetFirewallApplicationFilter
Get-NetFirewallPortFilter
Get-NetFirewallAddressFilter
Test-NetConnection
netstat
e outras ferramentas.
Esse processo permite descobrir quais regras podem estar relacionadas a determinada comunicação.
Mas ainda resta uma pergunta importante:
como descobrir se o Firewall do Windows realmente descartou uma conexão?
É aqui que entram os logs.
Em vez de apenas olhar para uma regra e imaginar o que aconteceu, podemos configurar o Firewall do Windows para registrar informações sobre tráfego permitido e descartado.
O principal arquivo utilizado nesse diagnóstico é conhecido como:
pfirewall.log
Quando configurado corretamente, esse arquivo pode ajudar a responder perguntas como:
O Firewall realmente descartou um pacote?
Qual era o IP de origem?
Qual era o IP de destino?
Era TCP ou UDP?
Qual porta estava envolvida?
Em que horário aconteceu?
Essas informações transformam o log em uma excelente ferramenta de troubleshooting.
O que é o pfirewall.log?
O pfirewall.log é um arquivo de texto utilizado pelo Firewall do Windows para registrar informações de tráfego conforme as opções de logging configuradas.
O caminho tradicional padrão é:
%windir%\system32\logfiles\firewall\pfirewall.log
Em uma instalação comum do Windows, %windir% normalmente corresponde à pasta do Windows.
Portanto, frequentemente encontraremos:
C:\Windows\System32\LogFiles\Firewall\pfirewall.log
Mas não devemos assumir que esse será sempre o caminho utilizado.
A localização pode ser configurada.
Por isso, primeiro devemos descobrir qual configuração está realmente ativa.
O arquivo pode existir e ainda assim não conter o que você procura
Esse é um detalhe fundamental.
Encontrar:
pfirewall.log
não significa automaticamente que todas as conexões do computador estejam sendo registradas.
O Firewall possui opções específicas para registrar:
conexões permitidas
e:
pacotes/conexões descartados
Se determinada opção não estiver habilitada, o arquivo não apresentará aquele tipo de registro.
Portanto, o primeiro passo não é simplesmente abrir o arquivo.
É verificar:
o que o Firewall está configurado para registrar?
Por que o log do Firewall é tão útil?
Imagine um programa tentando acessar:
192.168.1.50
pela porta:
9100
Você executa:
Test-NetConnection 192.168.1.50 -Port 9100
e recebe:
TcpTestSucceeded : False
Isso confirma uma falha no teste TCP.
Mas não responde:
onde ocorreu a falha?
Pode ser:
- Firewall do computador;
- Firewall do equipamento remoto;
- equipamento desligado;
- serviço parado;
- porta incorreta;
- roteador;
- VLAN;
- VPN;
- rota;
- ACL;
- outro equipamento intermediário.
Agora imagine que, exatamente no horário do teste, encontramos no log do Firewall uma entrada correspondente ao endereço, protocolo e porta investigados com uma ação de descarte.
A investigação muda completamente.
Passamos a ter uma evidência registrada pelo próprio Firewall.
DROP e ALLOW: dois termos importantes
Ao analisar logs do Firewall, dois termos aparecem com frequência.
DROP
Indica tráfego descartado.
Em um troubleshooting, é natural que essa informação chame nossa atenção.
Mas:
DROP não significa automaticamente que encontramos a causa do problema.
Precisamos verificar se aquele registro corresponde realmente ao tráfego investigado.
ALLOW
Indica tráfego permitido registrado.
Esse registro também pode ser extremamente útil.
Se encontramos uma comunicação correspondente ao teste marcada como permitida, podemos direcionar a investigação para outras etapas do caminho.
Um DROP isolado não prova nada
Um computador conectado a uma rede pode receber vários pacotes que não possuem qualquer relação com o problema investigado.
Por isso, nunca procure apenas pela palavra:
DROP
e conclua:
“Achei o problema.”
Precisamos correlacionar pelo menos:
horário
protocolo
IP de origem
IP de destino
porta de origem
porta de destino
Quanto mais características coincidirem com nosso teste, maior será a utilidade daquela entrada.
Primeiro descubra qual perfil de rede está ativo
Antes de configurar os logs, verifique o perfil atual.
Abra PowerShell e execute:
Get-NetConnectionProfile
Observe:
NetworkCategory
Podemos encontrar valores relacionados a:
Public
Private
ou contexto de domínio.
Isso importa porque o Firewall trabalha com perfis diferentes.
E as configurações de logging também podem ser administradas por perfil.
Veja a configuração dos perfis do Firewall
Execute:
Get-NetFirewallProfile
Podemos selecionar informações relacionadas ao logging:
Get-NetFirewallProfile | Format-List Name,Enabled,LogFileName,LogMaxSizeKilobytes,LogAllowed,LogBlocked
Agora temos uma visão muito mais interessante.
Podemos verificar, por perfil:
Name
qual perfil estamos analisando.
Enabled
se o Firewall está habilitado.
LogFileName
arquivo utilizado.
LogMaxSizeKilobytes
tamanho máximo configurado.
LogAllowed
registro de tráfego permitido.
LogBlocked
registro de tráfego bloqueado.
Isso nos permite descobrir rapidamente como o logging está configurado.
Não presuma que todos os perfis utilizam exatamente o mesmo log
Historicamente é muito comum encontrar todos os perfis utilizando:
pfirewall.log
Mas podemos configurar arquivos diferentes.
Isso pode ser útil principalmente quando queremos separar:
Domínio
Privado
Público
Em ambientes com muito tráfego, essa separação facilita bastante a análise.
A recomendação atual da Microsoft para separar os logs
Uma estratégia recomendada pela Microsoft é utilizar arquivos diferentes para cada perfil.
Por exemplo:
pfirewall_Domain.log
pfirewall_Private.log
pfirewall_Public.log
Assim fica mais fácil identificar de qual contexto de rede determinado registro veio.
Essa abordagem também evita concentrar toda a investigação em um único arquivo.
Como configurar os logs pela interface gráfica
Pressione:
Windows + R
Digite:
wf.msc
Pressione Enter.
Será aberto:
Firewall do Windows Defender com Segurança Avançada
No painel principal, abra as propriedades do Firewall.
Encontraremos guias correspondentes aos perfis, como:
Perfil de Domínio
Perfil Privado
Perfil Público
Dentro de cada perfil existe uma área relacionada a:
Registro em log
e uma opção de personalização.
É ali que podemos definir:
- nome/local do arquivo;
- tamanho máximo;
- registro de pacotes descartados;
- registro de conexões bem-sucedidas.
Registrar pacotes descartados
Para troubleshooting, uma das configurações mais importantes é:
Registrar pacotes descartados
Quando habilitada, o Firewall passa a registrar tráfego descartado correspondente ao recurso de logging.
Isso nos permite procurar eventos relacionados a uma conexão que falhou.
Registrar conexões bem-sucedidas
Outra opção é:
Registrar conexões bem-sucedidas
Ela também possui enorme valor diagnóstico.
Imagine:
Aplicativo não funciona.
Você acredita que o Firewall está impedindo a comunicação.
Mas o log mostra a conexão correspondente sendo permitida.
Nesse caso, precisamos considerar seriamente outras hipóteses.
Por exemplo:
- servidor recusando conexão;
- problema da aplicação;
- autenticação;
- protocolo;
- TLS;
- resposta do servidor;
- comunicação posterior em outra porta.
Ou seja:
registrar ALLOW pode ser tão útil quanto registrar DROP.
Por que registrar apenas DROP pode não ser suficiente?
Suponha que uma conexão falhe.
Você procura no log.
Não encontra DROP.
Conclusão precipitada:
“Então não é o Firewall.”
Ainda precisamos considerar:
- logging estava realmente habilitado?
- perfil correto estava sendo registrado?
- arquivo correto foi consultado?
- registro foi sobrescrito?
- horário está correto?
- estamos procurando a conexão certa?
- o tipo de tráfego aparece nesse registro?
Por isso, configure o ambiente antes de realizar o teste.
Descubra a configuração atual pelo netsh
Outra ferramenta muito útil é:
netsh advfirewall
Podemos consultar a configuração dos perfis.
Execute:
netsh advfirewall show allprofiles
Isso mostra diversas configurações.
Para investigar especificamente o logging, podemos consultar informações dos perfis e observar:
- arquivo;
- tamanho;
- conexões permitidas;
- conexões descartadas.
Como ativar o registro de conexões descartadas
Em um Prompt de Comando executado com privilégios administrativos, podemos configurar:
netsh advfirewall set allprofiles logging droppedconnections enable
Isso habilita o registro de conexões descartadas nos perfis abrangidos pelo comando.
Como ativar conexões permitidas
Podemos utilizar:
netsh advfirewall set allprofiles logging allowedconnections enable
Agora também solicitamos o registro das conexões permitidas.
Esses comandos são especialmente úteis em troubleshooting porque podemos configurar rapidamente os perfis.
allprofiles ou currentprofile?
Essa diferença merece atenção.
Quando utilizamos:
allprofiles
estamos aplicando a configuração aos perfis do Firewall.
Também existe:
currentprofile
Além disso, podemos trabalhar especificamente com:
domainprofile
privateprofile
publicprofile
Isso permite uma configuração muito mais controlada.
Não altere todos os perfis sem necessidade
Em um computador doméstico, utilizar allprofiles pode ser conveniente durante uma investigação controlada.
Mas em ambientes administrados ou corporativos, não devemos alterar configurações indiscriminadamente.
Primeiro descubra:
qual perfil está ativo
e:
qual política deve ser respeitada.
Configurando somente o perfil atual
Podemos utilizar comandos como:
netsh advfirewall set currentprofile logging droppedconnections enable
e:
netsh advfirewall set currentprofile logging allowedconnections enable
Isso restringe a alteração ao perfil atual.
Ainda assim, registre o estado original antes da mudança.
Verificando a configuração depois da alteração
Depois de habilitar os logs, não presuma que tudo funcionou.
Consulte novamente as configurações.
Use:
Get-NetFirewallProfile
ou:
netsh advfirewall show allprofiles
Confirme:
logging de bloqueados: habilitado
logging de permitidos: habilitado
arquivo: correto
perfil: correto
Depois disso podemos reproduzir o problema.
O tamanho do log importa
Imagine um computador muito ativo.
Se o arquivo de log for pequeno e estivermos registrando muitas conexões, ele pode atingir rapidamente seu limite.
Quando isso acontece, registros antigos podem ser substituídos.
Você realiza um teste pela manhã.
Vai investigar à tarde.
A entrada que precisava já desapareceu.
Por isso o tamanho do arquivo faz diferença.
A recomendação de 20 MB
A documentação atual da Microsoft recomenda considerar pelo menos:
20480 KB
ou aproximadamente:
20 MB
para reduzir o risco de o log encher rapidamente durante a coleta.
O tamanho máximo aceito pela configuração documentada chega a:
32767 KB
aproximadamente:
32 MB
A quantidade ideal depende do ambiente e do volume de tráfego.
Como alterar o tamanho máximo pelo netsh
Podemos utilizar:
netsh advfirewall set currentprofile logging maxfilesize 20480
Nesse exemplo configuramos:
20480 KB
para o perfil atual.
Antes de aplicar isso indiscriminadamente, avalie o ambiente e a política existente.
Onde está o arquivo?
O caminho padrão normalmente é:
%windir%\system32\logfiles\firewall\pfirewall.log
Podemos abrir a pasta:
C:\Windows\System32\LogFiles\Firewall
e procurar o arquivo configurado.
Mas existe uma abordagem melhor:
consulte a configuração.
Use:
Get-NetFirewallProfile
e observe:
LogFileName
Assim você não depende de suposições.
Podemos alterar o caminho do log?
Sim.
O Firewall permite definir outro nome e local.
Por exemplo, podemos organizar logs diferentes para cada perfil.
Mas existe um detalhe importante:
o serviço precisa ter permissão para gravar no local escolhido.
Escolher uma pasta arbitrária sem considerar permissões pode resultar em um log que simplesmente não é atualizado.
O pfirewall.log não atualiza: o que verificar?
Se o arquivo existe, mas não recebe novas linhas, investigue:
Logging está realmente habilitado?
Confirme:
LogAllowed
e:
LogBlocked
Você está olhando o perfil correto?
Verifique:
Get-NetConnectionProfile
Está olhando o arquivo correto?
Verifique:
LogFileName
Existe tráfego correspondente?
Reproduza uma comunicação conhecida.
O serviço consegue gravar no local?
Verifique permissões do diretório configurado.
Existe política administrativa?
Em computadores gerenciados, políticas podem determinar essas configurações.
Não use um log antigo para diagnosticar um problema atual
Sempre observe a data e o horário das entradas.
Imagine que você encontrou:
DROP TCP
para determinada porta.
Mas o registro é de ontem.
O problema que estamos testando aconteceu hoje.
Esse evento pode não ter qualquer relação.
Por isso precisamos trabalhar com uma janela temporal controlada.
Crie uma janela de teste
Uma metodologia simples:
10:31:00 — iniciar diagnóstico
10:31:15 — executar tentativa
10:31:30 — repetir
10:32:00 — encerrar teste
Agora sabemos que devemos procurar registros aproximadamente entre:
10:31 e 10:32
Isso reduz drasticamente o ruído.
Use um teste conhecido
Imagine que estamos investigando:
192.168.1.50
porta:
9100
Execute:
Test-NetConnection 192.168.1.50 -Port 9100
Anote o horário.
Depois abra o log.
Procure registros relacionados a:
192.168.1.50
e:
9100
Agora temos:
destino conhecido
porta conhecida
protocolo conhecido
horário conhecido
Esse é um diagnóstico muito mais confiável.
Não procure somente pelo nome do programa
O pfirewall.log é essencialmente um log de rede.
Seu valor está em informações como:
protocolo
endereços
portas
ação
Por isso, primeiro transforme o problema do programa em uma descrição de rede.
Em vez de:
“Programa X não conecta.”
pense:
“Programa X tenta uma conexão TCP do computador 192.168.1.20 para 192.168.1.50 na porta 9100 por volta das 10:31.”
Agora sabemos exatamente o que procurar.
A diferença entre problema de programa e problema de fluxo
Esse é um conceito extremamente importante.
Para o usuário:
Programa X não funciona.
Para o diagnóstico de firewall:
Precisamos identificar o fluxo de rede utilizado pelo Programa X.
Esse fluxo possui:
- origem;
- destino;
- protocolo;
- porta;
- direção;
- horário.
O log trabalha muito melhor quando pensamos dessa forma.
O cabeçalho do pfirewall.log
Ao abrir o arquivo, podemos encontrar linhas de cabeçalho iniciadas por:
#
Essas linhas ajudam a identificar:
- versão;
- software;
- horário;
- campos registrados.
Uma das mais importantes é a definição:
#Fields:
Ela informa a ordem das colunas utilizadas nas linhas seguintes.
Não ignore o cabeçalho.
Ele funciona como um mapa para interpretar cada registro.
Os campos podem incluir informações essenciais
Dependendo da configuração/formato, podemos encontrar campos relacionados a:
date
time
action
protocol
src-ip
dst-ip
src-port
dst-port
Esses nomes já revelam boa parte do que precisamos.
date e time
Representam data e horário do registro.
São fundamentais para correlacionar a entrada com nosso teste.
action
Mostra a ação registrada.
Entre as mais importantes para nossa investigação:
ALLOW
e:
DROP
protocol
Indica o protocolo.
Podemos encontrar, por exemplo:
TCP
UDP
ou outros valores conforme o tráfego.
src-ip
Significa:
source IP
ou:
IP de origem
É o endereço de onde o tráfego partiu.
dst-ip
Significa:
destination IP
ou:
IP de destino
É o endereço para o qual o tráfego estava indo.
src-port
É a:
porta de origem
Em conexões iniciadas por um cliente, muitas vezes será uma porta dinâmica.
dst-port
É a:
porta de destino
Frequentemente será a porta do serviço que estamos investigando.
Por exemplo:
443
445
3389
9100
ou outra porta utilizada pela aplicação.
Não interprete o número isoladamente.
Correlacione com protocolo, endereço e contexto.
Exemplo didático de uma linha DROP
Imagine uma entrada simplificada:
2026-09-21 10:31:22 DROP TCP 192.168.1.30 192.168.1.20 52144 5000
Vamos interpretar.
Data:
21/09/2026
Horário:
10:31:22
Ação:
DROP
Protocolo:
TCP
Origem:
192.168.1.30
Destino:
192.168.1.20
Porta de origem:
52144
Porta de destino:
5000
Agora imagine que exatamente às 10:31 fizemos um teste do computador:
192.168.1.30
para:
192.168.1.20:5000
A correlação torna-se extremamente relevante.
Agora temos uma evidência, não apenas uma suspeita
Antes:
“Talvez o Firewall esteja bloqueando.”
Depois do registro correspondente:
“O Firewall registrou um descarte compatível com o fluxo que acabamos de testar.”
Essa diferença é enorme.
Ainda precisamos descobrir:
qual política ou regra levou ao descarte?
Mas já sabemos que estamos investigando o componente certo.
E se aparecer ALLOW?
Imagine a mesma tentativa:
192.168.1.30 → 192.168.1.20:5000
Mas encontramos:
ALLOW TCP
correspondente.
Isso indica que o Firewall registrou aquela comunicação como permitida.
Se o aplicativo continua falhando, devemos ampliar a investigação.
Talvez:
- o serviço não responda corretamente;
- exista outra conexão posterior;
- a aplicação utilize outra porta;
- a autenticação falhe;
- outro dispositivo bloqueie a comunicação.
O log ajuda justamente a parar de culpar o componente errado.
Como interpretar o pfirewall.log e encontrar conexões bloqueadas
Na primeira parte, configuramos o Firewall do Windows para registrar informações importantes sobre o tráfego.
Vimos como verificar:
LogFileName
LogMaxSizeKilobytes
LogAllowed
LogBlocked
Também utilizamos:
Get-NetFirewallProfile
e:
netsh advfirewall
Agora chegamos à parte mais interessante:
como transformar milhares de linhas do pfirewall.log em uma resposta útil?
Abrir o arquivo e procurar visualmente por DROP funciona em um log pequeno.
Em um computador com muito tráfego, porém, podemos encontrar centenas ou milhares de registros.
Precisamos aprender a filtrar.
Primeiro: descubra o arquivo que realmente está sendo utilizado
Antes de analisar qualquer coisa, execute:
Get-NetFirewallProfile | Select-Object Name,Enabled,LogFileName,LogAllowed,LogBlocked
Observe principalmente:
LogFileName
Não presuma que o arquivo esteja necessariamente no caminho padrão.
Se os perfis estiverem configurados com arquivos separados, podemos encontrar caminhos diferentes.
O objetivo é simples:
analise o arquivo que o perfil realmente utiliza.
Confirme também o perfil de rede
Execute:
Get-NetConnectionProfile
Observe:
NetworkCategory
Se a conexão está utilizando:
Private
comece verificando a configuração correspondente ao perfil Privado.
Se está:
Public
analise o perfil Público.
Em ambientes corporativos também pode existir o contexto de domínio.
Abra o log com um editor de texto
O pfirewall.log é um arquivo de texto.
Podemos abri-lo com um editor apropriado.
Mas, dependendo do tamanho, pesquisar manualmente não será eficiente.
Para entender sua estrutura, comece observando as primeiras linhas.
Você poderá encontrar algo semelhante a:
#Version:
#Software:
#Time Format:
#Fields:
A linha mais importante para nossa interpretação é:
#Fields:
Ela informa a ordem dos campos das entradas.
Não interprete o log sem olhar #Fields
Esse cuidado é importante.
Um exemplo de cabeçalho pode conter campos como:
date
time
action
protocol
src-ip
dst-ip
src-port
dst-port
e outros.
A ordem deve ser interpretada conforme o cabeçalho efetivamente existente no arquivo.
Portanto, não crie uma regra mental de que:
“a quinta coluna sempre significa isso.”
Consulte:
#Fields:
Entendendo os campos fundamentais
Vamos analisar os principais campos utilizados no troubleshooting.
date
Data em que o evento foi registrado.
time
Horário do registro.
action
Ação relacionada ao tráfego.
Para nosso diagnóstico, dois valores são especialmente importantes:
ALLOW
DROP
protocol
Protocolo utilizado.
Exemplos:
TCP
UDP
ICMP
src-ip
Endereço IP de origem.
dst-ip
Endereço IP de destino.
src-port
Porta de origem.
dst-port
Porta de destino.
Dependendo do registro, também encontraremos campos adicionais.
Origem e destino precisam ser interpretados pela direção da comunicação
Imagine:
PC A:
192.168.1.20
PC B:
192.168.1.30
O PC B tenta acessar um serviço existente no PC A.
No tráfego chegando ao PC A:
src-ip
pode ser:
192.168.1.30
e:
dst-ip
pode ser:
192.168.1.20
Isso significa:
origem → destino
ou:
192.168.1.30 → 192.168.1.20
Parece simples, mas essa leitura evita muita confusão.
Porta de origem e porta de destino também possuem funções diferentes
Imagine uma conexão TCP iniciada por um cliente.
O cliente pode utilizar uma porta dinâmica, por exemplo:
53182
para acessar um servidor na porta:
443
Teríamos conceitualmente:
53182 → 443
A porta:
53182
é a porta de origem daquela comunicação.
A porta:
443
é a porta de destino.
Para investigar um serviço, normalmente a porta de destino será especialmente interessante.
Exemplo prático: serviço TCP 5000
Imagine:
Servidor:
192.168.1.20
Cliente:
192.168.1.30
Serviço:
TCP 5000
Às:
14:05:12
o cliente tenta conectar.
Encontramos no log um registro correspondente a:
DROP TCP 192.168.1.30 192.168.1.20 53210 5000
Temos:
ação: DROP
protocolo: TCP
origem: 192.168.1.30
destino: 192.168.1.20
porta de origem: 53210
porta de destino: 5000
Agora compare com nosso teste.
Se tudo coincide, temos uma evidência extremamente relevante.
O horário precisa coincidir
Imagine que encontramos exatamente os mesmos IPs e porta.
Mas a entrada aconteceu:
quatro horas antes.
Talvez não tenha qualquer relação com nosso teste.
Por isso, antes de reproduzir o problema, registre o horário.
Por exemplo:
14:05:00 — início
14:05:12 — tentativa 1
14:05:20 — tentativa 2
14:05:40 — fim
Agora podemos restringir nossa análise.
Faça duas ou três tentativas controladas
Esse truque ajuda bastante.
Em vez de executar apenas uma tentativa, faça três com alguns segundos de intervalo.
Por exemplo:
14:05:12
14:05:20
14:05:28
Depois procure um padrão semelhante no log.
Três registros correspondentes nos mesmos intervalos fortalecem muito a correlação.
Test-NetConnection ajuda a produzir tráfego controlado
Para TCP:
Test-NetConnection 192.168.1.20 -Port 5000
Execute.
Espere alguns segundos.
Execute novamente.
Agora sabemos exatamente:
destino
porta
protocolo
e aproximadamente:
horário
Isso torna a pesquisa no log muito mais eficiente.
Como procurar DROP com PowerShell
Podemos utilizar:
Select-String
Exemplo:
Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern "DROP"
O PowerShell procura linhas contendo:
DROP
Isso já reduz bastante o volume.
Mas ainda pode retornar muitos resultados.
Precisamos ser mais específicos.
Procurando um endereço IP específico
Imagine que estamos investigando:
192.168.1.30
Podemos executar:
Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern "192.168.1.30"
Agora veremos linhas que contêm esse endereço.
Mas ainda não sabemos se ele aparece como origem ou destino.
Por isso, interprete os campos.
Procurando uma porta específica
Podemos procurar:
5000
Exemplo:
Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern "5000"
Porém existe uma limitação.
O número 5000 pode aparecer em outra posição ou contexto.
Uma busca textual simples ajuda, mas não substitui a interpretação da linha.
Combine informações
Uma estratégia simples é procurar o IP e depois examinar apenas as linhas relevantes.
Outra possibilidade:
Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern "DROP.*192\.168\.1\.30"
Essa busca procura uma sequência em que DROP apareça antes do endereço especificado.
Mas expressões regulares precisam ser usadas com cuidado.
Os pontos do endereço foram escapados:
\.
porque, em expressões regulares, um ponto possui significado especial.
Podemos encadear filtros
Outra forma:
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" | Select-String "DROP" | Select-String "192.168.1.30"
Agora estamos procurando linhas que contenham:
DROP
e:
192.168.1.30
Podemos acrescentar:
| Select-String "5000"
Assim reduzimos ainda mais os resultados.
Exemplo completo de filtro simples
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" | Select-String "DROP" | Select-String "192.168.1.30" | Select-String "5000"
Esse comando pode ajudar a localizar entradas relacionadas ao nosso teste.
Mas existe uma ressalva:
ele continua sendo um filtro textual.
Precisamos abrir a linha encontrada e confirmar se:
5000
é realmente a porta que queremos.
Get-Content -Tail é excelente para troubleshooting
Em vez de carregar todo o arquivo, podemos observar somente as últimas linhas.
Execute:
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Tail 50
Isso mostra as últimas 50 linhas.
Podemos aumentar:
-Tail 100
ou:
-Tail 200
Isso é muito útil quando acabamos de reproduzir o problema.
Acompanhe o log praticamente em tempo real
PowerShell permite:
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Wait
O comando continua aguardando novas linhas adicionadas ao arquivo.
Isso é extremamente interessante durante troubleshooting.
Podemos deixar uma janela do PowerShell acompanhando o log e, em outra janela ou computador, reproduzir a conexão.
Quando novos registros aparecem, conseguimos observar o comportamento.
Para interromper:
Ctrl + C
Combine -Tail e -Wait
Uma combinação muito útil:
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Tail 20 -Wait
Primeiro vemos as últimas 20 linhas.
Depois o PowerShell continua aguardando novas entradas.
Isso evita despejar todo o arquivo na tela.
Filtrando somente DROP enquanto acompanha o arquivo
Podemos combinar:
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Wait | Select-String "DROP"
Agora novas linhas que contenham DROP ficam muito mais fáceis de observar.
Para um teste específico, ainda podemos adicionar outro filtro.
Exemplo: acompanhar DROP de determinado IP
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Wait | Select-String "DROP" | Select-String "192.168.1.30"
Agora podemos reproduzir a comunicação a partir daquele equipamento.
Se surgirem entradas compatíveis, temos um caminho claro para investigação.
E se nada aparecer?
Isso também é informação.
Mas não conclua imediatamente:
“O Firewall não bloqueou.”
Primeiro confirme:
LogBlockedestá habilitado?- O perfil correto está ativo?
- Estamos lendo o arquivo correto?
- O arquivo está sendo atualizado?
- O teste realmente gerou tráfego?
- O horário está correto?
- Existe alguma política diferente aplicada?
Somente depois disso devemos interpretar a ausência de registros.
Como saber se o arquivo está recebendo novas entradas?
Execute:
Get-Item "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" | Select-Object LastWriteTime,Length
Observe:
LastWriteTime
e:
Length
Reproduza tráfego.
Execute novamente.
Se o arquivo está configurado para registrar aquele tipo de evento e recebe novos registros, essas propriedades podem mudar.
O arquivo existe, mas o tamanho não muda
Investigue:
- logging desabilitado;
- perfil incorreto;
- caminho diferente;
- falta de tráfego correspondente;
- permissões;
- política administrativa.
Não recrie o arquivo manualmente sem antes entender por que ele não está sendo atualizado.
ALLOW também merece filtros
Se ativamos o registro de conexões permitidas:
Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern "ALLOW"
Podemos combinar com endereço:
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" | Select-String "ALLOW" | Select-String "192.168.1.50"
Ou com uma porta.
Por que ALLOW pode ser ainda mais interessante do que DROP?
Imagine um software dizendo:
Não foi possível conectar ao servidor.
Você acredita que o Firewall está bloqueando.
Executa o teste.
O log mostra uma entrada compatível:
ALLOW TCP
Isso muda nossa hipótese.
O Firewall permitiu pelo menos aquele fluxo registrado.
Então precisamos perguntar:
o programa faz outra conexão depois dessa?
Talvez ele:
- conecte na porta 443;
- receba uma configuração;
- tente abrir outra conexão na porta 8443;
- essa segunda conexão falhe.
Se olharmos apenas para a primeira, concluiremos erroneamente que tudo deveria funcionar.
Aplicativos modernos podem utilizar várias conexões
Um programa pode utilizar simultaneamente:
- HTTPS;
- WebSocket;
- serviços de descoberta;
- DNS;
- autenticação;
- atualização;
- APIs;
- servidores diferentes.
Portanto:
uma entrada ALLOW não significa necessariamente que todas as comunicações necessárias foram permitidas.
Precisamos descobrir o fluxo completo.
Exemplo: primeira conexão permitida e segunda bloqueada
Imagine:
ALLOW TCP 192.168.1.20 → 203.0.113.10:443
Depois:
DROP TCP 192.168.1.20 → 203.0.113.20:8443
O aplicativo pode iniciar corretamente sua primeira comunicação e falhar na segunda.
Para o usuário:
“O programa não conecta.”
Para o técnico:
“O primeiro fluxo foi permitido, mas existe outro fluxo que precisa ser investigado.”
DNS pode aparecer como parte da investigação
Antes de conectar a:
servidor.exemplo
o programa normalmente precisa descobrir o endereço IP correspondente.
Isso envolve DNS.
Se a resolução falhar, talvez a conexão TCP que você esperava nem seja iniciada.
Por isso, quando nenhum tráfego esperado aparece, investigue também:
Resolve-DnsName
Exemplo:
Resolve-DnsName servidor.exemplo
Se o nome não resolve, o problema pode ocorrer antes da conexão que você estava procurando no log.
UDP exige outra forma de pensar
Test-NetConnection -Port é particularmente útil para testes TCP.
UDP não estabelece uma conexão da mesma forma que TCP.
Portanto, não devemos interpretar UDP usando exatamente a mesma lógica de handshake do TCP.
Para programas que utilizam UDP, o log do Firewall pode ser ainda mais valioso porque ajuda a observar o fluxo sem depender de uma “conexão estabelecida” no mesmo sentido do TCP.
Exemplo clássico: descoberta de dispositivos
Aplicativos que procuram:
- impressoras;
- computadores;
- dispositivos multimídia;
- equipamentos IoT;
podem utilizar broadcast ou multicast e protocolos de descoberta.
Nesse cenário, o programa pode:
acessar a Internet normalmente
mas:
não encontrar nenhum equipamento local.
O problema pode envolver:
- perfil Público;
- regras de descoberta;
- multicast;
- broadcast;
- isolamento Wi-Fi;
- Firewall;
- serviço de descoberta.
Isso será particularmente importante no próximo post sobre impressoras.
DROP de entrada: como pensar
Imagine:
src-ip = 192.168.1.30
dst-ip = 192.168.1.20
O log está no computador:
192.168.1.20
Se encontramos um DROP compatível com uma tentativa iniciada pelo computador 192.168.1.30, estamos olhando para um possível bloqueio de tráfego chegando ao computador analisado.
Agora devemos investigar:
Regras de Entrada
no:
wf.msc
DROP relacionado a saída: como pensar
Se o computador local tenta iniciar comunicação para outro endereço e encontramos um registro compatível com o fluxo descartado, precisamos considerar regras e políticas relacionadas ao tráfego de saída.
Nesse cenário, investigamos:
Regras de Saída
e as políticas aplicáveis.
O ponto central é sempre:
qual era a direção real do fluxo?
Relacione o log com Get-NetFirewallRule
Depois de identificar um fluxo problemático, volte às regras.
Imagine:
protocolo: TCP
destino: 192.168.1.20
porta: 5000
perfil: Privado
Agora procure regras relevantes:
Get-NetFirewallRule -Enabled True
Depois examine:
Get-NetFirewallPortFilter
Get-NetFirewallApplicationFilter
Get-NetFirewallAddressFilter
Nosso objetivo agora é descobrir:
qual regra corresponde às características observadas no log?
Comece pelas regras Block
Uma abordagem prática:
Get-NetFirewallRule -Enabled True -Action Block
Depois analise regras compatíveis com:
- direção;
- perfil;
- programa;
- protocolo;
- porta;
- endereço.
Não escolha uma regra apenas porque o nome parece relacionado.
Confira seus filtros.
O log mostra o fluxo; as regras explicam a política
Essa frase resume bem o diagnóstico.
Log:
mostra o que aconteceu com determinado tráfego registrado.
Regra:
ajuda a explicar por que determinada política foi aplicada.
Usar apenas um dos dois pode deixar lacunas.
Combinar ambos é muito mais poderoso.
Exemplo de diagnóstico completo
Imagine o cenário:
PC servidor: 192.168.1.20
PC cliente: 192.168.1.30
Serviço: TCP 5000
Primeiro, no servidor:
Get-NetTCPConnection -LocalPort 5000 -State Listen
Encontramos o serviço ouvindo.
Depois, no cliente:
Test-NetConnection 192.168.1.20 -Port 5000
Resultado:
TcpTestSucceeded : False
No servidor acompanhamos:
pfirewall.log
No horário do teste encontramos um:
DROP
compatível com:
192.168.1.30 → 192.168.1.20:5000
Agora verificamos:
Get-NetConnectionProfile
O servidor está:
Public
Abrimos a regra do aplicativo.
Ela está habilitada apenas para:
Private
Temos agora uma cadeia coerente de evidências.
O problema não é simplesmente:
“Firewall bloqueando.”
O diagnóstico é:
o tráfego necessário chega ao servidor, é descartado no contexto atual e a regra esperada não corresponde ao perfil atualmente utilizado.
Esse é um diagnóstico técnico muito mais preciso.
E se não houver DROP?
Imagine o mesmo cenário.
O serviço está ouvindo.
O teste falha.
Mas nenhum DROP correspondente aparece no log devidamente configurado.
Agora precisamos investigar outros pontos.
Por exemplo:
- firewall no outro equipamento;
- roteador;
- VLAN;
- isolamento;
- rota;
- endereço incorreto;
- interface;
- VPN.
A ausência de um registro compatível não deve ser usada isoladamente como prova absoluta, mas ajuda a direcionar o troubleshooting quando a coleta foi configurada e validada corretamente.
O problema pode acontecer antes do pacote chegar
Se um roteador, switch gerenciável, ACL ou firewall intermediário descarta o tráfego antes de ele alcançar o computador, o Firewall do Windows não poderá registrar um pacote que nunca recebeu.
Esse conceito é fundamental.
Por isso:
nenhum DROP no pfirewall.log não significa automaticamente que a rede está funcionando.
Pode significar que o tráfego nem chegou ao Windows.
Compare os dois lados quando possível
Quando temos acesso aos dois computadores, o diagnóstico melhora muito.
No computador A:
observe a tentativa de saída.
No computador B:
observe a chegada.
Podemos comparar:
A enviou?
B recebeu?
B descartou?
Essa metodologia ajuda a localizar o ponto em que o fluxo desaparece.
Quando o log não é suficiente, use captura de pacotes
O pfirewall.log responde perguntas importantes sobre o Firewall.
Mas ele não substitui uma captura completa de tráfego.
Quando precisamos analisar:
- handshake TCP;
- retransmissões;
- flags;
- respostas;
- ICMP;
- comportamento detalhado dos pacotes;
podemos recorrer a ferramentas de captura.
No próprio Windows, ferramentas como:
pktmon
podem ajudar.
Esse assunto merece um diagnóstico próprio porque captura de pacotes e log de firewall são ferramentas diferentes.
pfirewall.log e Pktmon não são a mesma coisa
pfirewall.log
Ajuda a observar decisões registradas pelo Firewall.
Pktmon
Ajuda na observação e captura de tráfego em níveis mais detalhados da pilha de rede.
Uma ferramenta não substitui completamente a outra.
Em alguns problemas complexos, utilizamos ambas.
Crie uma tabela de diagnóstico
Para investigações mais difíceis, registre:
Horário: 14:05:12
Origem: 192.168.1.30
Destino: 192.168.1.20
Protocolo: TCP
Porta: 5000
Resultado do Test-NetConnection: False
Log: DROP
Perfil: Public
Regra esperada: Private
Serviço ouvindo: Sim
Essa pequena tabela transforma dezenas de informações em uma linha de raciocínio clara.
Não altere a regra antes de capturar a evidência
Se possível, reproduza primeiro o problema no estado original.
Capture:
- horário;
- resultado;
- log;
- perfil;
- regra.
Somente depois faça a alteração.
Assim podemos comparar:
antes
e:
depois
Isso é troubleshooting de verdade.
Compare antes e depois
Antes:
DROP TCP
Depois da correção:
ALLOW TCP
E:
TcpTestSucceeded : True
Essa combinação cria uma evidência muito forte de que a alteração afetou exatamente o fluxo investigado.
Não deixe logging excessivo habilitado sem necessidade
Registrar conexões permitidas pode gerar bastante informação em computadores movimentados.
Depois do troubleshooting, avalie se existe necessidade operacional de manter o nível de logging utilizado.
Em ambientes corporativos, siga a política definida pelo administrador.
O objetivo não é simplesmente acumular logs.
É coletar informação útil.
Preserve o arquivo quando o problema for intermitente
Problemas que acontecem apenas uma vez por dia podem ser difíceis de reproduzir.
Nesses casos, o tamanho máximo e a retenção tornam-se ainda mais importantes.
Se o log for sobrescrito antes de você analisá-lo, a evidência desaparece.
Considere copiar o arquivo para análise quando o incidente ocorrer, respeitando as políticas do ambiente.
Checklist de análise do pfirewall.log
Antes de concluir que encontrou o problema, responda:
O logging estava habilitado antes do teste?
Estou analisando o perfil correto?
Estou lendo o arquivo correto?
O horário corresponde?
O IP de origem corresponde?
O IP de destino corresponde?
O protocolo corresponde?
A porta corresponde?
A ação é DROP ou ALLOW?
O evento se repetiu quando repeti o teste?
Existe uma regra compatível com esse fluxo?
O serviço estava realmente em execução?
Existe algum equipamento de rede no caminho?
Quanto mais respostas confirmadas, maior a confiança no diagnóstico.
Casos práticos: usando o pfirewall.log para descobrir onde a conexão está falhando
Nas duas primeiras partes deste guia aprendemos a configurar e interpretar o log do Firewall do Windows.
Já sabemos verificar:
LogFileName
LogMaxSizeKilobytes
LogAllowed
LogBlocked
Também utilizamos:
Get-NetFirewallProfile
Get-NetConnectionProfile
netsh advfirewall
Get-Content
Select-String
Test-NetConnection
e:
Get-NetFirewallRule
Agora vamos juntar essas ferramentas em situações reais de troubleshooting.
A pergunta deixa de ser:
“Será que o Firewall está bloqueando?”
e passa a ser:
“Existe uma entrada registrada pelo Firewall que corresponde exatamente ao fluxo que falhou?”
Essa mudança de abordagem reduz bastante as tentativas aleatórias.
Caso 1 — Programa acessa a Internet, mas não conecta a um servidor específico
Imagine um software que:
- abre normalmente;
- baixa atualizações;
- acessa alguns serviços;
- mas não consegue conectar a determinado servidor.
O usuário diz:
“A Internet funciona, então não pode ser rede.”
Essa conclusão não é válida.
A Internet funcionar demonstra apenas que algumas comunicações estão funcionando.
O programa pode precisar acessar:
servidor.exemplo
pela porta:
8443
enquanto o navegador utiliza principalmente outros destinos e serviços.
Precisamos investigar o fluxo específico.
Primeiro descubra o endereço do servidor
Podemos utilizar:
Resolve-DnsName servidor.exemplo
Isso ajuda a descobrir para qual endereço o nome está resolvendo.
Depois teste a porta TCP, quando apropriado:
Test-NetConnection servidor.exemplo -Port 8443
Se:
TcpTestSucceeded : False
temos uma falha na tentativa TCP.
Agora registre o horário.
Procure o destino no log
Com o logging corretamente configurado, podemos procurar o endereço relacionado:
Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern "ENDERECO-IP"
Depois procure:
DROP
e a porta.
Se encontramos um registro compatível com:
- horário;
- destino;
- protocolo;
- porta;
a hipótese de bloqueio local ganha evidência.
E se encontrarmos ALLOW?
Esse resultado também é importante.
Imagine que o log registra:
ALLOW TCP
para o servidor e porta que acabamos de testar.
Isso sugere que o Firewall permitiu aquele fluxo registrado.
Nesse caso, precisamos ampliar o diagnóstico.
Podemos investigar:
- resposta do servidor;
- autenticação;
- TLS;
- certificado;
- proxy;
- segunda conexão utilizada pelo aplicativo;
- serviço remoto;
- outro equipamento no caminho.
O log serve tanto para encontrar o Firewall quanto para deixar de culpá-lo indevidamente.
Caso 2 — Dois computadores estão na mesma rede, mas não se enxergam
Imagine:
PC A:
192.168.1.20
PC B:
192.168.1.30
Ambos navegam normalmente.
Mas o PC A não consegue acessar determinado serviço no PC B.
Primeiro confirme os endereços.
Use:
ipconfig
ou:
Get-NetIPConfiguration
Depois confira os perfis:
Get-NetConnectionProfile
Imagine que:
PC A:
Private
PC B:
Public
Isso já merece atenção.
Perfil Público pode mudar o comportamento esperado
Uma regra necessária pode estar habilitada somente para:
Private
Quando o computador utiliza:
Public
ela pode não corresponder ao contexto atual.
Isso é especialmente relevante para recursos de rede local.
Mas não transforme automaticamente a rede em Privada.
Primeiro determine se aquela rede realmente deve ser considerada confiável.
Produza uma tentativa controlada
Se existe um serviço TCP na porta:
5000
a partir do PC A:
Test-NetConnection 192.168.1.30 -Port 5000
No PC B, acompanhe:
pfirewall.log
Se encontramos:
DROP
correspondente a:
192.168.1.20 → 192.168.1.30:5000
no mesmo horário, temos uma excelente pista.
Agora abra:
wf.msc
e investigue:
Regras de Entrada
O serviço precisa estar ouvindo
No PC B:
Get-NetTCPConnection -LocalPort 5000 -State Listen
Se não houver nenhum processo ouvindo, o problema pode estar no próprio serviço.
Também podemos utilizar:
netstat -ano | findstr :5000
A pergunta é:
existe realmente um serviço aguardando conexões nessa porta?
Sem isso, abrir o Firewall não resolve.
Caso 3 — Existe regra Allow, mas o log mostra DROP
Esse cenário costuma confundir bastante.
O usuário abre:
wf.msc
encontra:
Programa X — Permitir
e conclui:
“O Firewall não poderia estar bloqueando.”
Mas o log registra:
DROP
compatível com a tentativa.
Como isso pode acontecer?
Precisamos investigar as condições da regra.
A regra Allow pode estar associada ao perfil errado
Exemplo:
Regra:
Allow
Perfil:
Private
Conexão atual:
Public
A regra existe.
Mas não corresponde ao perfil atual.
O executável pode ser diferente
Regra:
C:\Program Files\ProgramaX\ProgramaX.exe
Processo que realmente comunica:
C:\Program Files\ProgramaX\Service\ProgramaXService.exe
O nome comercial é o mesmo.
O executável é diferente.
Verifique com:
Get-NetFirewallApplicationFilter
A porta pode estar errada
Regra:
TCP 443
Aplicativo:
TCP 8443
A regra permite uma comunicação diferente daquela que falhou.
Verifique:
Get-NetFirewallPortFilter
O escopo pode não corresponder
Regra permite:
192.168.1.0/24
Mas o cliente está:
192.168.10.25
Verifique:
Get-NetFirewallAddressFilter
Pode existir uma regra explícita de bloqueio
Procure:
Get-NetFirewallRule -Enabled True -Action Block
Depois investigue as condições das regras relevantes.
Não conclua que uma regra Allow resolve tudo apenas porque está habilitada.
Caso 4 — Test-NetConnection funciona, mas o programa continua falhando
Imagine:
Test-NetConnection servidor.exemplo -Port 443
resultado:
TcpTestSucceeded : True
O log também mostra tráfego permitido.
Mas o programa ainda apresenta:
Falha ao conectar.
Isso é possível.
O teste demonstra conectividade TCP para aquele destino e porta.
Não demonstra que toda a lógica da aplicação funcionou.
A aplicação pode falhar depois da conexão
Depois de estabelecer TCP, ainda podem ocorrer problemas relacionados a:
- TLS;
- certificado;
- autenticação;
- API;
- credenciais;
- versão do protocolo;
- resposta do servidor;
- proxy;
- aplicação.
Nesse cenário, criar mais regras de Firewall pode não ajudar.
O programa também pode usar outra conexão
Imagine:
Etapa 1
Programa conecta:
servidor1:443
Resultado:
ALLOW
Etapa 2
Servidor informa outro endpoint.
Programa tenta:
servidor2:8443
Resultado:
DROP
Para o usuário existe apenas:
“Programa não funciona.”
Para o técnico existem dois fluxos completamente diferentes.
Por isso, durante o teste, observe o comportamento completo.
Caso 5 — Conexão funciona na rede Privada e falha na Pública
Esse comportamento é uma pista forte de perfil.
Execute:
Get-NetConnectionProfile
Depois analise as regras relevantes.
Uma regra pode estar habilitada somente para:
Private
Isso pode ser proposital.
O perfil Público existe justamente para contextos em que não queremos expor determinados serviços da mesma forma que em uma rede confiável.
Não resolva isso marcando qualquer rede como Privada
Se o notebook está em:
- hotel;
- aeroporto;
- escola;
- Wi-Fi compartilhado;
- rede desconhecida;
mudar para Privada apenas para fazer uma aplicação funcionar pode ampliar desnecessariamente a exposição.
A pergunta correta é:
o aplicativo realmente precisa aceitar essa comunicação nesse tipo de rede?
Caso 6 — Firewall registra muitos DROP que não têm relação com o problema
Você abre o log e encontra dezenas de:
DROP
Isso pode parecer assustador.
Mas redes produzem tráfego de vários tipos.
Nem todo pacote descartado representa:
- ataque;
- erro;
- problema;
- aplicativo bloqueado.
Precisamos correlacionar.
Use cinco critérios
Para considerar um registro relevante, compare:
1. Horário
Aconteceu durante nosso teste?
2. Origem
É o equipamento esperado?
3. Destino
É o computador ou servidor correto?
4. Protocolo
TCP, UDP ou outro esperado?
5. Porta
É a porta utilizada pela aplicação?
Quanto mais elementos coincidirem, maior a relevância.
Caso 7 — Nenhum registro aparece no pfirewall.log
Imagine:
Test-NetConnection falha.
Mas não encontramos:
DROP
nem:
ALLOW
correspondentes.
Antes de culpar outra parte da rede, valide o próprio logging.
Execute:
Get-NetFirewallProfile | Format-List Name,Enabled,LogFileName,LogAllowed,LogBlocked
Confirme:
- perfil;
- arquivo;
- logging;
- estado.
Depois confirme se está lendo o arquivo correto
Veja:
LogFileName
Não use automaticamente:
C:\Windows\System32\LogFiles\Firewall\pfirewall.log
se a configuração aponta para outro arquivo.
O pacote pode nunca ter chegado ao computador
Esse cenário é especialmente importante para tráfego de entrada.
Se um roteador, firewall central, ACL ou outro dispositivo descartou o pacote antes de ele chegar ao Windows, o Firewall local não poderá registrar aquilo que não recebeu.
Então podemos ter:
falha de conexão
e:
nenhum DROP correspondente no Firewall do Windows.
Isso direciona a investigação para outra camada.
Caso 8 — Impressora responde ao ping, mas não imprime
Agora chegamos ao cenário que fará a ligação com nosso próximo artigo.
Imagine:
Impressora:
192.168.1.50
Do computador:
ping 192.168.1.50
responde normalmente.
O usuário conclui:
“A rede está funcionando.”
Mas imprimir falha.
Isso é perfeitamente possível.
Ping não testa o protocolo de impressão
O ping normalmente testa comunicação ICMP.
A impressão pode utilizar outro protocolo e outra porta.
Dependendo da configuração, podemos ter:
- porta TCP/IP;
- RAW;
- LPR;
- WSD;
- mecanismos de descoberta;
- serviços auxiliares.
Portanto:
ping respondendo não significa que a comunicação necessária para imprimir está funcionando.
Teste a porta realmente utilizada
Se a impressora estiver configurada para RAW na porta TCP 9100, por exemplo:
Test-NetConnection 192.168.1.50 -Port 9100
Agora estamos testando algo muito mais próximo do fluxo de impressão.
Se:
TcpTestSucceeded : True
sabemos que a porta TCP testada respondeu.
Se:
False
precisamos investigar.
Mas cuidado: o Firewall do computador pode não ser o culpado
Se o computador está iniciando uma conexão para a impressora e não existe uma política de saída bloqueando esse fluxo, outras hipóteses podem ser mais prováveis.
Por exemplo:
- impressora não escutando na porta esperada;
- configuração da porta errada;
- endereço IP mudou;
- driver;
- spooler;
- roteador;
- isolamento Wi-Fi;
- impressora em outra VLAN.
É exatamente por isso que o log é útil.
Descoberta de impressoras é diferente de impressão direta
Uma impressora pode:
não aparecer automaticamente
mas funcionar perfeitamente quando adicionada manualmente por IP.
Isso indica que precisamos separar:
descoberta
de:
comunicação de impressão.
Mecanismos de descoberta podem depender de tráfego e serviços diferentes do envio efetivo do trabalho de impressão.
Esse será o próximo artigo do cluster
Nosso próximo guia será:
Firewall do Windows bloqueando impressora na rede: como descobrir qual porta ou regra está impedindo a comunicação?
Nele vamos aprofundar:
- impressora por IP;
- porta TCP/IP padrão;
- RAW;
- LPR;
- WSD;
- descoberta;
- perfil Público e Privado;
- regras de entrada;
- regras de saída;
- ping;
- Test-NetConnection;
- spooler;
- IP fixo;
- isolamento Wi-Fi;
- roteadores;
- logs do Firewall.
Assim aplicaremos na prática tudo que aprendemos neste artigo.
Metodologia completa para diagnosticar o Firewall pelos logs
Vamos consolidar o processo.
Etapa 1 — Defina o problema
Não escreva apenas:
“Programa não conecta.”
Defina:
qual função falha?
Etapa 2 — Identifique o fluxo
Descubra:
- origem;
- destino;
- protocolo;
- porta;
- direção.
Etapa 3 — Descubra o perfil
Execute:
Get-NetConnectionProfile
Etapa 4 — Verifique o logging
Execute:
Get-NetFirewallProfile
Confira:
LogFileName
LogAllowed
LogBlocked
LogMaxSizeKilobytes
Etapa 5 — Habilite somente o logging necessário
Durante troubleshooting, configure o registro de acordo com a necessidade e a política do ambiente.
Etapa 6 — Anote o horário
Registre o início do teste.
Etapa 7 — Reproduza o problema
Faça uma tentativa controlada.
Quando TCP for aplicável:
Test-NetConnection DESTINO -Port PORTA
ou reproduza diretamente pelo programa.
Etapa 8 — Repita
Faça duas ou três tentativas controladas.
Isso ajuda a encontrar padrões temporais no log.
Etapa 9 — Analise as últimas entradas
Use:
Get-Content "CAMINHO-DO-LOG" -Tail 100
Etapa 10 — Acompanhe em tempo real quando necessário
Use:
Get-Content "CAMINHO-DO-LOG" -Tail 20 -Wait
Etapa 11 — Procure DROP
Use:
Select-String
para filtrar:
DROP
Etapa 12 — Procure ALLOW
Faça o mesmo para:
ALLOW
quando o registro de conexões permitidas estiver habilitado.
Etapa 13 — Correlacione
Compare:
horário + protocolo + origem + destino + porta
Etapa 14 — Consulte as regras
Use:
Get-NetFirewallRule
Etapa 15 — Analise o programa
Use:
Get-NetFirewallApplicationFilter
Etapa 16 — Analise a porta
Use:
Get-NetFirewallPortFilter
Etapa 17 — Analise o endereço
Use:
Get-NetFirewallAddressFilter
Etapa 18 — Verifique o serviço
Para TCP:
Get-NetTCPConnection
ou:
netstat
Etapa 19 — Corrija apenas a condição necessária
Evite liberar:
qualquer programa + qualquer porta + qualquer perfil + qualquer endereço
Etapa 20 — Repita exatamente o teste
Compare:
antes
com:
depois
Um diagnóstico ideal possui evidência antes e depois
Imagine:
Antes
Test-NetConnection
resultado:
False
Log:
DROP
Regra:
perfil incompatível.
Alteração
Corrigimos somente a condição apropriada.
Depois
Test-NetConnection
resultado:
True
Log:
ALLOW
Programa:
funciona.
Essa sequência é muito mais confiável do que:
“Desativei algumas coisas e voltou.”
Erros comuns ao utilizar o pfirewall.log
Procurar somente DROP
ALLOW também pode revelar informações importantes.
Não verificar #Fields
Você pode interpretar colunas incorretamente.
Ignorar o horário
Um evento antigo pode não ter relação com o teste atual.
Procurar apenas a porta
O mesmo número pode aparecer em várias comunicações.
Procurar apenas o IP
Um servidor pode receber várias conexões diferentes.
Não verificar o perfil
Você pode analisar configuração que não corresponde à conexão atual.
Não confirmar LogFileName
Talvez esteja lendo o arquivo errado.
Não confirmar LogBlocked
Você procura DROP em um ambiente que não está configurado para registrá-lo.
Não confirmar LogAllowed
Você espera ALLOW sem ter habilitado esse registro.
Culpar o Firewall porque encontrou qualquer DROP
Pacotes descartados fazem parte do funcionamento normal de uma política de firewall.
Concluir que não é Firewall porque não encontrou DROP
Primeiro valide se a coleta está funcionando corretamente.
Segurança: não deixe permissões amplas depois do teste
Troubleshooting não deve terminar com uma regra como:
Qualquer programa
Qualquer protocolo
Qualquer porta
Qualquer IP
Todos os perfis
apenas porque “funcionou”.
Depois de identificar a necessidade, restrinja a regra.
A melhor política é aquela que permite o funcionamento necessário sem ampliar a exposição sem motivo.
Revise o logging depois do diagnóstico
Se você habilitou logging detalhado apenas para troubleshooting, avalie se precisa mantê-lo.
Registrar muitas conexões permitidas pode aumentar rapidamente o volume do arquivo.
Em computadores corporativos, siga as políticas da organização.
Conclusão: pare de adivinhar se o Firewall bloqueou
O Firewall do Windows pode parecer difícil de diagnosticar porque o usuário normalmente percebe apenas o resultado final:
“O programa não conecta.”
Mas o problema pode ser transformado em uma sequência objetiva.
Precisamos descobrir:
quem está tentando falar
com quem
usando qual protocolo
em qual porta
em qual horário
Depois configuramos o logging e verificamos o que aconteceu.
O pfirewall.log permite sair de:
“Acho que o Firewall bloqueou.”
para algo muito mais técnico:
“Durante o teste, o Firewall registrou DROP para este protocolo, entre estes endereços e nesta porta.”
Ou, igualmente importante:
“O Firewall registrou ALLOW para o fluxo investigado; precisamos procurar a falha em outra etapa.”
Combinando:
Get-NetFirewallProfile
Get-NetConnectionProfile
netsh advfirewall
Get-Content
Select-String
Test-NetConnection
Get-NetFirewallRule
Get-NetFirewallApplicationFilter
Get-NetFirewallPortFilter
e:
Get-NetFirewallAddressFilter
transformamos o log do Firewall em uma verdadeira ferramenta de diagnóstico.
Perguntas frequentes sobre pfirewall.log e logs do Firewall do Windows 11
O que é pfirewall.log?
É um arquivo de log utilizado pelo Firewall do Windows para registrar informações sobre tráfego conforme as opções de logging configuradas.
Onde fica o pfirewall.log?
O caminho tradicional é:
%windir%\system32\logfiles\firewall\pfirewall.log
Porém o local pode ser alterado. Consulte LogFileName para confirmar.
Como descobrir qual arquivo o Firewall está usando?
Execute:
Get-NetFirewallProfile
e verifique:
LogFileName
Como ativar o registro de conexões bloqueadas?
Podemos configurar o Firewall para registrar tráfego descartado pela interface wf.msc, PowerShell/políticas apropriadas ou netsh advfirewall, conforme o ambiente.
Como ativar o registro de conexões permitidas?
Nas propriedades de logging do perfil, habilite o registro de conexões bem-sucedidas. Também é possível administrá-lo com ferramentas de linha de comando.
O que significa DROP?
Indica tráfego descartado registrado pelo Firewall.
Isso não significa automaticamente que aquele registro seja a causa do problema investigado.
O que significa ALLOW?
Indica tráfego permitido registrado.
Ele pode ajudar a demonstrar que determinado fluxo passou pelo Firewall.
Se encontrei DROP, o Firewall é o culpado?
Não necessariamente.
Confirme horário, protocolo, IP de origem, IP de destino e portas.
O registro precisa corresponder ao fluxo que está sendo investigado.
Se não encontrei DROP, posso descartar o Firewall?
Não imediatamente.
Primeiro confirme que o logging está habilitado, o perfil está correto, o arquivo está correto e a coleta funciona.
Como acompanhar o log em tempo real?
Podemos utilizar:
Get-Content "CAMINHO-DO-LOG" -Tail 20 -Wait
Como mostrar apenas registros DROP?
Podemos combinar Get-Content com:
Select-String "DROP"
Posso procurar um IP específico?
Sim.
Select-String permite filtrar linhas contendo determinado endereço.
Ping funcionando significa que uma porta está liberada?
Não.
Ping normalmente testa ICMP. Um aplicativo pode depender de TCP ou UDP em portas específicas.
Test-NetConnection funciona para testar portas?
Ele é muito útil para testar conectividade TCP para determinada porta.
O pfirewall.log substitui o Pktmon?
Não.
O log do Firewall e uma captura de pacotes possuem objetivos diferentes e podem ser complementares.
Posso usar o pfirewall.log para investigar impressoras?
Sim. Ele pode ajudar a analisar determinados fluxos relacionados à comunicação com a impressora, mas o diagnóstico também precisa considerar porta configurada, protocolo, IP, WSD, spooler, descoberta e rede.
O log pode ficar muito grande?
Sim. Principalmente quando o registro de conexões permitidas está habilitado em um computador com muito tráfego. Configure tamanho e retenção de acordo com a necessidade do ambiente.
Problemas de Firewall e rede no Windows 11? A VMIA pode diagnosticar
Uma conexão bloqueada nem sempre significa simplesmente “abrir uma porta”.
O problema pode envolver:
- Firewall do Windows;
- regra de entrada;
- regra de saída;
- perfil Público ou Privado;
- TCP ou UDP;
- endereço IP;
- DNS;
- roteador;
- Wi-Fi;
- VPN;
- impressora;
- serviço do Windows;
- isolamento entre dispositivos;
- configuração incorreta do programa.
A VMIA – Manutenção e Configuração realiza diagnóstico técnico de computadores Windows e redes, procurando identificar a causa antes de alterar configurações de segurança.
O atendimento pode ser realizado por acesso remoto ou visita técnica agendada, conforme o problema.
VMIA – Manutenção e Configuração
Rua Prof. Sud Menucci, 291 – Vila Mariana – São Paulo – SP – 04017-080
Telefone/WhatsApp: (11) 99779-7772
Site: vmia.site
Blog: vmia.com.br
Atendimento com agendamento.
Faça um comentário