Hardware e appliances para pfSense: como dimensionar sem errar

O erro clássico é dimensionar pfSense olhando só a velocidade do link. Firewall stateful puro é leve, e um hardware modesto empurra vários gigabits sem suar. O peso aparece quando entram as funções que processam o tráfego: VPN com criptografia, IDS e IPS inspecionando pacote a pacote, proxy e filtragem por listas. Cada uma dessas cobra CPU e memória.

O caminho certo é somar o que o ambiente vai usar de verdade. Um firewall que só roteia e filtra pede pouco. O mesmo firewall com VPN de volume, Suricata ligado e pfBlockerNG com várias listas é outra história. Dimensionar pela carga real, e não pelo link, é o que evita tanto o desperdício quanto o gargalo.

A CPU é o recurso mais exigido pelas funções pesadas. VPN e inspeção de tráfego consomem ciclos de processamento, e é aí que o dimensionamento certo faz diferença. Um detalhe importante: o pfSense moderno exige processadores com AES-NI, a instrução que acelera a criptografia em hardware. Sem ela, a VPN fica lenta e cara em CPU.

Para ambientes com VPN de volume, a aceleração de criptografia deixa de ser um luxo. Ela permite que o mesmo processador entregue muito mais throughput cifrado, o que muda o dimensionamento necessário. Além do AES-NI, alguns appliances Netgate trazem a aceleração Intel QuickAssist (QAT), que ajuda IPsec e OpenVPN em cargas maiores. Vale lembrar que o WireGuard não depende dessa aceleração da mesma forma, porque usa algoritmos como ChaCha20 que já são eficientes em CPU. Contar com AES-NI é o que mantém a VPN rápida sem inflar o custo do equipamento.

A memória do pfSense é consumida por duas frentes principais. A tabela de estados (state table) guarda cada conexão ativa, então ambientes com muitos usuários e muitas sessões simultâneas pedem mais RAM. O limite dela é configurável em System > Advanced > Firewall & NAT, no campo Firewall Maximum States, e por padrão o pfSense o calcula a partir da memória disponível. Os pacotes que trabalham com listas, como o pfBlockerNG, carregam dados na memória, o que soma conforme você ativa mais feeds.

Subdimensionar memória gera instabilidade difícil de diagnosticar: o firewall funciona bem em teste e engasga sob carga real. Dar folga de memória é barato e evita esse tipo de problema. Como referência, ambientes corporativos raramente ficam confortáveis com menos do que alguns gigabytes, e cresce a partir daí conforme estados e pacotes.

O pfSense não precisa de muito espaço para o sistema em si, mas os logs se acumulam, principalmente com IDS, IPS e monitoramento detalhado ligados. Um armazenamento confortável evita que o firewall precise apagar registro cedo demais, o que atrapalha investigação de incidente. Discos de estado sólido também favorecem a longevidade e a resposta do equipamento.

Onde a disponibilidade é crítica, o ZFS ajuda pela integridade de dados e pela recuperação mais previsível. Em appliances de produção, vale considerar redundância de armazenamento conforme o risco que a empresa aceita correr. O disco não é o componente que puxa o desempenho, mas é o que guarda a evidência quando algo dá errado.

A placa de rede é subestimada e decisiva. Interfaces Intel, com os drivers igb para gigabit e ix para dez gigabit, são as mais maduras no FreeBSD e evitam perda de pacote, travamento sob carga e comportamento errático que consomem horas de diagnóstico. Placas de baixo custo com chipset Realtek costumam dar mais problema sob tráfego intenso. Economizar na placa de rede costuma sair caro em dor de cabeça depois.

A quantidade e a velocidade das interfaces seguem o projeto: uma para cada link de WAN, uma para a LAN e as demais para segmentação, DMZ e outras redes. Onde há Multi-WAN, VLANs e segmentação, o número de interfaces, físicas ou lógicas, entra no dimensionamento junto com a velocidade que cada uma precisa sustentar.

A edição Community Edition é aberta, gratuita e adequada para uso corporativo, rodando em hardware compatível e em máquinas virtuais. A edição pfSense Plus é otimizada para os appliances Netgate e acompanha esse hardware, com alguns recursos e ajustes próprios. A escolha entre as duas se mistura com a escolha do hardware.

Para quem prioriza flexibilidade e custo, hardware próprio com a Community Edition é um caminho sólido. Para quem prioriza validação de fabricante, suporte oficial e previsibilidade, o appliance Netgate com pfSense Plus faz sentido. Não há resposta única: depende do que a empresa valoriza e de quanto quer terceirizar a responsabilidade pelo hardware.

Dimensionar hardware errado custa caro dos dois lados: no desperdício de uma máquina grande demais ou no gargalo de uma pequena demais. A OpenSourceBrasil faz esse dimensionamento dentro da consultoria pfSense, calculando CPU, memória, armazenamento e interfaces pela carga real do ambiente, e ajudando a decidir entre appliance, hardware próprio e virtualização conforme o cenário.