NAT de saída en pfSense: lea primeiro as regras xeradas

Abra Firewall, logo NAT e logo Outbound, e lea o modo antes de engadir nada. No modo Automatic, pfSense xera regras para as interfaces WAN e, entre elas, para as redes VPN de acceso remoto, así que o pool que vai engadir adoita estar xa cuberto. Que falte unha fila escrita a man non demostra que falte a tradución. A orde de abaixo evítalle cambiar todo o firewall a Manual para resolver un só pool.

O modo decide quen mantén a tradución para todas as demais redes da máquina, e esa é unha decisión maior ca unha excepción de VPN.

O modo Automatic xa cobre o pool de VPN

Cada modo ten un propietario distinto. Automatic xera regras para as interfaces WAN e inclúe as redes VPN de acceso remoto entre as súas fontes. Hybrid conserva esas regras xeradas e permítelle engadir regras manuais ao lado. Manual deixa de xerar nada, así que cada tradución do firewall pasa a ser responsabilidade súa, incluídas as que vostede non escribiu. Un cuarto axuste desactiva por completo o NAT de saída. Unha fila que parece escrita a man non demostra nada ata que se sabe que modo está activo.

En Automatic e Hybrid a páxina tamén mostra as regras xeradas. Léaas antes de concluír que un pool de VPN non ten tradución: busque a rede do pool na columna de orixe e a interface WAN na columna de interface.

Escolla Hybrid só para unha excepción revisada

Unha excepción documentada segue sendo posible cando a política de saída difire de verdade. Imagine un servidor que reparte 10.90.0.0/24, onde o firewall debe proporcionar saída a internet por IPv4 e o encamiñamento xa escolle WAN. A transformación esperada é que a orixe 10.90.0.23 se reescriba ao enderezo WAN. Comprobe se algunha regra xerada xa o fai nesa saída; se non, Hybrid conserva a cobertura automática e engade a súa regra revisada.

Use o pool de VPN real como orixe, ou un alias compatible, e nunca escolla un enderezo non relacionado só porque falte o nome da instancia de OpenVPN nun selector. Evite unha orixe any, que tamén traduce o tráfico que orixina o propio firewall.

Non pase todo o firewall a Manual por un só pool. Esa decisión reasigna o mantemento de cada rede interna e de cada cambio futuro de WAN.

O NAT non escolle a saída

O encamiñamento escolle a interface de saída; unha regra de NAT de saída só describe como se reescribe a orixe unha vez que o paquete sae. Unha asignación para WAN non obriga un paquete que o encamiñamento enviou a outro sitio a pasar por WAN, e por iso engadir NAT non pode reparar unha ruta incorrecta. Revise tamén as entradas de NAT 1:1 e as excepcións aplicables, porque a orde importa e unha fila nova non gaña necesariamente. E a páxina de saída non é a páxina de filtrado.

Unha orixe traducida non é permiso para chegar a calquera destino. Os clientes seguen necesitando unha ruta polo túnel e unha regra de firewall que admita o seu tráfico, e a saída escollida necesita un camiño de retorno que funcione. Mantéña o acceso só a LAN separado do permiso de saída a internet.

Demostre a transformación nunha conexión nova

Tras un cambio aprobado, probe cunha conexión autorizada nova en vez de reutilizar unha existente, porque os estados establecidos conservan a súa transformación anterior. Confirme o enderezo de orixe que sae realmente por WAN e que a resposta volve polo mesmo estado. Non baleire toda a táboa de estados como primeiro paso; iso oculta que regra cambiou o resultado. Anote o modo, a regra, o pool e a saída no tícket de cambio.

Este exemplo só cobre a saída IPv4. Non di nada sobre unha tradución ou política de filtrado IPv6, e un deseño que necesite unha debe declarao por separado. O rexistro final enumera o tráfico de clientes permitido, a interface que o transporta e o motivo polo que a orixe necesita reescribirse.