Redes · Firewall · pfSense · Netgate · FreeBSD · pf · CARP · OpenVPN · WireGuard · Snort

Duarte Spínola · 25 de Junho de 2026

pfSense: Configuração de Firewall, NAT e VPN em 2026

O pfSense é uma firewall e router open-source baseado em FreeBSD e no packet filter pf, desenvolvido pela Netgate. Em 2026, o pfSense existe em duas edições: o pfSense Plus (fechado, optimizado para hardware Netgate) e o pfSense CE (Community Edition, open-source). Diferentemente do OPNsense — que é um fork comunitário do pfSense — a Netgate oferece appliances físicos próprios (SG-2100, SG-4100, SG-6100), suporte oficial pago e um sistema de packages distinto (Snort/Suricata para IDS/IPS, WireGuard como package). Este guia cobre as configurações principais que diferem do OPNsense: Netgate appliances, pfSense Plus vs CE, floating rules, ALTQ traffic shaping, CARP HA com XMLRPC config sync, DNS Resolver vs Forwarder e troubleshooting na CLI com pfctl. As fontes oficiais estão referenciadas inline, baseadas na documentação oficial Netgate. Para comparação com outras firewalls comerciais, consulte os artigos sobre FortiGate, Palo Alto, Check Point e WatchGuard.

Neste artigo

  1. Arquitectura: pfSense Plus vs CE e Netgate Appliances
  2. Configuração Inicial: Interfaces, VIPs e DNS
  3. Regras de Firewall, Aliases e Floating Rules
  4. NAT: Outbound, Port Forward, 1:1 e Reflection
  5. VPN IPsec: Site-to-Site e Acesso Remoto
  6. VPN OpenVPN para Acesso Remoto
  7. VPN WireGuard via Package
  8. IDS/IPS com Snort e Suricata
  9. Traffic Shaping: ALTQ, Limiters, PRIQ/CBQ/FAIRQ
  10. Alta Disponibilidade com CARP e pfsync
  11. Multi-WAN com Gateway Groups e Failover
  12. Troubleshooting na CLI (pfctl, ifconfig, clog)
  13. Erros Comuns de Configuração
  14. Checklist Rápido de Verificação

1. Arquitectura: pfSense Plus vs CE e Netgate Appliances

O pfSense corre sobre FreeBSD e usa o pf (packet filter) como motor de firewall ao nível do kernel — o mesmo motor do OPNsense, dado que o OPNsense é um fork do pfSense (2014). A grande diferença em 2026 é a bifurcação em duas edições: o pfSense Plus, distribuído pela Netgate e optimizado para os seus appliances (código parcialmente fechado), e o pfSense CE (Community Edition), totalmente open-source e instalável em qualquer hardware x86 ou VM (documentação geral).

Componentes principais da arquitectura pfSense:

Componente Função
pf (packet filter) Motor de firewall no kernel FreeBSD — processa regras, NAT, ALTQ e limiters
Interfaces Físicas (igb, vmx, ixgbe) ou lógicas (VLAN, GRE, WireGuard, OpenVPN, CARP, IPsec)
Aliases Objectos nomeados (IPs, redes, portas, URLs dinâmicas) reutilizáveis em regras
Gateways e Gateway Groups Next-hop routers; grupos para failover ou load balancing multi-WAN
Unbound / dnsmasq DNS Resolver (Unbound) ou DNS Forwarder (dnsmasq) — o utilizador escolhe
Packages Snort, Suricata, WireGuard, ntopng, softether — instalados via Package Manager

A Netgate comercializa appliances físicos com hardware optimizado para pfSense Plus. A escolha do appliance depende do número de interfaces, débito esperado e funcionalidades (ZFS, TPM, crypto offload):

Appliance Interfaces Débito aprox. (Firewall) Uso recomendado
SG-2100 3× GbE (ARM) ~850 Mbps SOHO, pequena rede
SG-4100 4× GbE (Intel Atom) ~2 Gbps PME, multi-WAN básico
SG-6100 8× GbE (Intel Atom) ~5 Gbps PME média, IDS/IPS, HA
SG-7100 10× GbE ~9 Gbps Empresa, alta densidade
XG-7100 8× 10GbE + 1× SFP+ ~17 Gbps Datacenter, alto débito

⚠ Atenção

O pfSense Plus só está disponível para hardware Netgate ou imagens oficiais Netgate. Em hardware próprio (whitebox) ou VM, o utilizador deve instalar o pfSense CE. A maioria das funcionalidades de firewall, NAT e VPN são idênticas entre as duas edições, mas o pfSense Plus inclui melhorias de ZFS, netmap API e interface que o CE nem sempre tem.

A comparação entre pfSense Plus e pfSense CE resume-se a poucos pontos práticos: o pfSense Plus tem licença fechada (Netgate), só corre em hardware Netgate ou imagem oficial, recebe actualizações da Netgate num canal estável, suporta ZFS boot em SG-6100+ e está incluído no custo do appliance. O pfSense CE tem licença open-source (Apache), corre em qualquer hardware x86/ARM/VM, recebe actualizações da comunidade, tem suporte ZFS limitado e é gratuito.

O pfSense e o OPNsense partilham o mesmo motor pf, mas as interfaces web são diferentes: o pfSense usa o WebGUI clássico (menu horizontal System/Firewall/Interfaces/VPN/Services/Status), enquanto o OPNsense usa um WebUI reformulado. A lógica das regras também difere — ver secção 3. Para a comparação directa com o fork comunitário, consulte o artigo sobre OPNsense.

2. Configuração Inicial: Interfaces, VIPs e DNS

Após a instalação (ISO pfSense CE ou imagem Netgate pfSense Plus), o assistente inicial configura WAN e LAN. Por defeito, a LAN é 192.168.1.1/24 e a WAN obtém IP por DHCP. O passo seguinte é atribuir interfaces adicionais e configurar VIPs e DNS (documentação de configuração e interfaces).

Atribuir uma interface DMZ (OPT1):

  1. Navegar para Interfaces > Assignments
  2. Atribuir a interface física (ex.: igb2) a OPT1 e clicar + Add
  3. Navegar para Interfaces > OPT1:
  • Enable: ON
  • IPv4 Configuration Type: Static IPv4
  • IPv4 Address: 192.168.10.1/24
  1. Clicar Save e Apply Changes

Virtual IPs (VIPs): endereços IP adicionais numa interface. Existem três tipos: IP Alias (IP secundário na mesma máquina), CARP (IP partilhado entre duas pfSense para HA) e Proxy ARP (a pfSense responde ARP por um IP que pertence a outro dispositivo). Para NAT 1:1 ou HA, o tipo correcto é essencial.

⚠ Atenção

Não atribuir um VIP CARP a uma interface sem antes configurar o pfsync e o segundo nó. Um VIP CARP num sistema único causa conflitos de ARP e interrupções de rede.

DNS — Resolver vs Forwarder: o pfSense oferece dois motores DNS mutuamente exclusivos. A escolha depende de a rede usar encaminhamento DNS upstream ou resolução recursiva própria:

Critério DNS Resolver (Unbound) DNS Forwarder (dnsmasq)
Modo Resolução recursiva (root servers) Encaminha para DNS upstream
Cache Sim, com DNS-over-TLS e DNSSEC Sim, simples
Overrides Host overrides, domain overrides Host overrides, domain overrides
Recomendado Redes que querem privacidade/controlo Redes que usam DNS do ISP/Cloudflare

Por defeito, o pfSense activa o DNS Resolver (Unbound) em Services > DNS Resolver. Para mudar para Forwarder, desactivar o Resolver e activar Services > DNS Forwarder. Mais detalhes em documentação de DNS.

Para verificar as interfaces atribuídas e os seus IPs a partir da shell:

# Listar todas as interfaces com IPs atribuídos
ifconfig -a | grep -E “^[a-z]|inet ”

# Verificar VIPs CARP configurados
ifconfig | grep -A2 carp

# Estado das rotas e gateway por defeito
netstat -rn | grep default

3. Regras de Firewall, Aliases e Floating Rules

O pfSense processa regras pf de duas formas distintas, e este é um dos pontos que diferencia do OPNsense: regras por interface (tabs Firewall > Rules > LAN/WAN/OPT1) usam lógica first-match (primeira correspondência ganha, de cima para baixo), enquanto floating rules (Firewall > Rules > Floating) usam lógica last-match (a última regra correspondente ganha). As floating rules podem aplicar-se a múltiplas interfaces e direcções em simultâneo (documentação de firewall).

⚠ Atenção

Misturar lógica first-match (interface tabs) com last-match (floating) é a causa nº 1 de regras que “não funcionam” em pfSense. Se uma floating rule faz block e é a última a corresponder, ela sobrepõe-se a uma regra pass do tab da interface. Rever sempre a ordem das floating rules quando algo é bloqueado inesperadamente.

Aliases: objectos nomeados reutilizáveis em regras, criados em Firewall > Aliases. Exemplos práticos: Corp_LAN (Network, 192.168.1.0/24), DMZ_Net (Network, 192.168.10.0/24), Web_Servers (Host(s), 192.168.10.100,192.168.10.101), HTTP_HTTPS (Port(s), 80,443) e VPN_Clients (Network, 10.10.50.0/24).

Regra LAN → WAN (tab da interface):

  1. Navegar para Firewall > Rules > LAN
  2. Adicionar regra:
  • Action: Pass
  • Protocol: TCP/UDP
  • Source: Corp_LAN (alias)
  • Destination: any
  • Gateway: Default (ou gateway group se multi-WAN)
  1. Clicar Save e Apply Changes

Schedules: as regras podem ter horários (Firewall > Schedules). Uma regra com schedule só está activa dentro do período definido — útil para bloquear redes sociais fora do horário laboral sem remover a regra.

Para inspecionar as regras carregadas no pf a partir da shell (Diagnostics > Command Prompt ou SSH):

# Listar todas as regras pf activas (pass/block/NAT)
pfctl -sr

# Listar regras de NAT (rdr, binat, nat)
pfctl -sn

# Mostrar contadores por regra (tráfego que cada regra processou)
pfctl -v -sr

O comando pfctl -sr mostra as regras tal como o pf as carregou — útil para confirmar que uma regra criada no WebGUI está realmente activa e na ordem esperada.

4. NAT: Outbound, Port Forward, 1:1 e Reflection

O pfSense implementa NAT com o motor pf: outbound NAT (masquerade/source NAT), port forward (destination NAT) e 1:1 NAT (binat — mapeamento bidirecional de um IP inteiro). A configuração é feita em Firewall > NAT (documentação de NAT).

Outbound NAT: por defeito, é automático — todos os IPs internos são traduzidos para o IP da interface WAN (masquerade). Para personalizar (ex.: usar um IP público específico para um servidor), mudar para Hybrid Outbound NAT em Firewall > NAT > Outbound e adicionar regras manuais.

Port Forward (servidor web interno):

  1. Navegar para Firewall > NAT > Port Forward
  2. Adicionar regra:
  • Interface: WAN
  • Protocol: TCP
  • Destination: WAN address
  • Destination Port Range: HTTP (80)
  • Redirect Target IP: 192.168.10.100
  • Redirect Target Port: 80
  • Associated Filter Rule: ON (cria automaticamente a regra de firewall na interface WAN)
  1. Clicar Save e Apply Changes

Ao activar Associated Filter Rule, o pfSense cria automaticamente a regra de firewall que permite o tráfego encaminhado no tab da interface WAN. Sem esta opção, é necessário criar a regra manualmente em Firewall > Rules > WAN com destination 192.168.10.100.

1:1 NAT (IP público dedicado): mapeia um IP público inteiro para um servidor interno (todas as portas). Requer um VIP (IP Alias ou Proxy ARP) para o IP público.

  1. Criar VIP em Firewall > Virtual IPs: tipo IP Alias, interface WAN, endereço 203.0.113.20/32
  2. Navegar para Firewall > NAT > 1:1
  3. Adicionar regra:
  • Interface: WAN
  • External Subnet: 203.0.113.20/32
  • Internal Subnet: 192.168.10.100/32
  1. Criar a regra de firewall correspondente em Firewall > Rules > WAN com destination 192.168.10.100

NAT Reflection: permite que clientes internos acedam a um port forward usando o IP público (em vez do IP interno). Configurado em System > Advanced > Firewall & NAT > NAT Reflection. Útil quando o DNS resolve o nome do serviço para o IP público, mas o cliente está na LAN.

5. VPN IPsec: Site-to-Site e Acesso Remoto

O pfSense suporta IPsec para túneis site-to-site e acesso remoto (IKEv1 e IKEv2), configurado em VPN > IPsec (documentação IPsec). A configuração envolve Phase 1 (túnel IKE), Phase 2 (SA ESP) e, para acesso remoto, Phase 1 Mobile e utilizadores com chaves pré-partilhadas ou certificados.

IPsec Site-to-Site (Site A → Site B):

  1. Navegar para VPN > IPsec > Tunnels > Add Phase 1:
  • Key Exchange Version: IKEv2
  • Internet Protocol: IPv4
  • Interface: WAN
  • Remote Gateway: 203.0.113.50 (IP público do Site B)
  • Pre-Shared Key: string aleatória de 32+ caracteres
  • Encryption Algorithm: AES-256-GCM
  • Hash Algorithm: SHA256
  • DH Group: 14 (2048-bit) ou 21 (ECP384)
  • Lifetime: 28800 (8 horas)
  1. Adicionar Phase 2:
  • Mode: Tunnel
  • Local Network: 192.168.1.0/24 (alias Corp_LAN)
  • Remote Network: 192.168.2.0/24
  • Protocol: ESP
  • Encryption: AES-256-GCM
  • Hash: SHA256
  1. Repetir a configuração no Site B com os endereços invertidos
  2. Criar regras de firewall em Firewall > Rules > IPsec para permitir tráfego entre as redes

⚠ Atenção

Em ambientes com NAT entre os sites (ISP que bloqueia IPsec), activar NAT-T (NAT Traversal) em Phase 1. Sem NAT-T, o tráfego ESP (protocolo 50) é descartado por routers com NAT no caminho.

IPsec Mobile (acesso remoto): configurar Phase 1 Mobile com Remote Access e criar utilizadores em System > User Manager com PSK ou certificado. Os clientes (strongSwan no Android, iOS, Windows) ligam-se ao IP público da WAN.

6. VPN OpenVPN para Acesso Remoto

O OpenVPN é a VPN de acesso remoto mais usada no pfSense, suportando SSL/TLS com certificados (Client-Server) ou PSK (Peer-to-Peer). A configuração faz-se em VPN > OpenVPN com três passos: Certificate Authority, servidor e clientes (documentação OpenVPN).

Configurar servidor OpenVPN (Remote Access):

  1. Criar uma CA em System > Certificate Manager > CAs > Add (ou usar CA existente)
  2. Criar um certificado de servidor em System > Certificate Manager > Certificates > Add (tipo Server Certificate)
  3. Navegar para VPN > OpenVPN > Servers > Add:
  • Server Mode: Remote Access (SSL/TLS + User Auth)
  • Protocol: UDP on IPv4
  • Interface: WAN
  • Local Port: 1194
  • Cryptographic Settings: AES-256-GCM, TLS Configuration ON (gerar TLS key)
  • Tunnel Network: 10.10.50.0/24
  • Local Network: 192.168.1.0/24
  • DNS Server: 192.168.1.1
  • Concurrent Connections: 50
  1. Criar utilizadores em System > User Manager com certificado de cliente associado
  2. Adicionar regra de firewall em Firewall > Rules > WAN: UDP, source any, destination WAN address, port 1194
  3. Exportar configurações de cliente via package OpenVPN Client Export (System > Package Manager)

O pfSense gera automaticamente a interface OpenVPN (ovpns1, ovpns2…) e atribui IPs do Tunnel Network via DHCP integrado. Não é necessário configurar DHCP separado. Para HA, o Tunnel Network deve ser diferente em cada nó.

7. VPN WireGuard via Package

Diferentemente do OPNsense (onde o WireGuard é nativo), no pfSense o WireGuard é instalado como package a partir do pfSense 2.5+. A instalação faz-se em System > Package Manager > Available Packages — procurar “wireguard” e instalar (documentação WireGuard).

Configurar WireGuard (site-to-site):

  1. Navegar para VPN > WireGuard > Settings e activar
  2. Em VPN > WireGuard > Tunnels > Add Tunnel:
  • Interface Name: wg0
  • Interface Address: 10.20.0.1/30
  • Listen Port: 51820
  • MTU: 1420 (recomendado para evitar fragmentação)
  1. Gerar o par de chaves (o pfSense gera automaticamente chave privada e pública)
  2. Adicionar Peer no Site A:
  • Public Key: chave pública do Site B
  • Endpoint: 203.0.113.50:51820 (IP público do Site B)
  • Allowed IPs: 192.168.2.0/24,10.20.0.2/32
  1. Adicionar regra de firewall em Firewall > Rules > WAN: UDP, port 51820
  2. Repetir no Site B com endereços invertidos

⚠ Atenção

O WireGuard no pfSense é um package, não código do núcleo — as actualizações do pfSense podem quebrar a compatibilidade do package. Verificar sempre o changelog do package WireGuard antes de actualizar o pfSense. Manter uma cópia da configuração do túnel (chaves incluídas) antes de qualquer upgrade.

8. IDS/IPS com Snort e Suricata

O pfSense não tem IDS/IPS nativo — depende de packages Snort ou Suricata, instalados via Package Manager (documentação de packages). Ambos inspectam tráfego com signatures (regras Emerging Threats, Talos/VRT) e podem operar em modo IDS (alerta) ou IPS (bloqueio inline via netmap no pfSense Plus ou divert no CE).

Diferenças entre Snort e Suricata no pfSense:

Critério Snort Suricata
Motor Snort 3.x Suricata 6/7
Multi-thread Limitado Nativo (uma thread por interface)
Performance Menor em débito alto Melhor em multi-core
Protocolos analisados Principalmente L3-L4 L3-L7 com parsing HTTP/HTTPS/DNS
IPS inline netmap/divert netmap (pfSense Plus)

Instalar e configurar Suricata (recomendado para hardware moderno):

  1. Navegar para System > Package Manager > Available Packages e instalar suricata
  2. Navegar para Services > Suricata > Interfaces e activar na interface WAN (e/ou LAN)
  3. Em Global Settings, configurar a fonte de regras: ET Open (Emerging Threats, gratuito) ou subscrição Talos
  4. Actualizar regras (Rules > Update) e seleccionar categorias (ex.: emerging-exploit, emerging-malware)
  5. Definir modo: IDS Mode (alerta) inicialmente; após validação, mudar para IPS Mode (drop/block)
  6. Configurar Drop/Reject para acções de alta confiança; manter Alert para regras experimentais

Para verificar o estado do Suricata via CLI:

# Estado do processo Suricata (running/stopped)
ps aux | grep suricata

# Logs de alertas Suricata (formato clog)
clog /var/log/suricata/suricata_alert.log | tail -20

Nota: Em modo IPS, o Suricata no pfSense Plus usa netmap para inspecção inline. Em pfSense CE, o modo IPS pode usar divert ou netmap consoante a versão. Testar sempre em modo IDS antes de activar bloqueio — regras mal afinadas bloqueiam tráfego legítimo e causam indisponibilidade.

9. Traffic Shaping: ALTQ, Limiters, PRIQ/CBQ/FAIRQ

O pfSense herda do FreeBSD duas abordagens para QoS: ALTQ (Alternate Queueing, integrado no pf) e Limiters (Dummynet, independentes do pf). A configuração é feita em Firewall > Traffic Shaper (documentação de traffic shaper).

ALTQ aplica-se por interface e usa schedulers (queues) que as regras de firewall referenciam. Existem três schedulers principais:

Scheduler Descrição Uso recomendado
PRIQ Múltiplas filas com prioridade estática (q1 > q2 > q3), sem largura de banda garantida Simples, quando só interessa prioridade relativa
CBQ Class-Based Queueing — garante largura de banda por classe e permite borrow entre classes Quando se quer garantir débito mínimo por classe
FAIRQ Fair Queueing — distribui largura de banda equitativamente entre fluxos Evitar starvation de fluxos lentos

Limiters (Dummynet): criados em Firewall > Traffic Shaper > Limiters, definem limites de banda (upload/download) independentes do ALTQ. Cada limiter tem uma máscara (source/destination) que permite limitar por IP ou por rede. As regras de firewall referenciam o limiter no campo In/Out Pipe.

Exemplo — limiter de 10 Mbps por host na LAN:

  1. Navegar para Firewall > Traffic Shaper > Limiters > New Limiter
  2. Configurar:
  • Name: LAN_10M
  • Bandwidth: 10 Mbit/s
  • Mask: Destination addresses (um limite por IP de destino)
  1. Criar regra em Firewall > Rules > LAN que referencia LAN_10M no campo In/Out Pipe

Para verificar as queues ALTQ e limiters carregados no pf:

# Listar queues ALTQ activas por interface
pfctl -s queue

# Listar limiters (Dummynet pipes) configurados
pfctl -s info | grep -A5 “queue”

⚠ Atenção

O ALTQ e os Limiters podem coexistir, mas a combinação mal configurada degrada o desempenho. Em interfaces com débito elevado (>1 Gbps), o ALTQ consome CPU significativa. Para limites simples por host, preferir Limiters (Dummynet) — são mais leves e previsíveis.

10. Alta Disponibilidade com CARP e pfsync

O pfSense implementa alta disponibilidade (HA) com CARP (Common Address Redundancy Protocol) para partilhar VIPs entre dois nós, pfsync para sincronizar o estado das ligações pf entre os nós, e XMLRPC Config Sync para replicar a configuração do nó primário para o secundário (documentação de HA).

Configurar HA (Primary → Backup):

  1. Em ambos os nós, atribuir uma interface dedicada ao pfsync (idealmente uma ligação directa entre os dois appliances — cabo crossover ou switch dedicado)
  2. No nó Primary:
  • System > High Availability > Settings:
  • Synchronize States: ON, interface pfsync, peer IP 172.16.0.2
  • Synchronize Config: ON, peer IP 172.16.0.2, username/password do backup
  • Seleccionar as secções a sincronizar (Firewall Rules, NAT, VIPs, Aliases, etc.)
  • Firewall > Virtual IPs: criar VIPs tipo CARP, interface WAN/LAN, com VHID único por VIP e advskew 0 (primário)
  1. No nó Backup: configurar pfsync na mesma interface, VHID idêntico mas advskew 100 (para que o backup só assuma se o primário falhar)
  2. Criar regras de firewall na interface pfsync que permitam protocolo 112 (CARP) e pfsync (UDP port 2400)

⚠ Atenção

O advskew determina quem é o master CARP. O valor mais baixo ganha. Se ambos os nós tiverem advskew 0, há split-brain (ambos se declaram master) e causam conflitos ARP. Garantir que o backup tem advskew superior ao primário (ex.: 100 vs 0).

Para verificar o estado CARP a partir da CLI:

# Mostrar estado dos VIPs CARP (MASTER/BACKUP)
ifconfig | grep carp

# Estado detalhado CARP por interface
ifconfig carp0

# Estado pfsync (sincronização de estados)
ifconfig pfsync0

# Verificar estados pf sincronizados
pfctl -ss | grep “carp”

11. Multi-WAN com Gateway Groups e Failover

O Multi-WAN no pfSense permite usar múltiplas ligações internet com failover automático ou load balancing, via gateway groups em System > Routing > Gateway Groups (documentação Multi-WAN).

Configurar failover WAN1 → WAN2:

  1. Garantir que ambas as WANs têm gateway configurado em System > Routing > Gateways (cada WAN aponta para o seu next-hop)
  2. Configurar Monitor IP para cada gateway (IP externo que o pfSense faz ping para detectar falha — ex.: 8.8.8.8 para WAN1, 1.1.1.1 para WAN2)
  3. Navegar para System > Routing > Gateway Groups > Add:
  • Name: WAN_Failover
  • Tier 1: WAN1 (primária)
  • Tier 2: WAN2 (secundária — só usada se WAN1 falhar)
  • Trigger Level: Member Down
  1. Criar regras de firewall em Firewall > Rules > LAN que usam WAN_Failover no campo Gateway (em vez de Default)
  2. Configurar NAT outbound para ambas as WANs (Hybrid Outbound NAT com regras para cada interface WAN)

Load balancing (Tier 1 em ambos): colocar ambas as WANs no mesmo Tier para distribuir tráfego round-robin. O pfSense usa sticky connections por defeito, garantindo que uma sessão permanece na mesma WAN.

Para que o failover funcione, o Monitor IP deve ser um IP que só responde via essa WAN. Se o monitor IP for o gateway da própria WAN, uma falha do ISP a montante (mas gateway respondendo) não é detectada. Usar IPs públicos externos distintos (ex.: 8.8.8.8 e 1.1.1.1).

Para monitorizar o estado dos gateways via CLI:

# Estado dos gateways (online/offline) — via WebGUI ou dpinger
pfctl -sr | grep “gateway”

# Tabela de rotas activas (verificar next-hop por WAN)
netstat -rn | grep default

# Verificar regras com gateway groups carregados
pfctl -sr | grep “route”

12. Troubleshooting na CLI (pfctl, ifconfig, clog)

O pfSense, sendo FreeBSD, oferece shell access via SSH (System > Advanced > Admin > Secure Shell) ou consola directa (opção 8 no menu inicial). Os comandos essenciais para diagnóstico são pfctl, ifconfig, netstat e clog (documentação de troubleshooting e routing).

# Estados das ligações pf activas (quem está ligado, de onde, para onde)
pfctl -ss

# Tabela de NAT activa (traduções em curso)
pfctl -s nat

# Estatísticas das interfaces (RX/TX, erros, colisões)
ifconfig -a

# Logs do filtro (firewall) — formato binário clog
clog /var/log/filterlog | tail -50

# Logs do sistema geral
clog /var/log/system.log | tail -100

# Tabela de rotas e gateways
netstat -rn

O clog é o leitor de logs circular do FreeBSD usado pelo pfSense — os logs em /var/log/ são binários (não texto), pelo que cat não funciona correctamente; é obrigatório usar clog.

O pfSense guarda logs em formato circular binário (clog) com tamanho fixo por defeito (~500 KB por log). Para aumentar, ir a Status > System Logs > Settings > Log File Size. Para troubleshooting prolongado, aumentar para 2-5 MB evita perda de eventos relevantes.

Reiniciar serviços sem reiniciar a appliance:

# Reiniciar o serviço pf (reload de regras sem cortar ligações estabelecidas)
pfctl -f /tmp/rules.debug

# Flush de estados (corta TODAS as ligações — usar com cuidado)
pfctl -F all

# Reiniciar o webConfigurator (WebGUI) se ficar irresponsivo
/etc/rc.restart_webgui

⚠ Atenção

O comando pfctl -F all remove todos os estados pf — corta instantaneamente todas as ligações em curso (VPN, SSH, sessões web). Usar apenas em manutenção agendada ou quando há estados stale a causar problemas.

13. Erros Comuns de Configuração

Os erros mais frequentes em implementações pfSense resultam de confundir a lógica first-match (interface tabs) com last-match (floating rules), esquecer regras de firewall associadas a port forwards, e problemas de CARP com advskew incorrecto.

Problema Causa Solução
Port forward não funciona Regra de firewall WAN em falta Activar Associated Filter Rule no port forward ou criar regra manual em Firewall > Rules > WAN com destination o IP interno
Tráfego bloqueado inesperadamente Floating rule block sobrepõe regra pass do tab da interface (last-match) Mover a floating rule para baixo ou removê-la; ou usar tabs de interface para regras críticas
CARP split-brain (ambos master) advskew igual nos dois nós Definir advskew 0 no primário e ≥100 no backup
WireGuard package desaparece após upgrade Package WireGuard incompatível com a nova versão pfSense Verificar changelog do package antes de upgrade; reinstalar package e reimportar configuração do túnel
Falha de failover multi-WAN não detectada Monitor IP é o gateway da própria WAN (não detecta falha a montante) Usar IPs públicos externos distintos como Monitor IP (ex.: 8.8.8.8 e 1.1.1.1)
DNS não resolve após mudar para Forwarder DNS Resolver ainda activo em simultâneo Desactivar DNS Resolver antes de activar DNS Forwarder (são mutuamente exclusivos)
Suricata bloqueia tráfego legítimo Regras em modo IPS/Drop mal afinadas Começar em modo IDS/Alert; analisar falsos positivos durante 1-2 semanas antes de activar Drop
Logs cortados / eventos perdidos Logs clog demasiado pequenos (500 KB) Aumentar Log File Size em Status > System Logs > Settings para 2-5 MB

14. Checklist Rápido de Verificação

  • [ ] Edição: Confirmar pfSense Plus (hardware Netgate) ou pfSense CE (whitebox/VM) e versão actualizada
  • [ ] Interfaces: WAN, LAN e OPT atribuídas; IPs e subnets correctos; interface pfsync dedicada para HA
  • [ ] VIPs: Tipo correcto (IP Alias para NAT 1:1, CARP para HA, Proxy ARP para IPs de terceiros)
  • [ ] Aliases: Criados para redes, hosts e portas; referenciados nas regras (em vez de IPs hardcoded)
  • [ ] Regras: Lógica first-match nos tabs de interface; floating rules verificadas (last-match) e ordenadas
  • [ ] NAT: Outbound automático ou hybrid; port forwards com Associated Filter Rule; 1:1 com VIP correspondente
  • [ ] VPN IPsec: IKEv2, AES-256-GCM, NAT-T activado se há NAT no percurso; Phase 2 com redes correctas
  • [ ] VPN OpenVPN: CA e certificado de servidor criados; regra WAN UDP 1194; clientes exportados
  • [ ] VPN WireGuard: Package instalado; chaves geradas; Allowed IPs correctos; regra WAN UDP 51820
  • [ ] IDS/IPS: Snort ou Suricata instalado; regras ET Open actualizadas; testado em modo IDS antes de IPS
  • [ ] QoS: ALTQ (PRIQ/CBQ/FAIRQ) ou Limiters configurados; testado impacto em CPU em interfaces de alto débito
  • [ ] CARP HA: pfsync activo; advskew 0 (primário) e ≥100 (backup); regras CARP/pfsync na interface de sincronização
  • [ ] Multi-WAN: Gateway groups com Monitor IP externo distinto; failover testado (desligar WAN1 e confirmar WAN2)
  • [ ] DNS: Resolver (Unbound) ou Forwarder (dnsmasq) — não ambos; DNSSEC/DoT se aplicável
  • [ ] Logs: Tamanho clog aumentado (2-5 MB); filterlog e system.log monitorizados
  • [ ] Backup: Config exportada em Diagnostics > Backup & Restore antes de qualquer alteração

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário