OPNsense no Homelab Proxmox: 9 ajustes que faço em todo firewall

Todo mundo que me acompanha sabe que eu não gosto de rede "temporizada". Aquele esquema onde tudo funciona até o dia em que o vizinho conecta uma câmera chinesa na sua rede e o mundo desaba. Se você roda um homelab de verdade — ou uma PME que leva a infra a sério —, o roteador que a operadora te emprestou não é firewall: é um buraco com Wi-Fi.

Há um tempo decidi parar de fingir que o roteador da operadora era suficiente e subi um OPNsense como VM dentro do meu cluster Proxmox. Foi uma das melhores decisões de toda a minha jornada de homelab: tenho um firewall de nível enterprise, com snapshots, backup automático e zero hardware dedicado. O segredo não está na instalação em si (que é trivial), e sim no que você ajusta depois que o wizard fecha.

Neste post mostro a topologia que uso para virtualizar o OPNsense no Proxmox e os 9 ajustes de produção que aplico em todo firewall novo — mesmo que seja "só" um laboratório.

Por que OPNsense e não o roteador da operadora?

O aparelho que a Vivo, Claro ou TIM te empresta faz NAT, DHCP e um pedaço de firewall stateful — mas você não controla nada. Não tem visibilidade de logs, não tem segmentação real, não tem DNS próprio. O OPNsense é código aberto, baseado no FreeBSD/HardenedBSD, e entrega recursos que você só veria em um Palo Alto ou Fortinet de 5 dígitos: aliases, regras stateful por interface, DNS recursivo, gateway monitoring, IDS/IPS, VPN. E roda liso em 2 núcleos e 2 GB de RAM.

A cereja: rodando como VM no Proxmox, você ganha snapshot antes de mexer em regra arriscada, backup via Proxmox Backup Server e a possibilidade de clonar o firewall inteiro pra testar uma configuração nova.

Fundação: OPNsense como VM no Proxmox

A topologia que eu uso é a clássica de firewall virtualizado. O truque está em separar WAN e LAN em bridges diferentes do Proxmox:

VLANs (Mgmt/Server/IoT/Guest)

Se você tem apenas uma NIC física, dá pra separar WAN e LAN por VLAN — mas duas interfaces é muito mais simples para a primeira vez. Passo a passo enxuto:

1. Bridges no Proxmox: Node → Network → Create → Linux Bridge. Crie vmbr0 (WAN, com a NIC física em "Bridge ports", sem CIDR) e vmbr1 (LAN, bridge ports vazio, CIDR 192.168.1.1/24 se quiser o próprio Proxmox nesta rede). Aplique.
2. ISO: baixe a DVD image em opnsense.org/download e suba em Storage → local → ISO Images.
3. VM: 2 cores com CPU type: host, 2048 MB (4 GB se for rodar IDS/IPS), disco 16 GB VirtIO SCSI, duas interfaces VirtIO — WAN em vmbr0, LAN em vmbr1.
4. Install: boot pelo ISO, usuário installer / senha opnsense, instale em UFS (mais simples pra VM) e reboot.
5. Assign interfaces: no console, opção 1 — WAN = vtnet0, LAN = vtnet1. Opção 2 — LAN 192.168.1.1/24, DHCP 192.168.1.100-200.
6. Wizard: acesse https://192.168.1.1 (root/opnsense) e passe pelo setup. Troque a senha na hora.
7. Snapshot: antes de qualquer ajuste, VM → Snapshots → Take com nome fresh-install. Ponto de restauração salvo.

Pronto. Firewall no ar. Mas é aqui que a maioria para — e é exatamente aqui que o trabalho começa.

Os 9 ajustes que faço em todo firewall

1. Hostname e domínio local

Pare de usar nomes de Star Trek na sua rede. Dê um hostname significativo: fw01.home.arpa, opnsense01.lab.example.com. Use home.arpa para domínios puramente privados — e evite .local: ele colide com multicast/Bonjour e causa dor de cabeça silenciosa.

System > Settings > General
  Hostname: fw01
  Domain:   home.arpa

Parece bobagem, mas quando você começa a usar certificados, renovos automáticos e scripts, um esquema de nomes coerente salva sua sanidade.

2. Unbound como resolver recursivo (e DNS-over-TLS)

O OPNsense já traz o Unbound. Eu não encaminho tudo pro DNS da operadora — configuro como resolver recursivo e, quando quero privacidade, subo as consultas por DNS-over-TLS para um upstream confiável (Cloudflare 1.1.1.1 ou Google 8.8.8.8).

Services > Unbound DNS > General
  Enable: yes
  DNSSEC: yes

Services > Unbound DNS > Query Forwarding (opcional, p/ DoT)
  Encaminhe para 1.1.1.1 / 8.8.8.8

Com host overrides você resolve pve01.home.arpa → 192.168.20.11 localmente. Controle total de como os nomes respondem dentro da sua rede.

3. Aliases para simplificar as regras

Regra de ouro: nunca coloque IPs soltos nas regras de firewall. Crie aliases. Em vez de repetir 192.168.20.11, .12, .13 em dez regras, crie PROXMOX_HOSTS e referencie o alias. Adicionou um nó novo? Você muda só o alias.

Firewall > Aliases
  PROXMOX_HOSTS   -> 192.168.20.11, 192.168.20.12
  WEB_PORTS       -> 80, 443
  DNS_SERVERS     -> 192.168.20.10

4. Segmentação por VLAN

Esse é o ponto onde a maioria dos homelabs quebra. Não trate tudo como uma única LAN confiável. Eu crio zonas: Management, Server, Client, IoT, Guest, Storage, Lab. Já escrevi um artigo inteiro sobre a anatomia disso — gestão de redes e VLANs do caos ao controle — então não vou reinventar a roda aqui. O OPNsense cria as interfaces VLAN em Interfaces > Devices > VLAN e vira o gateway de cada zona.

VLAN	Propósito
Management	Hypervisors, switches, interfaces de gerência
Server	VMs, containers e serviços
Client	Notebooks, celulares, desktops
IoT	Câmeras, smart devices (menos confiável)
Guest	Wi-Fi de visita, só Internet
Storage	NAS, iSCSI, NFS
Lab	Rede isolada para testes arriscados

5. Regras inter-VLAN específicas (nada de "LAN → any")

Instalação nova vem com LAN net → any. Funciona, mas é preguiça. O OPNsense é stateful: se o tráfego origina na interface Client e vai pra Internet, eu olho as regras da interface Client. Exemplo real:

CLIENT_NET -> DNS_SERVERS        TCP/UDP 53   allow
CLIENT_NET -> INTERNET           80,443       allow
IOT_NET    -> SERVER/MGMT        block
GUEST_NET  -> (tudo interno)     block

Dica de ouro: coloque descrição em toda regra. "Allow câmeras → Frigate" salva você de apagar a regra errada meses depois.

6. Logging seletivo

Não ligue log em toda regra de pass — vira ruído. Eu logo as regras de block (é onde estão as respostas: "por que a câmera tentou falar com o servidor?"). Firewall > Log Files > Live View é seu melhor amigo na hora de debugar.

7. Gateway monitoring (e multi-WAN)

Se você tem link de redundância — e eu defendo redundância onde a internet é crítica, como já falei no artigo de failover inteligente — configure o monitoramento de gateway. Não use o IP do próprio gateway da operadora como alvo de ping: ele responde mesmo quando o upstream tá morto. Use 1.1.1.1 ou 8.8.8.8 como monitor.

System > Gateways > Single
  Monitor IP: 1.1.1.1

8. Hardware offloading em firewall virtualizado (esse é o seu)

Aqui está o ajuste que a galera que roda OPNsense bare metal esquece e quem virtualiza no Proxmox paga caro. Quando o firewall roda como VM, o offloading de hardware da placa de rede atrapalha: checksum, TSO e LRO feitos pela virtio podem gerar pacotes quebrados e latência estranha. Desabilite os três.

Interfaces > Settings
  [x] Disable hardware checksum offload
  [x] Disable hardware TCP segmentation offload (TSO)
  [x] Disable hardware large receive offload (LRO)

É contra-intuitivo — "hardware" soa como "mais rápido" — mas em firewall virtualizado esse trio é fonte de bugs silenciosos. Anote aí.

9. Atualizações automáticas

Firewall desatualizado é firewall comprometido. Configuro um cron pra aplicar firmware automaticamente:

System > Settings > Cron > +
  Command: Automatic firmware update
  Schedule: diário, madrugada

Já fiquei semanas com uma instalação velha que parava de falar com plugins novos. Nunca mais.

Fechamento: o que vem depois

Com esses 9 ajustes você tem um firewall de verdade, segmentado e observável — rodando como VM no Proxmox, com snapshot e backup (veja como faço backup de LXC/VM no PBS). A partir daqui o caminho natural é subir Suricata para IDS/IPS, uma VPN WireGuard pra acesso remoto, e refinar as regras por zona.

Se você ainda está no roteador da operadora, esse é o melhor final de semana pra mudar. E se quiser que eu escreva a parte 2 (Suricata + WireGuard na prática), comenta no LinkedIn ou me manda um direct por lá — me encontra em linkedin.com/in/alexandreponce.