Redes · Firewall · OPNsense · FreeBSD · pf · WireGuard · OpenVPN · Suricata · CARP

Duarte Spínola · 25 de Junho de 2026

OPNsense 2026: Firewall, NAT, VPN e IDS — Guia Prático para PME

O OPNsense é uma firewall open-source baseada em FreeBSD e pf (packet filter), com uma interface web moderna, suporte nativo para WireGuard, e funcionalidades empresariais como Suricata IDS/IPS, CARP para alta disponibilidade e multi-WAN com failover automático. Ao contrário de firewalls comerciais (FortiGate, Palo Alto, Check Point), o OPNsense não tem custos de licenciamento — é gratuito, community-supported, e pode ser instalado em hardware x86 standard ou em VM. Para PME portuguesas que precisam de uma firewall robusta sem subscrições, o OPNsense é uma das opções mais populares. Este guia cobre as configurações principais: firewall rules e aliases, NAT, VPN (IPsec, WireGuard, OpenVPN), Suricata IDS/IPS, traffic shaping, multi-WAN, CARP HA e CLI troubleshooting. As fontes oficiais estão referenciadas inline, baseadas na documentação oficial em docs.opnsense.org.

Neste artigo

  1. Entender a Arquitectura do OPNsense
  2. Pré-requisitos e Conceitos Essenciais
  3. Passo 1 — Interfaces e Firewall Rules com Aliases
  4. Passo 2 — Configurar NAT (Outbound e Port Forward)
  5. Passo 3 — VPN IPsec Site-to-Site
  6. Passo 4 — VPN WireGuard para Teletrabalho
  7. Passo 5 — OpenVPN SSL para Acesso Remoto
  8. Passo 6 — Activar Suricata IDS/IPS
  9. Passo 7 — Multi-WAN com Failover e Load Balancing
  10. Passo 8 — Traffic Shaping e QoS
  11. Passo 9 — Alta Disponibilidade com CARP
  12. CLI Troubleshooting (pfctl, ifconfig, configd)
  13. Erros Comuns de Configuração
  14. Checklist Rápido de Verificação

1. Entender a Arquitectura do OPNsense

O OPNsense é um fork do pfSense (2014), baseado em FreeBSD e no packet filter pf — o motor de firewall que processe e filtra pacotes ao nível do kernel. A arquitectura é simples: uma só appliance gere interfaces de rede, firewall rules, NAT, VPN, DNS, DHCP e IDS/IPS. Não há separação entre management e gateway como no Check Point — toda a configuração é feita via interface web ou CLI (docs.opnsense.org).

Componentes principais:

Componente Função
pf (packet filter) Motor de firewall no kernel FreeBSD — processa regras, NAT e QoS
Interfaces Físicas (NIC) ou lógicas (VLAN, GRE, WireGuard, OpenVPN, CARP)
Aliases Objectos nomeados (IPs, redes, portas, URLs dinâmicas) reutilizáveis em regras
Gateways Next-hop routers — cada WAN é um gateway; grupos para failover/load balancing
Unbound DNS Resolver DNS local com filtering e DNS-over-TLS
Suricata IDS/IPS — inspeção de tráfego com signatures actualizadas
CARP Common Address Redundancy Protocol — HA entre duas OPNsenses

⚠ Atenção

O OPNsense usa FreeBSD, não Linux. Comandos como ip, iptables, ss não existem — os equivalentes são ifconfig, pfctl, sockstat. Adaptar a mentalidade de troubleshooting ao usar FreeBSD.

2. Pré-requisitos e Conceitos Essenciais

Interfaces — O OPNsense atribui interfaces lógicas (LAN, WAN, OPT1, OPT2…) a interfaces físicas (igb0, igb1, vmx0…). Cada interface tem um IP e subnet. VLANs podem ser criadas sobre interfaces físicas (ex.: igb0.10 = VLAN 10).

Aliases — Objectos nomeados que representam um ou mais IPs, redes, portas ou domínios. Em vez de escrever IPs directamente nas regras, criam-se aliases (ex.: Corp_LAN = 192.168.1.0/24) e usam-se nas regras. Isto torna a configuração legível e fácil de manter (OPNsense — Aliases).

Gateways e Gateway Groups — Cada interface WAN tem um gateway (next-hop router). Para multi-WAN, criam-se gateway groups que permitem failover ou load balancing entre múltiplas ligações internet (OPNsense — Gateways).

VIPs (Virtual IPs) — Endereços IP adicionais atribuídos a interfaces. Usados para: (1) CARP — IP virtual partilhado entre duas OPNsenses; (2) NAT — IP público para port forwarding; (3) Proxy ARP — responder por um IP que pertence a outro dispositivo (OPNsense — VIPs).

Apply/Reload — No OPNsense, a maioria das alterações na interface web faz reload automático das regras pf. Não há um botão “commit” separado como no Palo Alto ou Check Point.

3. Passo 1 — Interfaces e Firewall Rules com Aliases

A configuração de interfaces é o primeiro passo. Por defeito, o OPNsense vem com LAN (192.168.1.1/24) e WAN (DHCP). Para adicionar uma interface DMZ:

  1. Navegar para Interfaces > Assignments
  2. Atribuir a interface física (ex.: igb2) a OPT1
  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

Criar aliases para as redes:

  1. Navegar para Firewall > Aliases
  2. Criar aliases:
Nome Tipo Conteúdo
Corp_LAN Network 192.168.1.0/24
DMZ_Net Network 192.168.10.0/24
Web_Server Host 192.168.10.100
VPN_Subnet Network 10.10.50.0/24
HTTP_Services Port 80, 443
  1. Clicar Save (OPNsense — Firewall)

Criar regra outbound (LAN → WAN):

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

A última regra na lista é implícita — o OPNsense bloqueia tudo o que não foi explicitamente permitido (default deny).

⚠ Atenção

As regras no OPNsense são avaliadas de cima para baixo, primeira correspondência ganha. Colocar regras de deny específicas acima de regras de pass mais amplas. A regra default é implícita (não aparece na lista) — não é necessário criar uma regra “deny all” no fim.

4. Passo 2 — Configurar NAT (Outbound e Port Forward)

O OPNsense tem dois tipos de NAT: Outbound NAT (tradução de origem — clientes internos a aceder à internet) e Port Forward (tradução de destino — acesso externo a servidores internos) (OPNsense — NAT).

Outbound NAT (automático):

Por defeito, o OPNsense faz outbound NAT automático — todos os IPs internos são traduzidos para o IP da interface WAN. Não é necessário configurar nada para acesso básico à internet. Para personalizar:

  1. Navegar para Firewall > NAT > Outbound
  2. Mudar de Automatic para Hybrid Outbound NAT (permite regras manuais + automático)
  3. Adicionar regra customizada se necessário (ex.: usar um IP específico para um servidor)

Port Forward (ex.: servidor web interno acessível pela internet):

  1. Navegar para Firewall > NAT > Port Forward
  2. Adicionar regra:
  • Interface: WAN
  • Protocol: TCP
  • Source: any
  • Destination: WAN address
  • Destination Port Range: HTTP (80)
  • Redirect IP: 192.168.10.100 (servidor DMZ)
  • Redirect Port: 80
  • Check “Add associated filter rule”: ON (cria automaticamente a regra de firewall correspondente)
  1. Clicar Save e Apply Changes

Nota: Ao activar Add associated filter rule, o OPNsense cria automaticamente a regra de firewall que permite o tráfego encaminhado. Sem isto, seria necessário criar a regra manualmente em Firewall > Rules > WAN.

1:1 NAT (Static NAT — servidor com IP público dedicado):

Para mapear um IP público inteiro para um servidor interno (todas as portas):

  1. Criar uma VIP do tipo Proxy ARP ou Single Address para o IP público (Firewall > Virtual IPs)
  2. Navegar para Firewall > NAT > 1:1
  3. Adicionar regra:
  • Interface: WAN
  • External Subnet: 203.0.113.20/32 (IP público)
  • Internal Subnet: 192.168.10.100/32 (IP interno)
  1. Criar a regra de firewall correspondente em Firewall > Rules > WAN com destination = 192.168.10.100

5. Passo 3 — VPN IPsec Site-to-Site

A VPN IPsec site-to-site liga dois sites através de um túnel encriptado. O OPNsense suporta IKEv1 e IKEv2 (OPNsense — VPN).

Configuração no Site A (OPNsense A):

  1. Navegar para VPN > IPsec > 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: uma string aleatória de 32+ caracteres
  • Encryption Algorithm: AES-256-CBC
  • Hash Algorithm: SHA-256
  • DH Group: 14 (2048-bit) ou 20 (NIST P-384)
  • Lifetime: 28800 (8 horas)
  1. Navegar para VPN > IPsec > Phase 2 (adicionar nova Phase 2):
  • Mode: Tunnel
  • Local Network: 192.168.1.0/24 (subnet do Site A)
  • Remote Network: 192.168.2.0/24 (subnet do Site B)
  • Protocol: ESP
  • Encryption Algorithm: AES-256-CBC
  • Hash Algorithm: SHA-256
  • PFS (Perfect Forward Secrecy): ON, DH Group 14
  • Lifetime: 3600 (1 hora)
  1. Criar regras de firewall para tráfego VPN:
  • Navegar para Firewall > Rules > IPsec
  • Regra 1: Source 192.168.1.0/24 → Destination 192.168.2.0/24 → Pass
  • Regra 2: Source 192.168.2.0/24 → Destination 192.168.1.0/24 → Pass
  1. Activar a fase: em VPN > IPsec > Connections, clicar no botão de activar a ligação.

Configuração no Site B (espelhada):

Phase 1 idêntica (PSK, IKEv2, AES-256, SHA-256, DH 14). Phase 2 espelhada: Local Network = 192.168.2.0/24, Remote Network = 192.168.1.0/24.

⚠ Atenção

Se ambos os sites usam a mesma subnet (ex.: 192.168.1.0/24), o túnel IPsec não funciona. É necessário usar Binat (tradução de subnets) ou mudar a subnet de um dos sites. Verificar também que a porta UDP 500 e 4500 estão abertas no ISP/roteador a montante.

6. Passo 4 — VPN WireGuard para Teletrabalho

O OPNsense tem suporte nativo para WireGuard — uma VPN moderna, rápida e simples de configurar. É ideal para teletrabalho onde os utilizadores ligam individualmente à firewall (OPNsense — WireGuard).

Configuração do servidor WireGuard no OPNsense:

  1. Navegar para VPN > WireGuard > Servers:
  • Name: WG-Teletrabalho
  • Public Key: gerado automaticamente
  • Listen Port: 51820
  • Tunnel Address: 10.10.50.1/24 (subnet VPN)
  • Peers: adicionar cada utilizador com a sua chave pública e IP atribuído (ex.: 10.10.50.10/32)
  1. Para cada utilizador, gerar um par de chaves WireGuard:
# No computador do utilizador (Linux/macOS/Windows)
wg genkey | tee privatekey | wg pubkey > publickey

A chave pública vai para a configuração do servidor (campo Peers); a chave privada fica no cliente.

  1. Criar regra de firewall para tráfego WireGuard:
  • Navegar para Firewall > Rules > WireGuard (interface criada automaticamente)
  • Regra: Source VPN_Subnet (10.10.50.0/24) → Destination Corp_LAN (192.168.1.0/24) → Pass
  1. Abrir a porta UDP 51820 na WAN (Firewall > Rules > WAN):
  • Source: any
  • Destination: WAN address
  • Destination Port: 51820 UDP
  • Action: Pass

Configuração do cliente (utilizador remoto):

O utilizador configura o cliente WireGuard (wg-quick, app oficial WireGuard para Windows/macOS/iOS/Android) com:

[Interface]
PrivateKey =
Address = 10.10.50.10/24
DNS = 192.168.1.1

[Peer]
PublicKey =
Endpoint = vpn.empresa.pt:51820
AllowedIPs = 192.168.1.0/24
PersistentKeepalive = 25

O campo AllowedIPs define o split tunnel — apenas o tráfego para 192.168.1.0/24 vai pelo túnel; o resto vai directamente pela internet do utilizador.

Nota: O WireGuard não tem autenticação de utilizador — a autenticação é baseada nas chaves criptográficas. Cada peer tem um par de chaves, e a chave pública tem de estar registada no servidor. Para revogar acesso, remover a chave pública da lista de peers. Para maior segurança, usar WireGuard com PSK (pre-shared key adicional por peer).

7. Passo 5 — OpenVPN SSL para Acesso Remoto

Para ambientes que precisam de VPN SSL tradicional (com autenticação de utilizador, suporte para certificados, compatibilidade com clientes empresariais), o OpenVPN é a alternativa ao WireGuard (OPNsense — OpenVPN).

Configuração do servidor OpenVPN:

  1. Navegar para VPN > OpenVPN > Wizards:
  • Type: Server
  • Protocol: UDP on IPv4
  • Interface: WAN
  • Local Port: 1194
  • Certificate Authority: criar ou seleccionar CA existente
  • Server Certificate: criar certificado para o servidor
  • Tunnel Network: 10.10.60.0/24 (subnet VPN)
  • Remote Network: 192.168.1.0/24 (rede interna)
  • DNS Default Domain: empresa.local
  • Authentication: Local Database ou LDAP/AD
  1. Criar utilizadores VPN em System > Access > Users:
  • Adicionar utilizador com password e certificado (se usar autenticação por certificado)
  1. Criar regras de firewall:
  • Firewall > Rules > WAN: permitir UDP 1194 de any para WAN address
  • Firewall > Rules > OpenVPN: permitir tráfego de 10.10.60.0/24 para 192.168.1.0/24
  1. Descarregar a configuração do cliente em VPN > OpenVPN > Client Export — o OPNsense gera ficheiros .ovpn prontos a importar no cliente OpenVPN.

8. Passo 6 — Activar Suricata IDS/IPS

O Suricata é um motor IDS/IPS que inspeciona tráfego em tempo real, detectando e prevenindo ataques conhecidos. O OPNsense tem Suricata integrado como plugin (OPNsense — IPS).

Configuração:

  1. Navegar para Services > Intrusion Detection > Administration
  2. Activar Enabled
  3. Em Interfaces, seleccionar as interfaces a inspecionar (WAN e LAN)
  4. Em Rules, descarregar e activar os rulesets:
  • ET Open (Emerging Threats Open) — gratuito, actualizado diariamente
  • ET Pro (requer subscrição) — mais completo
  • Snort Community Rules — alternativo gratuito
  1. Configurar o modo:
  • IDS Mode (Alert): apenas gera alertas, não bloqueia tráfego — recomendado para começar
  • IPS Mode (Drop): bloqueia tráfego malicioso — activar após 1-2 semanas em IDS para identificar falsos positivos
  1. Clicar Save e Apply

Alertas e logs:

  1. Navigar para Services > Intrusion Detection > Alerts para ver alertas em tempo real
  2. Configurar notificações por email em System > Settings > Notifications se necessário

⚠ Atenção

Activar Suricata em modo IPS pode degradar performance em hardware modesto. Monitorizar o uso de CPU e memória após activar. Se a firewall não tiver hardware suficiente, considerar IDS Mode (apenas alertas) em vez de IPS Mode (bloqueio activo).

9. Passo 7 — Multi-WAN com Failover e Load Balancing

Para PME com duas ligações internet (ex.: fibra + 4G/5G), o OPNsense suporta multi-WAN com failover automático e/ou load balancing (OPNsense — Multi-WAN).

Configuração:

  1. Configurar ambas as interfaces WAN (WAN1 = fibra, WAN2 = 4G/5G ou cabo)
  2. Navegar para System > Gateways > Single:
  • Verificar que cada WAN tem um gateway configurado com o IP do next-hop
  • Activar Gateway Monitoring (ping a um IP externo para detectar falhas)
  1. Navegar para System > Gateways > Group:
  • Criar grupo WAN_Failover:
  • Tier 1: WAN1 (fibra) — prioridade mais alta
  • Tier 2: WAN2 (4G) — fallback
  • Trigger Level: Packet Loss ou Latency
  1. Nas regras de firewall (Firewall > Rules > LAN), definir o gateway do grupo em Gateway:
  • Para regras que devem usar failover, seleccionar o grupo WAN_Failover
  • Para regras que devem usar sempre uma WAN específica (ex.: VPN), seleccionar o gateway individual

Load Balancing:

Para distribuir tráfego entre duas WANs (não só failover), criar um grupo com ambas as WANs no mesmo Tier 1. O OPNsense distribui o tráfego round-robin entre os gateways do mesmo tier.

10. Passo 8 — Traffic Shaping e QoS

O OPNsense tem dois motores de traffic shaping: ALTQ (tradicional, baseado em pf) e Limiters (baseado em dummynet, mais flexível) (OPNsense — Shaping).

Configurar QoS para priorizar VoIP:

  1. Navegar para Firewall > Traffic Shaper
  2. Criar um pipe (limiter) para a WAN:
  • Name: WAN_Up
  • Bandwidth: 20 Mbps (upload real da WAN)
  1. Criar um pipe para download:
  • Name: WAN_Down
  • Bandwidth: 100 Mbps (download real)
  1. Criar queues dentro dos pipes:
  • Queue 1: VoIP — 5 Mbps garantidos, prioridade 7 (highest)
  • Queue 2: Default — resto, prioridade 3
  1. Aplicar o shaper a regras de firewall:
  • Na regra de tráfego VoIP (ex.: UDP 5060-5061 + 10000-20000), seleccionar o queue VoIP na coluna Out/In Pipe

Nota: O traffic shaping só funciona correctamente se as bandwidths dos pipes reflectirem a realidade da ligação. Se o pipe estiver configurado para 100 Mbps mas a ligação real for 50 Mbps, o QoS não consegue priorizar correctamente — o buffer da linha satura antes do shaper actuar.

11. Passo 9 — Alta Disponibilidade com CARP

O CARP (Common Address Redundancy Protocol) é o equivalente FreeBSD ao VRRP — permite que duas OPNsenses partilhem um IP virtual. Se a firewall primária cai, a secundária assume em segundos (OPNsense — CARP, How-to CARP).

Configuração:

  1. Em ambas as OPNsenses, configurar System > High Availability:
  • Synchronize Configurations to Peer: ON
  • Synchronize Peer IP: IP da firewall peer (ex.: 192.168.255.2)
  • Synchronize via Interface: LAN (ou interface dedicada de sync)
  • Remote Root Username/Password: credenciais do peer
  1. Criar VIPs do tipo CARP para cada interface:
  • WAN: VIP CARP com IP público virtual (ex.: 203.0.113.10)
  • LAN: VIP CARP com IP interno virtual (ex.: 192.168.1.1 — o IP que os clientes usam como gateway)
  • Advertisement Skew: 0 no primário, 100 no secundário (define quem é master)
  1. Activar pfsync (sincronização de state table entre firewalls):
  • System > High Availability > pfsync Synchronize States: ON
  • Interface: interface dedicada de sync (recomendado) ou LAN
  1. Sincronizar regras, aliases e configurações via XMLRPC:
  • O OPNsense sincroniza automaticamente a configuração para o peer quando se faz alterações

⚠ Atenção

O CARP requer que ambas as firewalls tenham interfaces na mesma broadcast domain (Layer 2). Se as WANs estão em switches diferentes sem bridging, o CARP não funciona na WAN — considerar usar um router a montante que suporte VRRP. Para o pfsync, usar uma interface dedicada (ex.: um cabo directo entre as duas firewalls) — não usar a interface de gestão.

12. CLI Troubleshooting (pfctl, ifconfig, configd)

O OPNsense corre em FreeBSD, pelo que os comandos de troubleshooting são diferentes de Linux. Os comandos mais úteis em expert mode (ou SSH):

pfctl — inspecionar regras pf e NAT:

# Ver todas as regras pf carregadas
pfctl -sr

# Ver regras NAT
pfctl -sn

# Ver tabela de estados (conexoes activas)
pfctl -ss

# Resumo de estados
pfctl -s info

# Ver tabelas (aliases carregados no pf)
pfctl -t Corp_LAN -T show

# Ver limiters/queues de QoS
pfctl -sq

# Flush de estados (cuidado: derruba todas as conexoes)
pfctl -F all

ifconfig — estado das interfaces:

# Todas as interfaces
ifconfig

# Interface especifica
ifconfig igb1

# Interfaces CARP
ifconfig carp0

# Levantar/derrubar interface
ifconfig igb1 up
ifconfig igb1 down

configd — backend do OPNsense:

# Reiniciar configd (backend de configuracao)
configdctl restart

# Executar acao do configd
configdctl template reload OPNsense

Logs do sistema:

# Logs do firewall em tempo real
tail -f /var/log/filter/latest.log

# Logs do OpenVPN
tail -f /var/log/openvpn/latest.log

# Logs do IPsec
tail -f /var/log/ipsec/latest.log

# Logs do Suricata
tail -f /var/log/suricata/latest.log

# Logs do sistema (messages)
tail -f /var/log/system/latest.log

Diagnósticos de rede:

# Tabela de routing
netstat -rn

# ARP table
arp -an

# Conexoes activas (sockets)
sockstat -4

# Testar DNS
dig @192.168.1.1 kbase.pt

# Ping para um gateway externo
ping 8.8.8.8

# Traceroute
traceroute 8.8.8.8

💡 Nota

O fluxo de troubleshooting recomendado é: (1) pfctl -sr para ver as regras activas; (2) pfctl -ss para ver se a conexão aparece na state table; (3) tail -f /var/log/filter/latest.log para ver se o tráfego está a ser bloqueado; (4) netstat -rn para confirmar que o routing está correcto; (5) ifconfig para verificar estado das interfaces e CARP.

13. Erros Comuns de Configuração

Problema Causa Solução
Sem internet após configurar WAN Gateway errado ou ISP bloqueia ping de monitoring Verificar System > Gateways que o gateway IP está correcto. Desactivar gateway monitoring temporariamente
VPN IPsec não estabelece Mismatch de IKE parameters entre os dois peers Garantir que Phase 1 e Phase 2 são idênticos. Verificar portas UDP 500/4500 abertas
Port forward não funciona Falta regra de firewall na interface WAN Marcar Add associated filter rule ao criar o port forward, ou criar regra manual em Firewall > Rules > WAN
WireGuard liga mas não acede à LAN Falta regra na interface WireGuard Criar regra Pass em Firewall > Rules > WireGuard: Source VPN_Subnet → Destination Corp_LAN
CARP não faz failover Interfaces CARP em broadcast domains diferentes ou skew errado Garantir que ambas as firewalls estão no mesmo L2. Verificar advertisement skew: 0 no master, 100 no backup
Multi-WAN não faz failover Gateway monitoring desactivado ou IP de monitoring inatingível Activar gateway monitoring. Usar um IP fiável (ex.: 8.8.8.8) como monitoring target
QoS não prioriza VoIP Bandwidth dos pipes errada (superior à real) Definir bandwidth dos pipes = bandwidth real da ligação. Se a linha satura antes do shaper, QoS não funciona
Suricata bloqueia tráfego legítimo Falsos positivos em modo IPS Mudar para IDS Mode (apenas alertas). Analisar alertas e suprimir rules problemáticas. Depois voltar a IPS
DNS não resolve nomes internos Unbound não configurado para DNS local Configurar Host Overrides em Services > Unbound DNS > Overrides para nomes internos
OpenVPN não conecta Certificado inválido ou porta 1194 bloqueada Verificar certificado CA e servidor. Verificar porta UDP 1194 aberta na WAN e no ISP

14. Checklist Rápido de Verificação

  • [ ] Configurar interfaces WAN, LAN e DMZ com IPs correctos
  • [ ] Criar aliases para todas as redes e servidores (Corp_LAN, DMZ_Net, Web_Server)
  • [ ] Verificar que outbound NAT está activo (automático ou hybrid)
  • [ ] Criar regra Pass em LAN para tráfego outbound com gateway correcto
  • [ ] Verificar default deny implícito (não é necessário criar regra deny all)
  • [ ] Criar port forwards para serviços publicados com Add associated filter rule
  • [ ] Configurar VPN IPsec com IKEv2, AES-256, SHA-256, PFS DH Group 14+
  • [ ] Configurar WireGuard para teletrabalho (chaves por peer, split tunnel)
  • [ ] Abrir porta UDP 51820 (WireGuard) na WAN
  • [ ] Configurar OpenVPN com certificados se for necessário SSL VPN tradicional
  • [ ] Activar Suricata em IDS Mode primeiro, migrar para IPS após 1-2 semanas
  • [ ] Configurar multi-WAN com gateway groups para failover
  • [ ] Activar gateway monitoring (ping a IP externo) para detectar falhas
  • [ ] Configurar traffic shaping com bandwidths reais da ligação
  • [ ] Priorizar VoIP com queue dedicado (5 Mbps garantidos)
  • [ ] Configurar CARP VIPs para WAN e LAN se houver duas OPNsenses
  • [ ] Activar pfsync em interface dedicada para sincronização de estados
  • [ ] Activar XMLRPC sync para sincronizar configuração entre firewalls
  • [ ] Configurar Unbound DNS com Host Overrides para nomes internos
  • [ ] Verificar com pfctl -sr e pfctl -ss que as regras e estados estão correctos

Artigos Relacionados

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário