NAT de salida en pfSense: lea primero las reglas generadas

Abra Firewall, luego NAT y luego Outbound, y lea el modo antes de añadir nada. En el modo Automatic, pfSense genera reglas para las interfaces WAN y, entre ellas, para las redes VPN de acceso remoto, así que el grupo que va a añadir suele estar ya cubierto. Que falte una fila escrita a mano no demuestra que falte la traducción. El orden siguiente le evita cambiar todo el cortafuegos a Manual para resolver un solo grupo.

El modo decide quién mantiene la traducción de todas las demás redes del equipo, y esa es una decisión mayor que una excepción de VPN.

El modo Automatic ya cubre el grupo de VPN

Cada modo tiene un propietario distinto. Automatic genera reglas para las interfaces WAN e incluye las redes VPN de acceso remoto entre sus orígenes. Hybrid conserva esas reglas generadas y le permite añadir reglas manuales junto a ellas. Manual deja de generar nada, así que todas las traducciones del cortafuegos pasan a ser su responsabilidad, incluidas las que usted no escribió. Un cuarto ajuste desactiva por completo el NAT de salida. Una fila que parece escrita a mano no demuestra nada hasta que se sabe qué modo está activo.

En Automatic y Hybrid, la página también muestra las reglas generadas. Léalas antes de concluir que un grupo de VPN no tiene traducción: busque la red del grupo en la columna de origen y la interfaz WAN en la columna de interfaz.

Elija Hybrid solo para una excepción revisada

Una excepción documentada sigue siendo posible cuando la política de salida difiere de verdad. Imagine un servidor que reparte 10.90.0.0/24, donde el cortafuegos debe proporcionar salida a internet por IPv4 y el enrutamiento ya elige WAN. La transformación esperada es que el origen 10.90.0.23 se reescriba a la dirección WAN. Compruebe si alguna regla generada ya lo hace en esa salida; si no, Hybrid conserva la cobertura automática y añade su regla revisada.

Use el grupo de VPN real como origen, o un alias compatible, y nunca elija una dirección no relacionada solo porque falte el nombre de la instancia de OpenVPN en un selector. Evite un origen any, que también traduce el tráfico que origina el propio cortafuegos.

No pase todo el cortafuegos a Manual por un solo grupo. Esa decisión reasigna el mantenimiento de todas las redes internas y de cada cambio futuro de WAN.

El NAT no elige la salida

El enrutamiento elige la interfaz de salida; una regla de NAT de salida solo describe cómo se reescribe el origen una vez que el paquete sale. Una asignación para WAN no obliga a un paquete que el enrutamiento envió a otro sitio a pasar por WAN, y por eso añadir NAT no puede reparar una ruta incorrecta. Revise también las entradas de NAT 1:1 y las excepciones aplicables, porque el orden importa y una fila nueva no gana necesariamente. Y la página de salida no es la página de filtrado.

Un origen traducido no es permiso para llegar a cualquier destino. Los clientes siguen necesitando una ruta por el túnel y una regla de cortafuegos que admita su tráfico, y la salida elegida necesita una ruta de retorno operativa. Mantenga el acceso solo a LAN separado del permiso de salida a internet.

Demuestre la transformación en una conexión nueva

Tras un cambio aprobado, pruebe con una conexión autorizada nueva en lugar de reutilizar una existente, porque los estados establecidos conservan su transformación anterior. Confirme la dirección de origen que sale realmente por WAN y que la respuesta vuelve por el mismo estado. No vacíe toda la tabla de estados como primer paso; eso oculta qué regla cambió el resultado. Anote el modo, la regla, el grupo y la salida en el ticket de cambio.

Este ejemplo solo cubre la salida IPv4. No dice nada sobre una traducción o política de filtrado IPv6, y un diseño que necesite una debe declararlo por separado. El registro final enumera el tráfico de clientes permitido, la interfaz que lo transporta y el motivo por el que el origen necesita reescribirse.