NAT de saída no pfSense: leia primeiro as regras geradas

Abra Firewall, depois NAT, depois Outbound, e leia o modo antes de acrescentar qualquer coisa. No modo Automatic, o pfSense gera regras para as interfaces WAN e, entre elas, para as redes VPN de acesso remoto, por isso o pool que vai acrescentar muitas vezes já está coberto. A ausência de uma linha escrita à mão não prova que a tradução falte. A ordem abaixo evita que mude toda a firewall para Manual para resolver um único pool.

O modo decide quem mantém a tradução para todas as outras redes da máquina, e essa é uma decisão maior do que uma exceção de VPN.

O modo Automatic já cobre o pool de VPN

Cada modo tem um proprietário diferente. O Automatic gera regras para as interfaces WAN e inclui as redes VPN de acesso remoto entre as suas origens. O Hybrid mantém essas regras geradas e permite acrescentar regras manuais ao lado. O Manual deixa de gerar seja o que for, por isso cada tradução na firewall passa a ser sua responsabilidade, incluindo as que não escreveu. Uma quarta definição desativa por completo o NAT de saída. Uma linha que parece escrita à mão não prova nada enquanto não souber qual modo está ativo.

Em Automatic e Hybrid a página também mostra as regras geradas. Leia-as antes de concluir que um pool de VPN não tem tradução: procure a rede do pool na coluna de origem e a interface WAN na coluna de interface.

Escolha Hybrid apenas para uma exceção revista

Uma exceção documentada continua a ser possível quando a política de saída difere de facto. Imagine um servidor que distribui 10.90.0.0/24, onde a firewall deve fornecer saída para a internet por IPv4 e o encaminhamento já escolhe WAN. A transformação esperada é que a origem 10.90.0.23 seja reescrita para o endereço WAN. Verifique se alguma regra gerada já o faz nessa saída; se não, o Hybrid preserva a cobertura automática e acrescenta a sua regra revista.

Use o pool de VPN real como origem, ou um alias suportado para ele, e nunca escolha um endereço não relacionado só porque falta o nome da instância OpenVPN num seletor. Evite uma origem any, que também traduz o tráfego que a própria firewall origina.

Não mude toda a firewall para Manual por causa de um pool. Essa decisão reatribui a manutenção de cada rede interna e de cada alteração futura de WAN.

O NAT não escolhe a saída

O encaminhamento escolhe a interface de saída; uma regra de NAT de saída só descreve como a origem é reescrita depois de o pacote sair. Um mapeamento para WAN não obriga um pacote que o encaminhamento enviou para outro lado a passar pela WAN, e é por isso que acrescentar NAT não pode reparar uma rota errada. Inspecione também as entradas de NAT 1:1 aplicáveis e as exceções, porque a ordem importa e uma linha nova não ganha necessariamente. E a página de saída não é a página de filtragem.

Uma origem traduzida não é autorização para chegar a qualquer destino. Os clientes continuam a precisar de uma rota pelo túnel e de uma regra de firewall que admita o seu tráfego, e a saída escolhida precisa de um caminho de retorno funcional. Mantenha o acesso só à LAN separado da autorização de saída para a internet.

Prove a transformação numa ligação nova

Depois de uma alteração aprovada, teste com uma ligação autorizada nova em vez de reutilizar uma existente, porque os estados estabelecidos mantêm a transformação anterior. Confirme o endereço de origem que sai realmente pela WAN e que a resposta regressa pelo mesmo estado. Não esvazie toda a tabela de estados como primeiro passo; isso esconde qual regra mudou o resultado. Registe o modo, a regra, o pool e a saída no ticket de alteração.

Este exemplo abrange apenas a saída IPv4. Não diz nada sobre uma tradução ou política de filtragem IPv6, e um projeto que precise de uma tem de o declarar em separado. O registo final lista o tráfego de clientes permitido, a interface que o transporta e o motivo pelo qual a origem precisa de ser reescrita.