Firewall → Settings → Advanced → Disable reply-to on WAN rules → marcar → Save → Apply.

Síntoma: un port-forward o una regla WAN responde desde cualquier IP de internet, pero desde un equipo que vive en la misma subred que la WAN del firewall todo da timeout (SSH, HTTPS, incluso ping), aunque la regla diga from any.

Con una sola WAN es seguro: el firewall deja de forzar el regreso por el gateway y vuelve a usar su tabla de rutas.

El escenario

1
2
3
4
5
6
7
8

                203.0.113.0/24  (mismo segmento L2)
   ┌────────────────────┬────────────────────┬────────────────────┐
   │                    │                    │                    │
 gateway             fw01 (OPNsense)      vecino               internet
 203.0.113.1         WAN 203.0.113.40     203.0.113.50         (vía gateway)
                        │ rdr :22 → 192.168.1.10
                        ▼
                     servidor LAN

• Desde internet: ssh -p 22 203.0.113.40 entra al servidor de la LAN. Bien.
• Desde vecino (203.0.113.50): timeout en todos los puertos.

Qué hace reply-to

OPNsense genera las reglas de las interfaces tipo WAN (las que tienen gateway) con reply-to apuntando a ese gateway:

1

pfctl -sr | grep reply-to

1

pass in quick on vtnet0 reply-to (vtnet0 203.0.113.1) inet proto tcp from any to 192.168.1.10 port = ssh flags S/SA keep state

reply-to es una opción de pf. Cuando un paquete entra y crea un estado, pf guarda en ese estado que todas las respuestas salgan por vtnet0 hacia 203.0.113.1. Esas respuestas no pasan por la tabla de rutas: pf decide el siguiente salto por su cuenta.

Existe por multi-WAN. Si tienes dos proveedores y un cliente entra por la WAN2, la respuesta tiene que salir por la WAN2. Si sale por la ruta por defecto (WAN1), lleva una IP de origen que el proveedor 1 no reconoce y se pierde. reply-to garantiza el regreso simétrico sin tener que pensar en rutas.

Por qué rompe a los vecinos

Para un cliente en internet, «responder al gateway» es justo lo que haría la tabla de rutas, así que no se nota nada.

Para el vecino es distinto. Su IP (203.0.113.50) está en una red conectada del firewall. Sin reply-to, el firewall resolvería su MAC por ARP y le respondería directo. Con reply-to, el SYN-ACK sale con la MAC del gateway como destino:

1
2

# en el OPNsense (shell csh: envuelve en sh -c)
sh -c "tcpdump -lnei vtnet0 host 203.0.113.50 and tcp port 22"

1
2

<mac-vecino> > <mac-fw01>          203.0.113.50.49612 > 203.0.113.40.22: Flags [S]    ← llega directo
<mac-fw01>   > 00:00:5e:00:01:<vrid> 203.0.113.40.22 > 203.0.113.50.49612: Flags [S.]   ← sale al gateway

(00:00:5e:00:01:xx es la MAC virtual de VRRP: el gateway era un par redundante.)

A partir de ahí depende del gateway. Para él, el paquete entra por la misma interfaz por la que tendría que salir, y si tiene un filtro con estado ve un SYN-ACK de una conexión cuyo SYN nunca vio. En el lab, el gateway simplemente no lo devolvía al segmento. En el vecino sólo se ven SYN reintentándose y ningún [S.].

La huella en el firewall es un estado a medias:

1

pfctl -ss | grep 203.0.113.50

1

all tcp 192.168.1.10:22 (203.0.113.40:22) <- 203.0.113.50:57792   SYN_SENT:ESTABLISHED

El servidor ya respondió (ESTABLISHED) y el cliente sigue esperando (SYN_SENT): la respuesta se pierde de regreso, no a la ida. El filtro no está bloqueando nada.

Qué cambia el fix

Con Disable reply-to on WAN rules activado, OPNsense regenera las reglas sin reply-to:

1

pass in quick on vtnet0 inet proto tcp from any to 192.168.1.10 port = ssh flags S/SA keep state

El estado ya no fija el siguiente salto, así que las respuestas pasan por la tabla de rutas normal:

La última fila es el costo. Con multi-WAN no lo desactives global. En vez de eso, quita el reply-to sólo en la regla del port-forward afectado: en la regla, Advanced → reply-to. Revisa las opciones que ofrece tu versión.

Verificar

1
2
3

# en el OPNsense
sh -c "pfctl -sr | grep -c reply-to; grep -n disablereplyto /conf/config.xml"
# esperado: 0  y  <disablereplyto>yes</disablereplyto>

1
2

# desde el vecino
nc -z -w5 203.0.113.40 22 && echo abierto

Trampas

• «Disable force gateway» no es esto. Está en la misma pantalla y tiene un nombre parecido, pero sólo afecta el tráfico que origina el propio firewall (DNS, NTP, actualizaciones). No toca las respuestas a tráfico entrante.
• Una ruta estática en el gateway no ayuda. El gateway ya tiene la subred como conectada; el problema es que no regresa el paquete al mismo segmento, no que no sepa llegar.
• Shell csh. Por SSH, OPNsense entra a csh y cosas como 2>/dev/null fallan con Ambiguous output redirect. Usa sh -c "..." o ssh root@fw01 sh <<'EOF'.
• Revisa todos los puertos, no uno. Si falla sólo un puerto es otro problema (regla, NAT, servicio). Si fallan todos, incluido ping, y sólo desde la misma subred, sospecha de reply-to.

Ver también

• Documentación de OPNsense, configuración del firewall: https://docs.opnsense.org/manual/firewall_settings.html
• pf.conf(5), opciones route-to / reply-to: https://man.freebsd.org/cgi/man.cgi?query=pf.conf

1
2
3
4
5
6
7
8
9

pfctl -sT                                    # tablas cargadas
pfctl -t <tabla> -T show                     # contenido
pfctl -t <tabla> -T add 192.168.1.10         # añadir IP o red (también 10.20.0.0/16)
pfctl -t <tabla> -T delete 192.168.1.10
pfctl -t <tabla> -T test 192.168.1.10        # ¿está dentro? (match / no match)
pfctl -t <tabla> -T flush                    # vaciar la tabla
pfctl -t <tabla> -T replace -f /ruta/lista   # reemplazar todo el contenido desde un archivo

pfctl -t sshguard -T flush                   # pfSense: quitar el bloqueo por intentos de login fallidos

Qué es una tabla

Una tabla de PF es un conjunto de direcciones y redes al que las reglas hacen referencia como <nombre>. Se cambia en caliente, sin recargar el ruleset, y aguanta miles de entradas con búsqueda rápida; por eso PF la usa para listas de bloqueo, bogons y cualquier cosa que cambie más a menudo que las reglas.

En pf.conf:

1
2

table <blocklist> persist file "/etc/pf/blocklist.txt"
block in quick from <blocklist>

persist mantiene la tabla aunque ninguna regla la use en ese momento; file la carga desde un archivo (una IP o red por línea).

Comandos

Todos con la forma pfctl -t <tabla> -T <comando>:

Y sin -t:

1
2
3
4

pfctl -sT                    # nombres de todas las tablas
pfctl -vvsT                  # info global por tabla: entradas, evaluaciones, referencias
pfctl -T load -f /etc/pf.conf   # recarga solo las definiciones de tabla del pf.conf
pfctl -sr | grep '<nombre>'  # qué reglas usan una tabla

Tablas en pfSense

• Los aliases son tablas. Un alias de tipo Host, Network o URL Table llamado Admins existe en PF como <Admins>; pfctl -t Admins -T show te enseña lo que resolvió pfSense, incluidos los FQDN que ya convirtió a IPs.
• sshguard: donde caen las IPs bloqueadas por intentos de login fallidos a SSH o a la webGUI. Si te bloqueaste a ti mismo, pfctl -t sshguard -T flush (documentado por Netgate en Locked out of the WebGUI).
• virusprot: hosts bloqueados por superar los límites Max. src. conn. rate o Max. states de una regla. pfctl -t virusprot -T show y -T delete <ip> para soltar a uno.
• snort2c: bloqueos de Snort/Suricata en modo legacy. -T flush para desbloquear todo.
• bogons / bogonsv6: las listas que se actualizan solas cuando activas Block bogon networks en una interfaz.
• pfBlockerNG: cada lista es un alias pfB_*. Para saber si una IP está bloqueada por alguna: pfctl -t pfB_Top_v4 -T test 203.0.113.7.

En OPNsense la mecánica es la misma (pfctl -sT para ver los nombres); la tabla de bloqueo por login se llama sshlockout.

Lo que se pierde al recargar

Cualquier -T add, -T delete o -T flush vive hasta la siguiente recarga del filtro: guardar casi cualquier cosa en la GUI, Filter Reload en Status → Filter Reload, o el cron de actualización de aliases. En ese momento pfSense regenera cada tabla desde su alias y tus cambios a mano desaparecen. Para que algo sea permanente, edita el alias; para pruebas rápidas y desbloqueos, pfctl es perfecto.

Más allá de las tablas

Lo que más se usa junto a lo anterior:

1
2
3
4
5
6
7

pfctl -sr                    # reglas cargadas (con -vv, contadores y números de regla)
pfctl -ss                    # tabla de estados
pfctl -si                    # estadísticas globales
pfctl -k 192.168.1.10        # matar los estados de un host
pfctl -F states              # matar todos los estados (corta todas las conexiones)
pfctl -d / pfctl -e          # desactivar / activar PF (sin PF no hay NAT: úsalo solo para salir de un bloqueo)
pfctl -nf /etc/pf.conf       # comprobar sintaxis sin cargar

Referencia completa: pfctl cheat sheet del OpenBSD Handbook y man pfctl en FreeBSD.

System → Advanced → Networking → Disable hardware checksum offload ✔ → Save → reinicia la VM. La GUI no avisa, pero el cambio no aplica a las interfaces vtnet hasta el reinicio.

Para probar sin reiniciar (se pierde al arrancar):

1
2

ifconfig vtnet0 -rxcsum -txcsum -tso -lro
ifconfig vtnet1 -rxcsum -txcsum -tso -lro

En OPNsense: Interfaces → Settings → Hardware CRC → Disable hardware checksum offload, y el mismo reinicio.

Síntomas

La VM arranca, las interfaces están UP, el DHCP de la LAN reparte direcciones y aun así:

• Los equipos detrás del firewall no llegan a Internet, o la conexión se queda a medias (el ping pasa, TCP se cuelga).
• Desde el propio host de virtualización o desde otras VMs del mismo host no se llega a nada protegido por pfSense, ni a la GUI.
• Cambiar la NIC de la VM a e1000 lo arregla al momento, lo que confirma el diagnóstico.

Por qué pasa

El driver vtnet de FreeBSD, con el offload de checksums activado, entrega a la pila de red paquetes cuyo checksum nunca llegó a calcularse: entre VMs del mismo host, y entre el host y la VM, el tráfico no pasa por una NIC física que lo haga. FreeBSD ve checksums inválidos y descarta (bug 165059 de FreeBSD). Netgate lo documenta en VirtIO Driver Support.

pfSense intenta marcar la opción solo cuando detecta interfaces vtnet en la instalación. Si la NIC VirtIO se añadió después, si restauraste el config.xml de un firewall físico, o si migraste la VM desde otro hipervisor con otro tipo de NIC, la opción sigue apagada.

Procedimiento

1. System → Advanced → Networking, sección Network Interfaces:

   • Disable hardware checksum offload: marcar.
   • Disable hardware TCP segmentation offload y Disable hardware large receive offload: ya vienen marcadas por defecto; déjalas así.

2. Save.

3. Reboot desde Diagnostics → Reboot. Sin este paso, nada cambia en vtnet.

4. Comprueba:

   1	ifconfig vtnet0 | grep options

   No deben aparecer RXCSUM ni TXCSUM (ni TSO4, LRO).

Si sigue igual

• Todas las NICs de la VM tienen que ser del mismo estilo. Una vtnet con offload y otra e1000 se comportan distinto; revisa cada ifconfig.
• Offload en el host. Netgate señala que a veces también hay que apagar checksums y TSO en el hipervisor. En Proxmox/KVM, sobre la interfaz tap de la VM: ethtool -K tap100i0 tx off (el número es el VMID y i0 la NIC). Es raro necesitarlo; pruébalo el último.
• Plan B: modelo de NIC e1000 en la VM. Menos rendimiento que VirtIO sin offload, pero sin este bug.

Trampas

• El reinicio no es opcional y la GUI no lo pide. Es la causa número uno de “lo marqué y sigue sin funcionar”.
• No es un problema de reglas. Con el offload activo, los paquetes se descartan antes de llegar a pf; el log del firewall no muestra nada.
• e1000 también en OPNsense como plan B; el ajuste equivalente está en Interfaces → Settings.
• Multiqueue (queues=N en Proxmox) funciona bien con vtnet una vez desactivado el offload; no lo confundas con la causa.

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.