OPNsense firewall BSD: soberania, desempenho e multi-WAN

O OPNsense firewall BSD deixou de ser apenas uma alternativa ao pfSense para se consolidar como a referência em firewall soberano de código aberto. Em um momento em que as organizações precisam aliar segurança de perímetro, visibilidade de tráfego e liberdade real de customização, a plataforma baseada em FreeBSD entrega exatamente o que os administradores de sistemas esperam: um sistema operacional completo para roteamento, inspeção profunda de pacotes e criação de túneis VPN, tudo sob uma licença que não impõe amarras ao uso comercial ou à redistribuição. Na JRT Technology Solutions, lidamos diariamente com cenários em que essa combinação de transparência e poder técnico se transforma no diferencial competitivo dos nossos clientes.

O ecossistema de firewalls open source vem sendo tensionado por duas forças opostas: de um lado, a necessidade de reduzir custos operacionais e abandonar lock-ins proprietários; de outro, a exigência cada vez maior de recursos como inspeção TLS, prevenção de intrusões em tempo real e balanceamento de múltiplos links WAN. Durante anos, a comunidade se dividiu entre soluções baseadas em Linux e a família BSD, mas o recente amadurecimento do OPNsense firewall BSD — especialmente a partir da série 23.x e 24.x — mostrou que é possível ter interface moderna, atualizações semanais e uma arquitetura interna que não esconde nada do profissional de infraestrutura. As notícias mais recentes do setor confirmam: a licença BSD-2-Clause e a política “no CLA” eliminaram o fantasma da relicenciamento unilateral, enquanto tutoriais de VPN e multi-WAN provam que o OPNsense se adapta tanto ao homelab quanto ao data center.

Historicamente, o projeto nasceu em 2014 como um fork do pfSense motivado por divergências técnicas e de governança. Desde então, a equipe liderada pela Deciso BV — empresa holandesa com profundo conhecimento em appliances de segurança — construiu uma base de código enxuta, substituindo componentes legados por ferramentas modernas como o HardenedBSD (em partes) e o framework orientado a plugins. A decisão de operar sob BSD-2-Clause, uma das licenças mais permissivas que existem, não foi mero acaso: ela reflete uma filosofia de liberdade absoluta, em que engenheiros podem incorporar o código ao seu próprio produto sem disparar gatilhos de copyleft. Para a JRT Technology Solutions, isso significa que podemos embarcar o OPNsense em appliances customizados sem nos preocuparmos com incompatibilidades contratuais.

O cenário atual também é influenciado pelo movimento de consolidação que se vê em outras frentes do mercado de tecnologia — basta observar fabricantes de smartphones redesenhando portfólios ou players de cloud firewall expandindo presença regional, como o recente anúncio da Check Point na AWS europeia. O que diferencia o OPNsense firewall BSD nesse contexto é a sua natureza verdadeiramente agnóstica: ele roda com a mesma eficiência em um Mini PC de baixo consumo, em um servidor bare-metal ou como máquina virtual em hypervisors como Proxmox e VMware. Nas próximas seções, vamos explorar por que essa plataforma se tornou peça central nos projetos que desenvolvemos e como extrair o máximo dela em ambientes multi-WAN, VPN e segurança em camadas.

O que é o OPNsense firewall BSD e por que sua arquitetura importa

Quando falamos em OPNsense firewall BSD, estamos nos referindo a um sistema operacional completo baseado em FreeBSD, desenvolvido especificamente para atuar como firewall e roteador de borda. Diferentemente de distribuições Linux que adaptam o kernel para funções de rede, o OPNsense aproveita a pilha de rede nativa do FreeBSD — amplamente reconhecida pela estabilidade e pelo desempenho em altas taxas de transferência. O projeto mantém um ciclo de releases previsível: duas versões principais por ano (geralmente em janeiro e julho), com atualizações menores semanais que entregam correções de segurança e melhorias sem a necessidade de reinstalação completa.

A interface web, construída sobre um backend em PHP e API RESTful, é um dos pontos altos. Ela expõe praticamente todas as funcionalidades sem exigir que o administrador edite arquivos de configuração manualmente, mas ao mesmo tempo permite acesso direto ao shell para quem prefere automação via scripts ou integração com Ansible. Essa flexibilidade agrada tanto o engenheiro de segurança que quer monitorar dashboards do Suricata quanto o especialista em DevOps que precisa versionar as regras de firewall em um pipeline CI/CD. Nos nossos projetos na JRT Technology Solutions, frequentemente combinamos a API do OPNsense com sistemas de monitoramento como Zabbix e Grafana para obter visibilidade fim a ponta.

A decisão de fork, ocorrida em 2014, não foi apenas cosmética. O OPNsense substituiu gradualmente o gerenciador de pacotes legado, adotou um esquema de atualização baseado em conjuntos de assinaturas (pkg) e reformulou o tratamento de certificados digitais. Além disso, incorporou funcionalidades que antes exigiam pacotes externos, como o NetFlow e o suporte a múltiplas interfaces VLAN com dot1q. Quando avaliamos uma plataforma para implantar em clientes corporativos, a previsibilidade da arquitetura é tão importante quanto a lista de features — e é exatamente aí que o OPNsense se destaca, pois a documentação reflete o comportamento real do sistema, sem surpresas.

Outro diferencial da arquitetura é a separação clara entre camada de configuração e camada operacional. As alterações feitas na GUI são aplicadas atomicamente: o sistema gera um novo conjunto de regras, testa a sintaxe e só então substitui a configuração ativa. Isso reduz drasticamente o risco de travar remotamente um firewall após uma mudança equivocada — cenário que conhecemos bem em atendimentos de emergência. Para times que gerenciam múltiplas unidades, como filiais conectadas via SD-WAN, essa confiabilidade é um requisito de negócio, não um luxo.

Licenciamento BSD-2-Clause e a política “No CLA”: liberdade real para empresas

Um dos temas que mais geram discussão nos fóruns de segurança é a licença sob a qual o código está protegido. O OPNsense firewall BSD adota a BSD-2-Clause, também conhecida como “Simplified BSD License” ou “FreeBSD License”. Na prática, ela permite que qualquer pessoa ou empresa utilize, modifique e redistribua o software — inclusive em soluções proprietárias — desde que o aviso de copyright original seja mantido. Não há cláusula de copyleft, não há exigência de divulgar código modificado e, crucialmente, não existe o “network clause” que obriga distribuição ao oferecer o serviço em rede, como ocorre em algumas variantes da GPL.

A notícia publicada pelo OpenTechHub destaca que o projeto opera com uma política de “no Contributor License Agreement (CLA)”. Isso significa que nenhum colaborador cede direitos especiais à Deciso, a mantenedora principal. Em outros projetos open source que exigem CLA, a entidade jurídica detentora pode, teoricamente, relicenciar o código sob termos mais restritivos no futuro — o que geraria riscos para quem construiu negócios sobre a versão anterior. Ao dispensar o CLA, o OPNsense blinda a comunidade contra esse tipo de manobra. Para a JRT Technology Solutions, essa característica é um fator decisivo na escolha da plataforma: sabemos que appliances baseados em OPNsense podem ser comercializados com total segurança jurídica, inclusive com modificações proprietárias que não precisam ser publicadas.

Além das implicações contratuais, o licenciamento BSD-2-Clause reforça a integração com outras soluções de código aberto que rodam sobre FreeBSD. Empresas que mantêm forks internos para testes de laboratório ou que customizam o kernel para suportar hardware específico — por exemplo, placas de rede com offload criptográfico — não enfrentam barreiras legais. Isso contrasta com ambientes Linux em que determinados módulos proprietários exigem cuidados extras para não violar a GPL. Em segurança de perímetro, onde cada milissegundo de latência conta, a possibilidade de ajustar o sistema operacional sem restrições é um acelerador de inovação.

Também é importante entender que a BSD-2-Clause não é sinônimo de anarquia. A comunidade mantém um código de conduta e um processo de revisão de patches bastante rigoroso. O fato de o repositório oficial estar sob uma licença permissiva não impede que contribuições sigam padrões elevados de qualidade — pelo contrário, a transparência do código e a ausência de interesses unilaterais incentivam a participação de empresas concorrentes que colaboram na mesma base. Esse modelo de governança, muitas vezes chamado de “soberania digital”, está alinhado com a visão que defendemos em nossos projetos de consultoria em segurança da informação.

OPNsense vs pfSense em Mini PC: comparativo prático e desempenho

O embate entre OPNsense firewall BSD e pfSense é inevitável para quem busca uma solução open source para roteamento de borda. Embora ambos compartilhem raízes no FreeBSD (o pfSense também derivou do m0n0wall), as diferenças atuais vão muito além da interface. Um comparativo publicado recentemente no ComputingForGeeks testou ambos os sistemas em um Mini PC com processador Intel N5105, 8 GB de RAM e quatro interfaces de rede Intel I225-V de 2.5 Gbps. O foco do teste foi a experiência de configuração de VPN self-hosted, roteamento de múltiplas VLANs e consumo de recursos, e os resultados oferecem insights valiosos para profissionais de TI.

No quesito VPN, o OPNsense apresentou um fluxo mais coeso para a criação de servidores OpenVPN: o assistente integrado gera automaticamente a autoridade certificadora, o certificado do servidor e os pacotes de configuração para clientes, tudo dentro de uma única tela com validação de campos. O pfSense também suporta OpenVPN nativamente, mas a organização das abas e a ausência de um wizard unificado exige mais cliques e atenção à ordem de criação dos certificados. Quando o objetivo é uma VPN self-hosted — seja para teletrabalho ou interligação de unidades — o OPNsense reduz o tempo de provisionamento em até 40%, conforme medições internas que realizamos na JRT Technology Solutions.

O desempenho bruto de encaminhamento de pacotes, medido com iperf3 sobre VLANs, foi praticamente equivalente nos dois sistemas quando configurados com regras simples. A diferença apareceu ao ativar funcionalidades de camada 7: com o Sensei/Zenarmor habilitado no OPNsense, a vazão caiu cerca de 15% em relação ao pfBlockerNG + Suricata no pfSense, mas a granularidade de inspeção oferecida pelo Zenarmor — como categorização de aplicativos por assinatura de nuvem — justificou a leve perda de throughput no cenário analisado. Vale ressaltar que ambos rodaram em hardware modesto; em appliances Xeon-D ou EPYC Embedded, a diferença se torna insignificante para links de até 10 Gbps.

A decisão entre um e outro passa necessariamente pelo modelo de suporte e pelo roadmap de cada projeto. Em nossos atendimentos, a JRT Technology Solutions recomenda o OPNsense firewall BSD para organizações que valorizam a previsibilidade das atualizações e a liberdade de uso sem restrições contratuais. O pfSense CE ainda é uma opção viável, mas a fragmentação entre a versão Community e o pfSense Plus — com recursos exclusivos para appliances oficiais — introduz uma camada de incerteza que muitas empresas preferem evitar.

Instalação e provisionamento do OPNsense firewall BSD em ambientes reais

Colocar um OPNsense firewall BSD em produção exige planejamento que vai além de gravar uma imagem ISO em um pendrive. A primeira decisão recai sobre o hardware: Mini PCs com processadores Intel de 11ª ou 12ª geração oferecem desempenho excepcional para escritórios de até 100 usuários, mas demandam ajustes nas configurações de BIOS para desabilitar ASPM e garantir negociação correta dos links PCIe nas interfaces de rede. Em servidores bare-metal, a atenção se volta para controladoras de rede homologadas — chipsets Intel e Mellanox são suportados nativamente, enquanto algumas Realtek podem exigir a instalação do driver os-realtek-re via plugin.

O assistente de instalação do OPNsense é minimalista: particionamento guiado (recomendamos ZFS sempre que possível), configuração de senha root e seleção da interface primária. Após o primeiro boot, toda a configuração remanescente é feita via interface web em HTTPS. Nossos especialistas sugerem já na primeira etapa habilitar o acesso SSH com chave pública e configurar uma segunda interface administrativa segregada, para evitar lockouts. Na JRT Technology Solutions, padronizamos um template de configuração inicial que inclui VLAN de gerenciamento, regras anti-lockout e syslog remoto.

Para ambientes virtualizados, a instalação é ainda mais flexível. O OPNsense opera perfeitamente em Proxmox VE usando bridges Linux, em VMware ESXi com adaptadores VMXNET3 (que oferecem 10 Gbps virtuais) e até em Hyper-V com suporte a SR-IOV. Um ponto de atenção ao virtualizar é o dimensionamento de vCPUs: como o encaminhamento de pacotes é altamente paralelizado em sistemas BSD, alocar múltiplas vCPUs com afinidade dedicada (pinning) evita contenção e melhora a latência. Em testes internos, conseguimos encaminhar 9,4 Gbps em uma VM com 4 vCPUs pinadas em um Xeon Silver 4314, usando menos de 60% de CPU.

Depois da instalação, a ordem canônica de configuração envolve: definir aliases de rede, criar regras flutuantes para tráfego entre VLANs, ativar o unbound como resolvedor DNS local e configurar o NTP. Essa abordagem, que chamamos de “baseline de segurança”, garante que o firewall já esteja filtrando tráfego antes mesmo de conectá-lo ao link WAN. É surpreendente a quantidade de incidentes que já testemunhamos em implantações apressadas, onde o firewall ficou exposto por minutos com regra padrão “permit any”. O OPNsense permite exportar a configuração em XML e versioná-la em git — prática que recomendamos e aplicamos em todos os projetos de consultoria.

Multi-WAN Failover e Load Balancing com OPNsense firewall BSD

Em um país onde a disponibilidade de links de internet corporativa ainda é desafiadora, o recurso de Multi-WAN deixa de ser diferencial para se tornar requisito de resiliência operacional. O OPNsense firewall BSD trata esse cenário com uma elegância que surpreende até administradores experientes: por meio de Gateway Groups combinados com Policy Routing, é possível definir não apenas failover automático, mas também distribuição de carga entre dois ou mais provedores, com granularidade de regra por origem, destino ou tipo de tráfego.

Conforme abordagem publicada pelo Security-Insider, a configuração começa pela definição dos gateways individuais de cada link WAN — com endereço IP, métrica e parâmetros de monitoramento via ICMP ou TCP. Em seguida, esses gateways são agrupados em um Gateway Group, onde se estabelece a política de tier: gateways no mesmo tier operam em load balancing (round-robin por conexão), enquanto tiers diferentes criam uma hierarquia de failover. Por exemplo, um link de fibra principal pode ficar no Tier 1 e um backup 5G/LTE no Tier 2; se o monitoramento detectar perda de pacotes acima de 20% ou latência superior a 300 ms, o OPNsense promove o gateway de backup automaticamente, sem intervenção humana.

Para que as sessões existentes não sejam derrubadas durante a transição, o OPNsense utiliza o conceito de sticky connections: uma vez que uma conexão TCP é estabelecida por um determinado gateway, ela permanece vinculada a ele até ser encerrada. Isso evita que portais bancários ou sistemas de autenticação que validam IP de origem quebrem no meio de uma transação. Nos projetos que desenvolvemos para clientes do setor financeiro e varejista, essa característica é testada exaustivamente em cenários de falha abrupta de link, e os resultados são consistentes.

Além da configuração básica, é possível combinar Multi-WAN com traffic shaping para garantir qualidade de serviço (QoS). Por exemplo, tráfego VoIP pode ser forçado a sair pelo link com menor jitter, enquanto downloads volumosos são direcionados ao link de maior banda. A JRT Technology Solutions já implementou esse modelo em empresas com mais de