A impressora está ligada.
Está conectada ao Wi-Fi ou cabo.
Possui endereço IP.
O computador consegue acessar a Internet normalmente.
Em alguns casos:
ping 192.168.1.50
responde perfeitamente.
Mesmo assim, quando o usuário tenta imprimir, acontece um dos seguintes problemas:
A impressora aparece offline.
O documento fica preso na fila.
O Windows não encontra a impressora.
A instalação não consegue localizar o equipamento.
A impressora aparece, mas o trabalho não chega até ela.
A impressora funciona em um computador e não funciona em outro.
Nesse momento surge uma suspeita muito comum:
“O Firewall do Windows está bloqueando a impressora.”
Pode estar.
Mas também pode não estar.
Desativar completamente o Firewall apenas para testar e deixá-lo desativado não é uma solução adequada.
O diagnóstico correto precisa responder perguntas mais específicas:
Qual protocolo a impressora utiliza?
Qual porta o Windows está utilizando?
A impressora está configurada por WSD ou Porta TCP/IP Padrão?
O problema é impressão ou descoberta?
Existe comunicação TCP com o endereço da impressora?
O Firewall registrou algum DROP relacionado ao teste?
Existe alguma regra que corresponde ao fluxo?
O computador está usando perfil Público ou Privado?
A impressora é acessada diretamente pelo IP ou compartilhada por outro computador?
Neste guia vamos montar um diagnóstico completo.
Antes do Firewall: descubra como essa impressora está instalada
Esse é um dos passos mais importantes de todo o troubleshooting.
Duas impressoras aparentemente iguais podem estar instaladas no Windows de formas completamente diferentes.
Um computador pode utilizar:
Porta TCP/IP Padrão
Outro:
WSD
Outro pode acessar:
uma impressora compartilhada por outro computador Windows
E outro ainda pode utilizar um monitor de porta fornecido pelo fabricante.
Por isso, não existe uma única “porta da impressora” que possa ser aplicada cegamente a qualquer cenário.
Precisamos primeiro identificar a arquitetura.
Cenário 1 — Impressora de rede acessada diretamente por IP
Imagine uma impressora com:
192.168.1.50
O Windows possui uma Porta TCP/IP Padrão apontando diretamente para:
192.168.1.50
Nesse cenário, o computador envia os trabalhos diretamente para o equipamento.
É uma situação bastante diferente de imprimir através de outro computador.
Cenário 2 — Impressora instalada por WSD
O Windows também possui suporte ao:
Web Services for Devices
ou:
WSD
Nesse modelo entram mecanismos de descoberta e comunicação diferentes de uma simples porta RAW apontando para um endereço IP.
Portanto:
WSD e Porta TCP/IP Padrão não devem ser tratados como se fossem exatamente a mesma coisa.
Cenário 3 — Impressora compartilhada por outro computador
Imagine:
PC A possui a impressora.
PC B acessa:
\\PC-A\Impressora
Agora existe comunicação:
PC B → PC A
e depois:
PC A → impressora
O computador cliente não está necessariamente enviando o trabalho diretamente para a porta 9100 da impressora.
Existe um spooler remoto envolvido.
Nesse cenário entram componentes e protocolos do Windows que não aparecem da mesma forma em uma instalação direta por IP.
Primeiro passo: descubra o IP da impressora
Se estamos investigando uma impressora de rede direta, descubra seu endereço.
Exemplo:
192.168.1.50
Podemos encontrá-lo:
- no painel da impressora;
- página de configuração de rede;
- interface do roteador;
- software do fabricante;
- propriedades da porta no Windows.
Anote o endereço.
Esse será um dos principais identificadores do nosso teste.
Não confunda IP atual com IP configurado no Windows
Imagine que o Windows está configurado para:
192.168.1.50
Mas depois de uma alteração no DHCP a impressora recebeu:
192.168.1.73
Agora temos:
Windows → 192.168.1.50
e:
impressora → 192.168.1.73
Nesse caso, o Firewall pode estar funcionando perfeitamente.
O Windows simplesmente está tentando falar com o endereço errado.
Verifique qual porta a impressora usa no Windows
Abra:
Configurações
Procure:
Bluetooth e dispositivos
Depois:
Impressoras e scanners
Selecione a impressora.
Abra suas propriedades apropriadas e acesse:
Propriedades da impressora
Procure a guia:
Portas
Essa tela é extremamente importante.
Observe qual porta está marcada.
Podemos encontrar algo parecido com:
IP_192.168.1.50
ou uma porta:
WSD-...
Também podemos encontrar portas criadas pelo software do fabricante.
Se for TCP/IP, abra Configurar Porta
Selecione a porta correspondente.
Abra:
Configurar Porta
Observe informações como:
Nome ou endereço IP da impressora
Protocolo
Número da porta
Status SNMP
Essas informações revelam como o Windows está tentando enviar o trabalho.
RAW e porta 9100
Na Porta TCP/IP Padrão, um cenário muito comum é:
Protocolo: RAW
Número da porta: 9100
Portanto, se a impressora está configurada dessa maneira, temos um fluxo concreto para testar:
COMPUTADOR → IP-DA-IMPRESSORA:9100/TCP
Agora saímos de:
“A impressora não imprime.”
para:
“O computador precisa estabelecer comunicação TCP com 192.168.1.50 na porta 9100.”
Isso é muito mais fácil de diagnosticar.
Nem toda impressora utiliza RAW 9100
Não transforme:
9100
em uma regra universal.
Uma configuração pode utilizar:
- RAW;
- LPR;
- WSD;
- IPP;
- compartilhamento Windows;
- monitor proprietário do fabricante.
Por isso:
primeiro identifique a porta configurada.
Depois teste.
Ping é apenas o primeiro teste
Execute:
ping 192.168.1.50
Imagine:
Resposta de 192.168.1.50
Isso confirma que houve resposta ICMP naquele teste.
Não confirma que:
TCP 9100
esteja funcionando.
Não confirma que:
WSD
esteja funcionando.
Não confirma que:
o spooler esteja correto.
Não confirma que:
o driver esteja correto.
Não confirma que:
o Windows esteja utilizando o IP certo.
Ping responde, mas a impressora continua offline
Esse é justamente um dos motivos pelos quais o troubleshooting de impressoras confunde tantos usuários.
Temos duas camadas diferentes.
Teste 1
ping 192.168.1.50
Resultado:
responde
Teste 2
Impressão:
falha
Não existe contradição.
Os testes verificam coisas diferentes.
Testando TCP 9100 corretamente
Se confirmamos que a porta da impressora utiliza:
RAW 9100
abra PowerShell:
Test-NetConnection 192.168.1.50 -Port 9100
Observe:
TcpTestSucceeded
Se:
True
o teste TCP para aquele endereço e porta foi bem-sucedido.
Se:
False
temos um problema a investigar.
O que TcpTestSucceeded False significa?
Não significa automaticamente:
“O Firewall do Windows bloqueou.”
Pode significar:
- porta não está aberta na impressora;
- impressora está em outro IP;
- serviço de impressão do equipamento não responde;
- equipamento está dormindo ou travado;
- VLAN;
- isolamento;
- firewall;
- ACL;
- rota;
- problema no equipamento;
- protocolo configurado incorretamente.
Precisamos continuar.
Compare o IP configurado na porta
Imagine:
Porta do Windows:
192.168.1.50
IP real:
192.168.1.51
O teste para:
192.168.1.50:9100
falha.
Mas:
192.168.1.51:9100
funciona.
Encontramos um problema de endereçamento.
Não precisamos abrir nenhuma regra do Firewall.
Por que IP reservado ajuda impressoras de rede?
Impressoras normalmente funcionam melhor quando o endereço utilizado pelo Windows permanece previsível.
Isso pode ser obtido, por exemplo, através de uma reserva DHCP corretamente configurada no roteador.
Assim, o mesmo dispositivo continua recebendo o endereço esperado.
Isso reduz situações como:
Windows aponta para 192.168.1.50
enquanto:
impressora passou para 192.168.1.73
IP fixo não corrige Firewall
Esse detalhe também é importante.
Configurar um endereço estável ajuda a evitar mudança de endereço.
Mas não corrige automaticamente:
- porta bloqueada;
- regra de Firewall;
- driver;
- WSD;
- spooler;
- isolamento Wi-Fi.
São problemas diferentes.
Descubra se o computador realmente está tentando falar com a impressora
Podemos observar conexões TCP.
Execute:
Get-NetTCPConnection
Para procurar especificamente pelo IP:
Get-NetTCPConnection | Where-Object RemoteAddress -eq "192.168.1.50"
Se existir uma tentativa ativa ou conexão relacionada, poderemos encontrar informações úteis.
Também podemos utilizar:
netstat -ano
e procurar pelo endereço.
Test-NetConnection é melhor para produzir um teste controlado
Para nosso diagnóstico de Firewall, queremos uma tentativa previsível.
Execute:
Test-NetConnection 192.168.1.50 -Port 9100
Anote o horário.
Por exemplo:
14:35:10
Repita:
14:35:20
Depois:
14:35:30
Agora temos três tentativas controladas.
Isso será extremamente útil quando consultarmos o:
pfirewall.log
Consulte o log do Firewall
No artigo anterior aprendemos a configurar:
pfirewall.log
Agora vamos utilizá-lo em um caso real.
Primeiro confira:
Get-NetFirewallProfile | Format-List Name,Enabled,LogFileName,LogAllowed,LogBlocked
Precisamos saber:
- qual arquivo está sendo utilizado;
- se conexões permitidas estão sendo registradas;
- se tráfego bloqueado está sendo registrado.
Procure pelo IP da impressora
Exemplo:
Select-String -Path "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Pattern "192.168.1.50"
Agora examine as linhas encontradas.
Procure o período em que executamos os testes.
Procure DROP relacionado ao teste
Podemos reduzir:
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" | Select-String "DROP" | Select-String "192.168.1.50"
Depois procure também a porta esperada.
No nosso exemplo:
9100
O objetivo é encontrar algo que corresponda a:
horário + IP + protocolo + porta
Encontrar DROP é uma pista importante
Imagine que exatamente durante nossas três tentativas encontramos registros compatíveis com:
DROP
TCP
192.168.1.50
9100
Agora temos evidência muito melhor do que simplesmente:
“Acho que é Firewall.”
Precisamos descobrir qual regra ou política corresponde ao fluxo.
E se aparecer ALLOW?
Imagine que o log mostra registros correspondentes:
ALLOW
para:
TCP 9100
no mesmo horário.
Nesse caso, precisamos considerar seriamente que o Firewall permitiu aquele fluxo registrado.
Então investigamos:
- porta da impressora;
- driver;
- spooler;
- estado do equipamento;
- SNMP;
- protocolo;
- trabalho de impressão.
E se não aparecer nada?
Antes de concluir:
“Não é Firewall.”
confirme:
LogAllowed
LogBlocked
perfil correto
arquivo correto
horário correto
IP correto
porta correta
Também precisamos considerar que o problema pode ocorrer em um fluxo diferente daquele que estamos observando.
Agora verifique o perfil da rede
Execute:
Get-NetConnectionProfile
Observe:
NetworkCategory
Podemos encontrar:
Public
ou:
Private
Esse detalhe pode afetar regras relacionadas a descoberta e compartilhamento.
Impressão direta e descoberta não são a mesma coisa
Imagine:
A impressora não aparece quando clicamos em:
Adicionar dispositivo
Mas:
Test-NetConnection 192.168.1.50 -Port 9100
retorna:
True
Isso sugere uma situação interessante.
A comunicação direta com a porta testada funciona.
O problema pode estar relacionado ao mecanismo utilizado para:
descobrir automaticamente a impressora.
Portanto:
não aparecer automaticamente não significa necessariamente que a impressão TCP/IP direta está bloqueada.
WSD adiciona outra camada ao diagnóstico
Quando encontramos uma porta:
WSD-...
não estamos lidando simplesmente com:
IP + TCP 9100
WSD utiliza mecanismos de Web Services for Devices.
Isso pode envolver descoberta e comunicação próprias.
Nesse cenário, precisamos investigar:
- perfil da rede;
- descoberta;
- regras correspondentes;
- serviços;
- endereço;
- comunicação WSD;
- comportamento do equipamento.
Por que trocar tudo para TCP/IP não deve ser o primeiro passo?
Em alguns ambientes, a Porta TCP/IP Padrão pode ser uma escolha bastante previsível.
Mas troubleshooting correto começa identificando:
por que a configuração atual falha.
Se simplesmente substituímos WSD por TCP/IP sem investigar, podemos fazer a impressora funcionar e ainda assim não descobrir a causa.
Para suporte técnico, entender a causa é valioso.
Impressora compartilhada por outro computador muda completamente o diagnóstico
Agora imagine:
PC A:
192.168.1.20
possui a impressora instalada.
PC B utiliza:
\\PC-A\Impressora
Se o PC B não consegue imprimir, testar:
IP-DA-IMPRESSORA:9100
a partir do PC B pode não representar o fluxo que está falhando.
O cliente está tentando falar com:
PC A
O PC A é que administra a fila compartilhada.
Compartilhamento de impressoras pode envolver SMB e RPC
Quando utilizamos compartilhamento de impressoras entre computadores Windows, entram em cena componentes diferentes da impressão TCP/IP direta.
Dependendo do cenário, precisamos investigar:
- compartilhamento de arquivos e impressoras;
- spooler remoto;
- SMB;
- RPC;
- regras de Firewall correspondentes;
- políticas de impressão.
Por isso nunca abra simplesmente:
TCP 9100
e espere que uma impressora compartilhada volte a funcionar.
Windows 11 e RPC de impressão
Em versões atuais do Windows 11, a comunicação de impressão entre computadores também possui considerações relacionadas a RPC.
Ambientes que utilizam servidor de impressão ou compartilhamento entre computadores precisam tratar esse cenário separadamente.
Isso será aprofundado na próxima parte.
Não abra grandes intervalos de portas sem entender o cenário
Ao pesquisar problemas de impressora na Internet, é comum encontrar recomendações como:
“Abra estas dez portas.”
ou:
“Desative o Firewall.”
Essa abordagem é ruim.
Primeiro determine:
qual arquitetura de impressão está sendo utilizada?
Depois:
qual fluxo está falhando?
Somente então analise a regra correspondente.
Use wf.msc
Pressione:
Windows + R
Digite:
wf.msc
Agora temos acesso ao:
Firewall do Windows Defender com Segurança Avançada
Podemos analisar:
Regras de Entrada
e:
Regras de Saída
Procure regras relacionadas ao cenário que está sendo investigado.
Não procure apenas a palavra “impressora”
Algumas regras podem estar associadas a grupos ou serviços.
Além disso, uma comunicação pode depender de:
- compartilhamento;
- descoberta;
- spooler;
- RPC;
- aplicação do fabricante.
O nome visual da regra não é suficiente.
Abra suas propriedades.
Verifique cinco condições da regra
Para qualquer regra suspeita, confirme:
1. Direção
Entrada ou saída?
2. Ação
Allow ou Block?
3. Perfil
Domain?
Private?
Public?
4. Protocolo e porta
Correspondem ao fluxo?
5. Escopo
Os endereços envolvidos estão permitidos?
Esses cinco pontos eliminam grande parte dos falsos diagnósticos.
Use PowerShell para analisar regras
Liste regras habilitadas:
Get-NetFirewallRule -Enabled True
Procure regras de bloqueio:
Get-NetFirewallRule -Enabled True -Action Block
Depois podemos relacioná-las aos filtros:
Get-NetFirewallPortFilter
Get-NetFirewallAddressFilter
Get-NetFirewallApplicationFilter
O objetivo não é listar milhares de regras.
É encontrar regras que correspondam ao fluxo observado.
O caminho correto é do tráfego para a regra
Não faça:
Regra → talvez seja esta → alterar → testar.
Prefira:
Falha → descobrir fluxo → reproduzir → log → protocolo/porta/IP → localizar regra → corrigir → retestar.
Essa metodologia reduz muito as alterações desnecessárias.
Um primeiro diagnóstico em menos de cinco minutos
Para uma impressora TCP/IP direta, podemos começar assim:
1.
Descubra o IP.
Exemplo:
192.168.1.50
2.
Veja a porta configurada no Windows.
3.
Se for RAW 9100:
Test-NetConnection 192.168.1.50 -Port 9100
4.
Confira:
Get-NetConnectionProfile
5.
Confira:
Get-NetFirewallProfile
6.
Reproduza o problema e anote o horário.
7.
Procure o IP no:
pfirewall.log
8.
Se houver DROP correspondente, investigue a regra.
9.
Se houver ALLOW correspondente, investigue outras partes do sistema de impressão.
Isso já é muito melhor do que desativar o Firewall.
RAW 9100, LPR, WSD, descoberta, SMB e RPC: qual comunicação da impressora está falhando?
Na primeira parte, estabelecemos uma regra fundamental:
antes de alterar o Firewall, descubra como a impressora está instalada.
Isso é importante porque “impressora de rede” pode significar arquiteturas completamente diferentes.
Podemos ter:
Computador → impressora diretamente pelo IP
ou:
Computador → descoberta WSD → impressora
ou:
Computador cliente → outro computador Windows → impressora
Para o usuário, todas parecem apenas uma impressora.
Para a rede, são fluxos diferentes.
Primeiro classifique a instalação
Abra:
Configurações → Bluetooth e dispositivos → Impressoras e scanners
Selecione a impressora.
Abra:
Propriedades da impressora
Depois:
Portas
Agora identifique o tipo de porta selecionada.
Podemos encontrar:
IP_192.168.1.50
WSD-...
ou outro monitor fornecido pelo fabricante.
Essa informação define boa parte do diagnóstico seguinte.
Cenário A — Porta TCP/IP Padrão com RAW
Vamos começar pelo cenário mais simples.
Imagine:
IP da impressora: 192.168.1.50
Tipo: Porta TCP/IP Padrão
Protocolo: RAW
Porta: 9100
O fluxo principal de impressão pode ser representado como:
PC → 192.168.1.50:9100/TCP
Isso é excelente para troubleshooting porque temos:
destino conhecido
protocolo conhecido
porta conhecida
Teste RAW 9100
No PowerShell:
Test-NetConnection 192.168.1.50 -Port 9100
Observe:
TcpTestSucceeded
Se retornar:
True
conseguimos estabelecer o teste TCP para a porta.
Isso não prova que o driver e o spooler funcionarão corretamente.
Mas demonstra que a conectividade TCP testada existe.
Se retornar False
Não crie imediatamente uma regra no Firewall.
Verifique primeiro:
- O IP está correto?
- A impressora está ligada?
- A porta do Windows aponta para o mesmo IP?
- A impressora realmente aceita RAW 9100?
- Existe isolamento entre Wi-Fi e LAN?
- A impressora está em outra VLAN?
- O equipamento está respondendo?
- O Firewall registrou DROP?
Essa ordem evita perder tempo.
Teste ping e 9100 juntos
Execute:
ping 192.168.1.50
Depois:
Test-NetConnection 192.168.1.50 -Port 9100
Agora podemos ter quatro interpretações gerais.
Ping funciona e TCP 9100 funciona
Isso demonstra que:
- houve resposta ICMP;
- o teste TCP para 9100 foi bem-sucedido.
Se a impressão ainda falha, investigue:
- spooler;
- driver;
- fila;
- configuração da porta;
- SNMP;
- formato do trabalho;
- estado da impressora.
Nesse cenário, culpar imediatamente o Firewall pela comunicação TCP testada perde força.
Ping funciona e TCP 9100 falha
Esse cenário é especialmente interessante.
A impressora está alcançável por ICMP, mas a porta TCP testada não responde.
Investigue:
- serviço RAW desabilitado no equipamento;
- porta configurada incorretamente;
- firewall;
- ACL;
- segmentação;
- configuração da impressora;
- outro equipamento de rede.
Agora o pfirewall.log pode ajudar.
Ping falha e TCP 9100 funciona
Também pode acontecer.
Alguns dispositivos ou políticas podem não responder a ICMP, mas aceitar a comunicação necessária ao serviço.
Por isso:
ping não deve ser tratado como teste definitivo de disponibilidade da impressora.
Ping falha e TCP 9100 falha
Agora temos uma falha mais ampla.
Verifique:
- IP;
- máscara;
- gateway quando aplicável;
- VLAN;
- Wi-Fi;
- cabo;
- isolamento;
- endereço duplicado;
- estado do equipamento.
Antes de entrar profundamente nas regras do Windows, confirme a conectividade básica.
Cenário B — Porta TCP/IP com LPR
Outra possibilidade é encontrar:
LPR
em vez de RAW.
Nesse caso, não devemos testar apenas:
9100
como se fosse obrigatório.
LPR utiliza outra arquitetura de impressão.
O monitor de Porta TCP/IP Padrão do Windows oferece suporte tanto a RAW quanto a LPR.
Portanto, consulte a configuração efetiva da porta.
LPR utiliza fila
Em uma configuração LPR, podemos encontrar um:
nome da fila
Além da conectividade, esse nome precisa corresponder ao que o equipamento espera.
Isso significa que podemos ter rede funcionando e ainda assim uma configuração LPR incorreta impedir a impressão.
Não transforme um problema LPR em problema RAW
Se a porta está configurada como LPR, testar somente:
TCP 9100
não representa adequadamente a configuração.
O diagnóstico deve acompanhar o protocolo realmente selecionado.
Essa regra vale para todo este artigo:
teste o fluxo real, não o fluxo que você imagina que a impressora deveria utilizar.
Cenário C — Impressora instalada por WSD
Agora entramos em uma situação mais complexa.
Na guia Portas encontramos:
WSD-...
O Windows está utilizando:
Web Services for Devices
Nesse cenário, a experiência pode envolver descoberta e comunicação baseadas em serviços Web.
Isso muda bastante o troubleshooting.
O problema pode ser somente descoberta
Imagine:
A impressora está ligada.
Possui IP:
192.168.1.50
Responde ao ping.
A interface Web abre.
Mas, ao selecionar:
Adicionar dispositivo
o Windows não encontra a impressora.
Isso não significa automaticamente que:
“todas as portas da impressora estão bloqueadas.”
Pode existir um problema específico de descoberta.
Descoberta e impressão são etapas diferentes
Esse conceito precisa ficar muito claro.
Descoberta
O Windows tenta localizar dispositivos disponíveis.
Instalação
O Windows cria a impressora e associa driver, porta e configuração.
Impressão
O spooler envia trabalhos através do caminho configurado.
Uma etapa pode falhar enquanto as outras funcionam.
Exemplo clássico
A impressora não aparece automaticamente.
Mas você cria manualmente uma Porta TCP/IP para:
192.168.1.50
e a impressão funciona.
O que isso demonstra?
Que o problema original provavelmente não era simplesmente:
“o computador não consegue falar com a impressora.”
A comunicação necessária para a impressão direta funcionou.
A falha estava em outro ponto, possivelmente relacionado à descoberta ou configuração automática.
Perfil Público pode interferir em recursos de descoberta
Execute:
Get-NetConnectionProfile
Imagine:
NetworkCategory : Public
O Windows trata redes Públicas de forma mais restritiva em vários cenários de descoberta e compartilhamento.
Isso pode explicar por que determinado comportamento funciona em:
Private
e não funciona em:
Public
Mas novamente:
não altere o perfil apenas para fazer funcionar.
Primeiro determine se a rede realmente é confiável.
Descubra se o problema acompanha o perfil
Em uma rede de laboratório ou doméstica que realmente deve ser confiável, podemos comparar o comportamento dentro de uma configuração apropriada.
Se determinada função depende de regras habilitadas somente para perfil Privado, isso aparecerá na análise das regras.
Abra:
wf.msc
Procure grupos relacionados a descoberta e compartilhamento.
Verifique:
Perfil
Direção
Protocolo
Escopo
Estado
Não habilite todas as regras de descoberta sem entender o motivo
Esse é um erro comum.
O usuário vê várias regras desabilitadas e pensa:
“Vou habilitar todas.”
Isso elimina a capacidade de saber qual comunicação era necessária e pode ampliar a superfície de exposição.
Prefira descobrir:
qual fluxo está falhando?
WSD e multicast
Mecanismos de descoberta podem utilizar multicast.
Isso cria outra diferença importante em relação a uma conexão TCP direta para um endereço conhecido.
Uma rede pode permitir perfeitamente:
PC → 192.168.1.50:9100
e ainda impedir determinados mecanismos de descoberta multicast.
Roteadores e Wi-Fi também podem impedir descoberta
Nem todo problema de descoberta está no Firewall do Windows.
Alguns equipamentos de rede possuem:
- isolamento de clientes;
- AP Isolation;
- redes de convidados;
- VLANs;
- filtragem multicast;
- segmentação entre Wi-Fi e Ethernet.
Imagine:
Notebook no Wi-Fi.
Impressora no Wi-Fi.
Ambos acessam a Internet.
Mas os clientes wireless não podem conversar entre si.
Nesse cenário, abrir regras no Firewall do Windows não resolve.
Teste comunicação direta para separar rede de descoberta
Descubra o IP da impressora.
Depois tente:
ping IP-DA-IMPRESSORA
e, conforme a configuração:
Test-NetConnection IP-DA-IMPRESSORA -Port PORTA
Se a comunicação direta funciona, mas a descoberta não, temos uma separação importante.
Podemos concentrar o diagnóstico nos mecanismos de descoberta.
Cenário D — Impressora compartilhada por outro computador Windows
Agora imagine:
PC-SERVIDOR:
192.168.1.20
possui a impressora instalada.
PC-CLIENTE acessa:
\\PC-SERVIDOR\Impressora
O fluxo é diferente.
O PC-CLIENTE não está simplesmente enviando o trabalho diretamente para:
IP-DA-IMPRESSORA:9100
Ele precisa comunicar-se com o computador que compartilha a fila.
Teste primeiro o computador servidor
No cliente:
ping 192.168.1.20
Depois podemos verificar serviços TCP pertinentes ao cenário.
Mas lembre:
ping sozinho não testa compartilhamento.
SMB pode participar do compartilhamento
Em redes Windows, compartilhamento de arquivos e impressoras pode envolver SMB.
Uma porta extremamente conhecida nesse contexto é:
TCP 445
Podemos testar:
Test-NetConnection 192.168.1.20 -Port 445
Se:
TcpTestSucceeded : False
temos uma pista.
Mas não abra imediatamente a porta.
Primeiro verifique:
- perfil;
- compartilhamento;
- regras;
- serviços;
- política;
- alcance de rede.
TCP 445 aberto não garante que a impressora compartilhada funcionará
Esse detalhe é importante.
O compartilhamento de impressão não deve ser reduzido a:
“porta 445 aberta = tudo certo.”
Existem outros componentes envolvidos, especialmente:
- spooler;
- RPC;
- autenticação;
- políticas de impressão;
- drivers;
- permissões.
O teste serve como parte da investigação.
RPC entra no diagnóstico de impressão compartilhada
A arquitetura de impressão do Windows utiliza RPC em cenários de comunicação remota.
Isso significa que problemas de impressão compartilhada podem exigir análise de regras e políticas relacionadas a RPC.
Por isso, simplesmente abrir:
9100
não corrige um problema entre:
PC-CLIENTE → PC-SERVIDOR
TCP 135 merece atenção em diagnósticos RPC
O RPC Endpoint Mapper tradicionalmente utiliza:
TCP 135
Em troubleshooting controlado podemos testar:
Test-NetConnection 192.168.1.20 -Port 135
Mas novamente:
um teste bem-sucedido para 135 não prova que toda a comunicação RPC necessária funcionará.
RPC pode negociar comunicações adicionais conforme a arquitetura e política utilizadas.
Não abra manualmente toda a faixa RPC
Ao encontrar documentação sobre RPC, alguns usuários descobrem que existem portas dinâmicas e pensam:
“Vou liberar tudo.”
Essa não é uma boa primeira abordagem.
O Windows possui grupos de regras preparados para funcionalidades específicas.
Além disso, ambientes corporativos podem possuir políticas próprias.
Prefira utilizar regras apropriadas e entender o fluxo.
Procure grupos de regras relacionados à funcionalidade
No:
wf.msc
podemos encontrar regras agrupadas por funcionalidades do Windows.
Para compartilhamento e descoberta, procure regras relacionadas ao contexto utilizado.
Analise:
- nome do grupo;
- direção;
- perfil;
- protocolo;
- porta;
- programa/serviço;
- escopo.
O objetivo é habilitar apenas aquilo que a funcionalidade realmente necessita.
Spooler é peça fundamental
O serviço:
Spooler de Impressão
ou:
Spooler
gerencia a fila de impressão no Windows.
Verifique:
Get-Service Spooler
Observe:
Status
Se estiver:
Running
o serviço está em execução.
Se estiver parado, temos um problema que não será resolvido abrindo uma porta no Firewall.
Reiniciar o Spooler não deve ser uma resposta automática
Muitos tutoriais sugerem:
Restart-Service Spooler
para qualquer problema.
Reiniciar pode limpar determinado estado temporário, mas não explica:
- IP errado;
- porta errada;
- driver;
- Firewall;
- WSD;
- isolamento;
- equipamento offline.
Use reinicialização como ferramenta de diagnóstico quando fizer sentido, não como ritual.
Verifique a configuração da impressora com PowerShell
Podemos listar impressoras:
Get-Printer
Isso ajuda a visualizar:
- nome;
- driver;
- porta;
- compartilhamento.
Para uma impressora específica:
Get-Printer -Name "NOME DA IMPRESSORA" | Format-List *
Agora temos uma visão mais detalhada da configuração.
Veja as portas configuradas
Execute:
Get-PrinterPort
Procure a porta utilizada pela impressora.
Podemos filtrar:
Get-PrinterPort | Format-Table Name,PrinterHostAddress,PortNumber,Protocol -AutoSize
Dependendo do tipo de porta e das informações expostas, isso pode revelar rapidamente:
- endereço;
- porta;
- protocolo.
É uma ótima maneira de comparar a configuração com o IP real do equipamento.
Exemplo de erro encontrado em segundos
Imagine:
Get-Printer
mostra:
PortName : IP_192.168.1.50
Mas:
Get-PrinterPort
revela:
PrinterHostAddress : 192.168.1.40
E a impressora atualmente está:
192.168.1.73
Agora temos três endereços envolvidos.
Antes de alterar o Firewall, precisamos corrigir o endereçamento.
Descubra o PID e conexões quando necessário
Para troubleshooting mais profundo podemos correlacionar processos e conexões.
Por exemplo:
Get-NetTCPConnection
e:
Get-Process
Mas em impressão devemos lembrar que o trabalho pode passar pelo:
Spooler
e por componentes do sistema.
Portanto, nem sempre encontraremos o executável do aplicativo original realizando diretamente toda a comunicação com a impressora.
O Word não precisa necessariamente falar diretamente com a impressora
Imagine que você imprime pelo Word.
O usuário pensa:
Word → impressora
Na prática, existe a infraestrutura de impressão do Windows.
O aplicativo entrega o trabalho ao sistema de impressão.
O spooler e os componentes associados cuidam das etapas seguintes.
Isso explica por que procurar apenas uma regra:
WINWORD.EXE
pode ser completamente inadequado.
Use o log do Firewall para descobrir o fluxo real
Com LogAllowed e LogBlocked configurados corretamente, reproduza a impressão.
Anote o horário.
Depois procure:
IP-DA-IMPRESSORA
no:
pfirewall.log
Podemos encontrar tráfego que revela:
- protocolo;
- origem;
- destino;
- porta;
- ação.
Agora não precisamos adivinhar.
Compare tentativa de impressão com Test-NetConnection
Essa comparação é muito útil.
Teste manual
Test-NetConnection 192.168.1.50 -Port 9100
Resultado:
True
Impressão real
Falha.
Isso sugere:
a simples conectividade TCP 9100 não explica sozinha o problema.
Precisamos investigar a fila, driver, configuração e fluxo realmente utilizado.
O contrário também é importante
Teste manual
Test-NetConnection 192.168.1.50 -Port 9100
Resultado:
False
Porta da impressora
RAW 9100.
Agora temos forte motivo para investigar a conectividade daquele fluxo antes de reinstalar drivers.
SNMP pode causar o famoso “offline”
Existe ainda outro componente frequentemente encontrado nas propriedades de uma Porta TCP/IP Padrão:
Status SNMP habilitado
O monitor pode utilizar SNMP para consultar informações do equipamento.
Em determinadas situações, problemas nessa comunicação podem afetar a forma como o Windows apresenta o estado da impressora.
Isso significa que:
“Offline” nem sempre significa que o caminho de impressão TCP está totalmente indisponível.
Não desative SNMP automaticamente
Alguns tutoriais recomendam:
“Desmarque Status SNMP e pronto.”
Isso pode alterar o comportamento em determinados casos, mas novamente queremos diagnóstico.
Pergunte:
A impressão falha ou apenas o status aparece incorreto?
São problemas diferentes.
Impressora aparece offline, mas imprime
Esse cenário é possível.
O monitor de status pode apresentar uma condição diferente da conectividade efetiva utilizada para enviar o trabalho.
Por isso teste:
Test-NetConnection
e uma impressão real.
Não dependa apenas da palavra:
Offline
mostrada na interface.
Impressora aparece online, mas não imprime
Também é possível.
Nesse caso investigue:
- fila;
- spooler;
- driver;
- porta;
- erro do trabalho;
- comunicação durante o envio;
- estado do equipamento.
Novamente:
status visual não substitui diagnóstico.
Método para separar descoberta, conectividade e impressão
Podemos dividir o troubleshooting em três testes.
Teste A — Descoberta
O Windows encontra automaticamente a impressora?
Teste B — Conectividade
O computador consegue alcançar o endereço e serviço necessários?
Teste C — Impressão
O spooler consegue enviar e concluir o trabalho?
Isso cria uma matriz muito útil.
Descoberta falha, conectividade funciona, impressão manual funciona
Suspeite de:
- WSD;
- descoberta;
- multicast;
- perfil;
- regras de descoberta;
- roteador.
Descoberta funciona, conectividade da porta falha
A impressora pode ter sido encontrada, mas o caminho configurado não está funcionando corretamente.
Investigue:
- IP;
- protocolo;
- porta;
- equipamento;
- Firewall;
- rede.
Conectividade funciona, impressão falha
Investigue:
- driver;
- spooler;
- fila;
- protocolo configurado;
- monitor de porta;
- estado do equipamento.
Nada funciona
Volte à camada básica:
- endereço;
- rede;
- Wi-Fi;
- cabo;
- isolamento;
- VLAN;
- roteador;
- equipamento.
Não comece pelo driver.
Crie um diagnóstico documentado
Anote:
Nome da impressora
IP
Porta do Windows
Tipo da porta
RAW/LPR/WSD
Perfil da rede
Ping
Test-NetConnection
Spooler
Resultado do pfirewall.log
Regra correspondente
Resultado da impressão
Essa pequena ficha evita repetir testes e ajuda muito em atendimento técnico.
Como encontrar a regra que bloqueia a impressora e corrigir sem abrir o Firewall inteiro
Nas partes anteriores, separamos os principais cenários:
Porta TCP/IP Padrão
RAW 9100
LPR
WSD
impressora compartilhada
SMB
RPC
Também vimos que uma impressora responder ao ping não significa que a comunicação necessária para imprimir esteja funcionando.
Agora chegamos à etapa decisiva:
como descobrir se existe realmente uma regra do Firewall interferindo e qual configuração precisa ser corrigida?
A metodologia será:
identificar → reproduzir → registrar → correlacionar → localizar regra → corrigir → testar novamente
Primeiro: não comece alterando regras
Antes de abrir o wf.msc, monte uma fotografia do problema.
Anote:
IP da impressora:192.168.1.50
Porta configurada:IP_192.168.1.50
Protocolo:
RAW
Porta TCP:9100
Perfil da rede:
Private
Ping:
Responde
Test-NetConnection 9100:
False
Impressão:
Falha
Agora temos um problema bem definido.
Reproduza a falha em horário conhecido
Abra PowerShell.
Execute:
Get-Date
Anote o horário.
Depois:
Test-NetConnection 192.168.1.50 -Port 9100
Espere alguns segundos.
Repita.
Depois tente imprimir uma página de teste.
Agora temos uma pequena janela temporal para procurar nos logs.
Consulte o pfirewall.log
Primeiro confirme o caminho:
Get-NetFirewallProfile | Select-Object Name,LogFileName,LogAllowed,LogBlocked
Depois consulte o arquivo correspondente.
Exemplo:
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" -Tail 200
Procure o IP:
192.168.1.50
Podemos também utilizar:
Select-String
Procure DROP
Exemplo:
Get-Content "C:\Windows\System32\LogFiles\Firewall\pfirewall.log" | Select-String "DROP" | Select-String "192.168.1.50"
Agora compare com o horário do teste.
Depois verifique:
- protocolo;
- IP de origem;
- IP de destino;
- porta de origem;
- porta de destino.
Não considere qualquer DROP envolvendo a impressora como prova suficiente.
O registro precisa corresponder ao fluxo
Se estamos testando:
PC → 192.168.1.50:9100/TCP
queremos encontrar uma entrada compatível com esse fluxo.
Quanto mais elementos coincidirem, maior a confiança:
horário
TCP
endereço da impressora
porta 9100
Encontrou DROP: agora procure a política correspondente
Esse é o momento de abrir:
wf.msc
Mas agora não estamos procurando aleatoriamente.
Já sabemos aproximadamente:
direção
protocolo
porta
endereço
perfil
Esses dados reduzem drasticamente a quantidade de regras que precisam ser analisadas.
Liste regras de bloqueio com PowerShell
Execute:
Get-NetFirewallRule -Enabled True -Action Block
Observe:
DisplayName
Direction
Profile
Mas não pare no nome da regra.
Precisamos olhar seus filtros.
Analise filtros de porta
Para uma regra específica:
$regra = Get-NetFirewallRule -DisplayName "NOME DA REGRA"
Depois:
$regra | Get-NetFirewallPortFilter
Observe:
Protocol
LocalPort
RemotePort
Compare com o fluxo observado.
Analise filtros de endereço
Execute:
$regra | Get-NetFirewallAddressFilter
Observe:
LocalAddress
RemoteAddress
Imagine que uma regra foi criada para bloquear:
192.168.1.0/24
Agora temos algo extremamente relevante para uma impressora em:
192.168.1.50
Analise o programa ou serviço
Execute:
$regra | Get-NetFirewallApplicationFilter
Dependendo da regra, também pode ser útil analisar o serviço associado.
Não presuma que a regra esteja ligada ao aplicativo que abriu a janela de impressão.
Como vimos:
Word não precisa realizar diretamente toda a comunicação com a impressora.
O subsistema de impressão do Windows participa do processo.
Verifique o perfil da regra
Execute:
$regra | Format-List DisplayName,Enabled,Direction,Action,Profile
Imagine:
Action: Allow
Profile: Private
Mas:
Get-NetConnectionProfile
mostra:
Public
A regra existe, mas não corresponde ao perfil atual.
Regra Allow existente não significa que todo tráfego está liberado
Esse erro é frequente.
O usuário encontra uma regra chamada:
Compartilhamento de Arquivos e Impressoras
com:
Permitir
e conclui:
“Então não é Firewall.”
Mas precisamos verificar:
- está habilitada?
- direção correta?
- perfil correto?
- protocolo correto?
- porta correta?
- escopo correto?
- aplica-se ao serviço correto?
Uma regra é um conjunto de condições.
O nome é apenas uma descrição.
Caso prático — impressora funciona em um PC e não no outro
Esse cenário é excelente para diagnóstico comparativo.
Imagine:
PC A: imprime normalmente.
PC B: não imprime.
Ambos utilizam:
192.168.1.50
Isso já nos dá uma referência.
Compare primeiro a porta
No PC A:
Get-Printer
Get-PrinterPort
Faça o mesmo no PC B.
Compare:
- nome da porta;
- endereço;
- protocolo;
- número da porta;
- driver.
Podemos descobrir rapidamente:
PC A:
192.168.1.50 / RAW / 9100
PC B:
WSD
Agora os computadores não estão usando a mesma arquitetura.
Compare o perfil
No PC A:
Get-NetConnectionProfile
No PC B:
Get-NetConnectionProfile
Talvez encontremos:
PC A:
Private
PC B:
Public
Isso pode explicar diferenças relacionadas a regras e descoberta.
Compare Test-NetConnection
Em ambos:
Test-NetConnection 192.168.1.50 -Port 9100
Imagine:
PC A:
True
PC B:
False
Agora sabemos que a diferença ocorre antes mesmo do driver concluir um trabalho de impressão.
Precisamos investigar rede, política e Firewall no PC B.
Compare os logs
Execute o mesmo teste em horário conhecido.
Depois compare o pfirewall.log.
PC A:
ALLOW
PC B:
DROP
Agora temos uma diferença concreta.
Em vez de reinstalar a impressora dez vezes, investigamos a política do PC B.
Caso prático — impressora funciona por cabo, mas não pelo Wi-Fi
Não conclua imediatamente que:
“O Wi-Fi está ruim.”
Pode existir segmentação.
Exemplo:
Computador cabeado:
192.168.1.20
Impressora:
192.168.1.50
Notebook Wi-Fi:
192.168.50.30
Agora percebemos que o notebook está em outra sub-rede.
Talvez:
- rede de convidados;
- VLAN;
- isolamento;
- roteador secundário;
- NAT;
- outro DHCP.
Isso muda completamente o diagnóstico.
Descubra a configuração de rede
Execute:
ipconfig
ou:
Get-NetIPConfiguration
Compare:
- IPv4;
- gateway;
- interface.
Não tente corrigir uma segmentação de rede criando regras aleatórias no Firewall do Windows.
Caso prático — dois dispositivos no mesmo Wi-Fi, mas não se comunicam
Mesmo SSID não garante comunicação direta.
Um roteador ou access point pode utilizar:
Client Isolation
AP Isolation
ou políticas semelhantes.
Nesse cenário:
- notebook acessa Internet;
- impressora acessa Internet;
- notebook não consegue alcançar a impressora.
O Firewall do Windows não consegue corrigir uma política aplicada pelo access point.
Caso prático — ping funciona, mas RAW 9100 falha
Esse cenário merece uma sequência clara.
1. Ping
ping 192.168.1.50
Resposta.
2. Porta
Test-NetConnection 192.168.1.50 -Port 9100
False.
3. Confirme configuração
A porta da impressora realmente usa RAW 9100?
4. Teste outro computador
Outro PC consegue:
Test-NetConnection 192.168.1.50 -Port 9100
?
Se todos falham, olhe com atenção para:
- impressora;
- protocolo habilitado;
- rede;
- configuração.
Se apenas um computador falha, investigue esse computador.
Comparação entre máquinas é extremamente poderosa
Imagine:
PC A → 9100 = True
PC B → 9100 = False
Mesma impressora.
Mesma rede.
Mesmo horário.
Agora podemos comparar:
- perfil;
- Firewall;
- VPN;
- rota;
- adaptador;
- antivírus;
- política.
Essa comparação reduz muito o universo de possibilidades.
Caso prático — WSD falha, mas TCP/IP funciona
Imagine:
Impressora instalada por:
WSD
apresenta falhas frequentes.
Criamos, para diagnóstico, uma configuração baseada no IP correto e no protocolo suportado pelo equipamento.
A comunicação direta funciona.
Isso demonstra que:
existe caminho de rede entre computador e impressora.
A investigação pode então se concentrar em:
- descoberta;
- WSD;
- perfil;
- serviços;
- comportamento do monitor;
- endereço utilizado.
Não significa que “WSD é sempre ruim”.
Significa que isolamos uma parte do problema.
Caso prático — impressora compartilhada funciona em Privado e falha em Público
Imagine um notebook conectado a uma rede marcada como:
Public
Ele tenta acessar:
\\PC-SERVIDOR\Impressora
e falha.
Na rede Privada funciona.
Essa diferença sugere investigar as regras aplicáveis aos perfis.
Execute:
Get-NetConnectionProfile
Depois abra:
wf.msc
Analise as regras relacionadas ao compartilhamento.
Não habilite compartilhamento indiscriminadamente no perfil Público apenas para eliminar o erro.
Pergunte primeiro:
essa rede é confiável e esse compartilhamento deveria estar disponível nela?
Firewall desligado faz a impressora funcionar: e agora?
Esse é um teste muito utilizado.
Usuário desativa o Firewall.
A impressora funciona.
Conclusão:
“Era o Firewall.”
Essa conclusão é parcialmente útil.
O teste indica que a política local merece investigação.
Mas:
deixar o Firewall desligado não é a correção.
Agora precisamos descobrir:
qual regra estava impedindo a comunicação?
Reative o Firewall
Depois do teste controlado, reative a proteção.
Em seguida:
- determine o fluxo;
- configure logging;
- reproduza;
- encontre DROP;
- identifique regra/perfil;
- faça a correção mínima;
- teste novamente.
O objetivo é:
Firewall ligado + impressão funcionando.
Não crie uma regra Any/Any como solução
Evite regras do tipo:
qualquer programa
qualquer porta
qualquer protocolo
qualquer endereço
todos os perfis
Isso pode fazer o teste funcionar, mas não representa uma boa correção.
Restrinja a regra ao necessário
Quando uma regra realmente precisar ser criada ou ajustada, considere limitar:
- direção;
- protocolo;
- porta;
- perfil;
- programa ou serviço;
- endereço remoto.
Por exemplo, em um cenário controlado de rede local, uma regra pode precisar corresponder somente à comunicação realmente necessária.
A configuração exata depende da arquitetura encontrada.
Não copie uma regra da Internet sem entender o ambiente
Uma solução encontrada para:
impressora compartilhada via Windows
pode não ter qualquer relação com:
impressora RAW 9100 direta
Da mesma forma, uma solução para:
WSD
pode ser irrelevante para:
LPR
Por isso, este artigo insiste tanto em identificar o tipo de instalação.
Crie nomes claros para regras personalizadas
Se uma regra personalizada for realmente necessária, utilize um nome que permita entender sua finalidade.
Exemplo:
VMIA - Impressora Escritório - TCP 9100 - Rede Privada
Isso é muito melhor do que:
Nova Regra
ou:
Liberar Impressora
Também documente por que ela foi criada.
Evite duplicar regras desnecessariamente
Antes de criar uma regra nova, procure se já existe uma regra adequada.
Talvez o problema seja apenas:
- perfil;
- escopo;
- regra desabilitada;
- endereço antigo.
Criar uma segunda, terceira e quarta regra torna o troubleshooting futuro mais difícil.
Depois da correção, repita exatamente o mesmo teste
Esse passo é obrigatório.
Antes:
Test-NetConnection 192.168.1.50 -Port 9100
resultado:
False
Depois:
execute exatamente:
Test-NetConnection 192.168.1.50 -Port 9100
Se agora retorna:
True
temos uma mudança objetiva.
Depois teste uma impressão real
A conectividade TCP funcionar ainda não significa que todo o sistema de impressão esteja correto.
Envie uma página de teste.
Observe:
- fila;
- status;
- desaparecimento do trabalho;
- chegada à impressora;
- impressão física.
O diagnóstico só termina quando a função real funciona.
Verifique novamente o log
Se anteriormente tínhamos:
DROP
e depois da correção temos:
ALLOW
correspondente ao mesmo fluxo, temos uma evidência excelente.
A sequência fica:
antes → DROP
alteração → regra corrigida
depois → ALLOW
impressão → funciona
Esse é um diagnóstico tecnicamente muito mais sólido.
O trabalho sai da fila, mas nada imprime
Esse cenário merece atenção.
Se o trabalho desaparece da fila sem erro, mas a impressora não produz nada, investigue:
- driver;
- linguagem de impressão;
- configuração da porta;
- firmware;
- fila no equipamento;
- compatibilidade.
Não continue abrindo portas apenas porque o papel não saiu.
Trabalho fica parado em “Imprimindo”
Agora verifique:
- conectividade;
- porta;
- spooler;
- monitor de porta;
- equipamento;
- log.
O estado da fila pode ajudar a determinar em qual etapa a impressão está presa.
Trabalho fica em “Erro”
Abra as propriedades e investigue o evento correspondente.
Podemos também utilizar:
Visualizador de Eventos
para procurar informações relacionadas ao sistema de impressão.
O Firewall é apenas uma das possíveis causas.
O Visualizador de Eventos complementa o pfirewall.log
Temos duas fontes diferentes.
pfirewall.log
Ajuda a analisar tráfego permitido e descartado conforme o logging configurado.
Visualizador de Eventos
Pode fornecer informações sobre componentes e falhas do sistema de impressão.
Em um problema complexo, utilize os dois.
Driver e Firewall podem produzir sintomas parecidos
Imagine:
A impressora aparece offline.
O trabalho não imprime.
Isso pode ser:
rede
Mas também:
driver
ou:
monitor de porta
ou:
spooler
ou:
equipamento
Por isso, o diagnóstico baseado em evidências é tão importante.
Checklist VMIA — impressora de rede que não imprime
Etapa 1
Descubra o IP real da impressora.
Etapa 2
Confirme o IP configurado no Windows.
Etapa 3
Identifique a porta:
TCP/IP, WSD ou compartilhada.
Etapa 4
Se TCP/IP, identifique:
RAW ou LPR.
Etapa 5
Confira a porta configurada.
Etapa 6
Execute:
ping IP
como teste complementar.
Etapa 7
Quando aplicável:
Test-NetConnection IP -Port PORTA
Etapa 8
Execute:
Get-NetConnectionProfile
Etapa 9
Confira:
Get-NetFirewallProfile
Etapa 10
Verifique:
LogAllowed
e:
LogBlocked
Etapa 11
Anote o horário.
Etapa 12
Reproduza a falha.
Etapa 13
Analise:
pfirewall.log
Etapa 14
Procure:
DROP
e:
ALLOW
Etapa 15
Correlacione:
horário + IP + protocolo + porta.
Etapa 16
Analise:
Get-NetFirewallRule
Etapa 17
Analise:
Get-NetFirewallPortFilter
Etapa 18
Analise:
Get-NetFirewallAddressFilter
Etapa 19
Confira:
Get-Service Spooler
Etapa 20
Compare outro computador, se disponível.
Etapa 21
Verifique isolamento Wi-Fi e VLAN.
Etapa 22
Faça somente a correção necessária.
Etapa 23
Repita o teste de porta.
Etapa 24
Repita a impressão.
Etapa 25
Compare os logs antes e depois.
Quando o problema provavelmente não está no Firewall do Windows?
Alguns resultados apontam fortemente para outras áreas.
Vários computadores não acessam a impressora
Investigue impressora e infraestrutura de rede.
IP configurado está errado
Corrija endereçamento.
Spooler está parado
Resolva o serviço.
Porta TCP funciona, log mostra ALLOW, mas impressão falha
Investigue driver, spooler, configuração e equipamento.
Notebook e impressora estão em redes isoladas
Investigue roteador, VLAN ou access point.
WSD falha, mas impressão direta por IP funciona
Investigue descoberta/WSD e não apenas a conectividade básica.
Quando o Firewall merece atenção especial?
Quando encontramos uma sequência como:
serviço/endereço correto
porta correta
teste reproduzível
DROP correspondente no log
regra ou perfil compatível com o bloqueio
Agora temos evidência suficiente para investigar a política local de forma direcionada.
Não restaure o Firewall para o padrão como primeira solução
Existe uma tentação:
“Vou restaurar tudo.”
Isso pode remover regras personalizadas importantes e não ensina qual era a causa.
Primeiro diagnostique.
Restauração deve ser uma decisão consciente, não um botão de tentativa.
Não reinstale o Windows por um problema de impressão sem diagnóstico
Parece exagero, mas acontece.
Antes de medidas drásticas, temos ferramentas suficientes para descobrir:
- endereço;
- porta;
- protocolo;
- perfil;
- regra;
- log;
- serviço;
- driver;
- isolamento.
Na maioria dos casos, reinstalar todo o sistema seria uma resposta desproporcional.
Conclusão: “impressora bloqueada pelo Firewall” precisa virar um diagnóstico específico
A frase:
“O Firewall está bloqueando minha impressora”
é ampla demais.
Precisamos transformá-la em algo verificável.
Por exemplo:
“A impressora está em 192.168.1.50, utiliza RAW TCP 9100, responde ao ping, mas o teste TCP falha e o Firewall registra DROP correspondente ao horário da tentativa.”
Agora temos um diagnóstico.
Ou podemos descobrir:
“A porta TCP 9100 responde, o Firewall registra ALLOW, mas o trabalho continua preso na fila.”
Nesse caso, o foco muda.
Também podemos encontrar:
“A impressão direta por IP funciona, mas a descoberta WSD não.”
Novamente, o problema muda.
Ou:
“A impressora funciona em um computador e não no outro porque um está em perfil Privado e o outro utiliza uma política diferente.”
O segredo é separar:
descoberta
conectividade
impressão
compartilhamento
e:
Firewall
em etapas independentes.
Ferramentas como:
ping
Test-NetConnection
Get-Printer
Get-PrinterPort
Get-NetConnectionProfile
Get-NetFirewallProfile
Get-NetFirewallRule
Get-NetFirewallPortFilter
Get-NetFirewallAddressFilter
pfirewall.log
e:
Get-Service Spooler
permitem fazer isso de forma estruturada.
A solução correta não é desligar a proteção.
É descobrir exatamente qual comunicação falha e corrigir somente aquilo que precisa ser corrigido.
Perguntas frequentes sobre Firewall do Windows e impressoras de rede
O Firewall do Windows pode bloquear uma impressora?
Sim. Dependendo do tipo de comunicação, perfil e regras aplicáveis, o Firewall pode interferir em tráfego necessário. Mas problemas de IP, porta, WSD, driver, spooler e isolamento de rede podem produzir sintomas semelhantes.
A impressora responde ao ping. Isso significa que o Firewall não está bloqueando?
Não.
Ping e impressão podem utilizar protocolos diferentes. Uma resposta ICMP não demonstra que a porta necessária para impressão esteja funcionando.
Qual porta uma impressora de rede utiliza?
Depende da configuração.
Uma Porta TCP/IP Padrão configurada em RAW frequentemente utiliza TCP 9100. Outros cenários podem utilizar LPR, WSD, IPP, compartilhamento Windows ou protocolos próprios do fabricante.
Como testar a porta 9100?
Quando a impressora realmente estiver configurada para RAW 9100:
Test-NetConnection IP-DA-IMPRESSORA -Port 9100
TcpTestSucceeded True significa que a impressora deveria imprimir?
Não necessariamente.
Ele demonstra sucesso no teste TCP daquela porta. Driver, spooler, fila e outros componentes ainda podem falhar.
TcpTestSucceeded False significa que o Firewall bloqueou?
Não.
Pode existir problema na impressora, porta, endereço, rede, VLAN, isolamento ou Firewall.
O que é WSD?
WSD significa Web Services for Devices e pode ser utilizado pelo Windows para descoberta e comunicação com dispositivos, incluindo impressoras compatíveis.
WSD é igual a TCP 9100?
Não.
São mecanismos diferentes. Uma impressora WSD não deve ser diagnosticada simplesmente assumindo que tudo depende da porta TCP 9100.
Posso trocar WSD por uma Porta TCP/IP?
Em equipamentos compatíveis, uma instalação direta por IP pode ser uma alternativa válida. Mas, para troubleshooting, primeiro vale identificar por que a configuração atual está falhando.
Impressora offline significa problema de Firewall?
Não necessariamente.
O status pode envolver conectividade, SNMP, monitor de porta, endereço, spooler ou estado do próprio equipamento.
Devo desativar o SNMP?
Não automaticamente.
Primeiro descubra se o problema está no status apresentado ou na impressão propriamente dita.
Impressora funciona em outro computador. O que isso indica?
É uma excelente oportunidade para comparação.
Compare porta, IP, protocolo, perfil de rede, regras, driver e resultado de Test-NetConnection.
O Firewall desligado faz a impressora funcionar. Posso deixá-lo desligado?
Não é uma boa solução.
Use esse resultado como evidência para localizar a regra ou condição responsável e faça uma correção específica mantendo o Firewall ativo.
Preciso liberar todas as portas de impressão?
Não.
Determine primeiro o protocolo e o fluxo realmente utilizados.
Impressora compartilhada usa porta 9100?
Não necessariamente entre o cliente e o computador que compartilha a impressora. O cenário de compartilhamento Windows envolve componentes como SMB, RPC e o spooler.
Como saber se o Firewall realmente descartou o tráfego?
Configure adequadamente o logging do Firewall e analise o pfirewall.log, correlacionando horário, IP, protocolo e porta.
O roteador pode bloquear a impressora?
Sim.
Isolamento de clientes, rede de convidados, VLANs e outras configurações podem impedir comunicação local mesmo quando ambos os dispositivos acessam a Internet.
IP fixo resolve problema de Firewall?
Não.
Um endereço previsível ajuda a evitar mudanças de IP, mas não corrige automaticamente regras, portas, drivers ou problemas de rede.
Sua impressora está na rede, mas o Windows não imprime? A VMIA pode diagnosticar
Problemas de impressão em rede nem sempre são resolvidos reinstalando o driver.
A causa pode estar em:
- endereço IP;
- Porta TCP/IP;
- WSD;
- RAW;
- LPR;
- Firewall do Windows;
- perfil Público ou Privado;
- spooler;
- SNMP;
- roteador;
- Wi-Fi;
- Mesh;
- isolamento de clientes;
- compartilhamento Windows;
- driver;
- configuração da própria impressora.
A VMIA – Manutenção e Configuração realiza diagnóstico de computadores Windows, impressoras e redes domésticas ou de pequenos escritórios.
O atendimento pode ser feito por acesso remoto quando o problema permitir ou por visita técnica agendada para diagnóstico da rede, roteador, Wi-Fi e impressora.
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