Opción limpia (split DNS): Services → DNS Resolver → Host Overrides → app.example.com → IP interna del servidor (192.168.1.50). Los clientes de la LAN tienen que usar el firewall como DNS.

Opción NAT reflection: System → Advanced → Firewall & NAT:

• NAT Reflection mode for port forwards: Pure NAT
• Enable NAT Reflection for 1:1 NAT: ✔
• Enable automatic outbound NAT for Reflection: ✔

Save y prueba desde un cliente de la LAN contra la IP pública.

El problema

El port forward WAN:443 → 192.168.1.50:443 funciona desde Internet. Desde un equipo de la misma LAN, https://app.example.com (que resuelve a la IP pública) responde con la GUI de pfSense, un error de certificado, o Potential DNS Rebind attack detected.

El paquete sale del cliente hacia la IP pública, llega al firewall por la interfaz LAN y ahí se queda: la regla de port forward escucha en la WAN, no en la LAN, y la IP de destino es una dirección del propio firewall. Nunca “sale y vuelve a entrar”.

Opción 1: split DNS

Es la que recomienda Netgate: el nombre resuelve a la IP interna dentro y a la pública fuera. El tráfico va directo, el servidor ve la IP real del cliente y el firewall no toca nada.

1. Services → DNS Resolver → Host Overrides → Add: host app, dominio example.com, IP 192.168.1.50. Si el servicio tiene varios nombres, añade Additional Names.
2. Los clientes deben usar el firewall como DNS (lo normal si el DHCP lo entrega). Un cliente con 8.8.8.8 fijo seguirá yendo a la IP pública.
3. nslookup app.example.com desde la LAN → 192.168.1.50.

Requisitos: el puerto interno y el externo tienen que ser el mismo (si fuera reenvías 8443 → 443, el cliente interno tendrá que usar 443 directamente).

Si usas DNS Forwarder (dnsmasq) en vez del Resolver, el ajuste equivalente está en Services → DNS Forwarder → Host Overrides.

Opción 2: NAT reflection

Cuando no controlas el DNS de los clientes, o hay un montón de puertos, el firewall puede “reflejar” la conexión: reescribe el destino a la IP interna y, con el outbound NAT automático, también el origen, para que la respuesta vuelva por el firewall.

System → Advanced → Firewall & NAT, sección Network Address Translation:

También se puede activar por regla: Firewall → NAT → Port Forward → editar → NAT reflection → Enable (Pure NAT), dejando el global en Disable.

Costes: el servidor ve como origen la IP LAN del firewall (no la del cliente), y todo ese tráfico pasa por el firewall aunque cliente y servidor estén en el mismo switch.

OPNsense

Misma idea, otros menús:

• Split DNS: Services → Unbound DNS → Overrides → Host Overrides.
• Reflection: Firewall → Settings → Advanced → Reflection for port forwards, Reflection for 1:1, Automatic outbound NAT for Reflection.

Trampas

• DNS rebinding. Si en vez de un host override apuntas el Resolver a un DNS externo que devuelve IPs privadas (un DNS interno de otra sede, un proveedor con vistas), Unbound descarta esas respuestas por protección contra rebinding. No desmarques Disable DNS Rebinding Checks en System → Advanced → Admin Access: añade en Services → DNS Resolver → Custom options private-domain: "example.com" y solo ese dominio queda exento.
• El cliente con DNS fijo se salta el split DNS. O lo obligas por DHCP, o lo capturas con una regla de NAT de puerto 53, o usas reflection.
• Pure NAT necesita saber la interfaz y el gateway en el momento de cargar reglas; con WANs dinámicas que cambian de IP, un Filter Reload después del cambio de IP lo arregla.
• Puertos distintos dentro y fuera solo funcionan con reflection; split DNS no traduce puertos.
• Certificados: con split DNS el navegador sigue viendo app.example.com, así que el certificado del servidor sirve igual. Si reflejas por IP pública, también. El error de certificado del principio era el de la GUI del firewall, no el del servidor.

Referencias: Port Forwards from Local Networks y NAT Reflection en la documentación de Netgate.