NAT é um daqueles temas que parecem simples até a hora de publicar um serviço e o acesso não funcionar, ou funcionar demais. No pfSense existem vários tipos de NAT, cada um para um problema diferente. Entender qual usar, e o que cada regra abre de verdade, evita tanto a frustração de "não conecta" quanto o risco silencioso de deixar um serviço exposto sem perceber.
Este guia explica o NAT de saída, o port forward, o NAT 1:1 e o NAT reflection, com foco em publicar serviços de forma controlada. A ideia não é decorar telas, e sim entender o que acontece com o pacote para você decidir com segurança.
O que é NAT, sem complicar
NAT é a tradução de endereços de rede. Como os IPs internos privados não trafegam na internet, o firewall troca o endereço de origem dos pacotes que saem pelo IP público da WAN, e desfaz essa troca na volta. É por isso que uma rede inteira consegue acessar a internet por um único endereço público. No pfSense isso acontece de forma automática assim que a LAN é configurada.
O ponto que confunde é que NAT e firewall são coisas distintas que trabalham juntas. O NAT decide como o endereço é reescrito. A regra de firewall decide se o pacote passa. Publicar um serviço bem feito envolve os dois, e é aí que mora a maioria dos erros.
NAT de saída (outbound)
O NAT de saída controla como o tráfego interno é mascarado ao sair pela WAN. Por padrão, o pfSense opera em modo automático e cuida disso sozinho, o que atende à maioria dos ambientes. Você só precisa mexer nisso em cenários específicos, como múltiplos IPs públicos, VPNs que exigem que certo tráfego não seja mascarado ou situações de roteamento mais elaboradas.
Nesses casos, o modo híbrido é o mais prático: o pfSense mantém as regras automáticas e permite que você acrescente as suas por cima, sem precisar recriar tudo à mão. O modo manual dá controle total, mas exige que você assuma a responsabilidade por cada regra de saída.
Port forward: publicar uma porta de um serviço interno
O port forward é o NAT mais usado no dia a dia. Ele pega uma conexão que chega em uma porta do IP público e a encaminha para um IP e uma porta na rede interna. É assim que você publica um servidor web, um serviço de acesso ou uma câmera para fora, quando não há alternativa melhor.
Um detalhe do pfSense economiza erro: ao criar um port forward, ele oferece criar automaticamente a regra de firewall associada. Aceite. Sem essa regra, o NAT reescreve o pacote, mas o firewall o bloqueia, e você fica horas procurando defeito onde não há. Com a regra associada, os dois lados ficam coerentes desde o começo.
NAT 1:1: um IP público inteiro para um host interno
O NAT 1:1 associa um endereço público inteiro a um endereço interno, mapeando todas as portas de uma vez. Ele faz sentido quando você tem IPs públicos sobrando e quer que um host se comporte como se estivesse diretamente na internet, para dentro e para fora, sem traduzir porta a porta.
A conveniência do 1:1 é também o seu risco. Mapear o endereço inteiro não significa liberar tudo: as regras de firewall continuam mandando no que passa. Ainda assim, é uma configuração que pede regras restritas, porque a superfície exposta é maior por natureza. Use quando a arquitetura realmente pedir, não por comodidade.
NAT reflection: acessar o serviço pelo IP público de dentro da rede
NAT reflection resolve um problema clássico: você publicou um serviço e ele funciona de fora, mas de dentro da própria rede, pelo mesmo endereço público, não conecta. O reflection faz o firewall refletir esse acesso interno de volta para o servidor certo. O pfSense suporta essa função, e ela desliga muita dor de cabeça de "funciona na rua e não funciona no escritório".
Ainda assim, reflection é um remendo elegante para uma limitação, não a melhor arquitetura. Quando possível, resolver o acesso interno com split DNS, apontando o nome para o IP interno dentro da rede, costuma ser mais limpo e mais previsível do que refletir NAT.
O cuidado que separa publicar de expor
Todo port forward abre uma janela para a internet inteira, incluindo quem varre endereços procurando serviço vulnerável. Publicar um painel administrativo, um banco de dados ou um serviço de acesso remoto direto na porta é um dos erros mais comuns e mais caros. O que está exposto será testado, mais cedo ou mais tarde.
Antes de criar a regra, pergunte se o serviço precisa mesmo ficar aberto para todos. Muitas vezes a resposta é não, e uma VPN resolve melhor. Quando a exposição é necessária, restrinja a origem por IP quando possível, coloque a aplicação atrás de um proxy reverso e mantenha o serviço atualizado.
Alternativas mais seguras à porta aberta
- VPN de acesso remoto: em vez de expor o serviço, o usuário entra na rede pela VPN e acessa como se estivesse dentro.
- Proxy reverso com HAProxy: publica aplicações web por trás de um único ponto, com terminação TLS e regras de acesso.
- Restrição de origem: liberar o port forward apenas para os IPs que precisam, quando eles são conhecidos.
- Split DNS: resolver o acesso interno pelo nome sem depender de NAT reflection.
Como diagnosticar quando o NAT não funciona
Quando um port forward não conecta, o roteiro é quase sempre o mesmo. Confirme que a regra de firewall associada existe e está ativa. Verifique se o serviço interno está de fato escutando na porta e no IP informados. Cheque se não há outro equipamento fazendo NAT antes do pfSense, o que é comum quando o modem do provedor não está em modo bridge.
Os logs de firewall do pfSense mostram se o pacote está sendo bloqueado, e o diagnóstico de estados mostra se a conexão está sendo criada. Ler esses registros resolve a maioria dos casos sem tentativa e erro. O guia sobre logs de firewall e monitoramento ajuda a interpretar o que aparece ali.
Onde a OpenSourceBrasil entra
Publicar serviços com NAT é rotina, mas rotina que erra em silêncio. Um port forward esquecido ou uma regra ampla demais vira porta de entrada sem ninguém notar. A OpenSourceBrasil trabalha a publicação segura de serviços dentro do projeto de firewall pfSense, com regras restritas, proxy quando faz sentido e revisão periódica do que está exposto.