☰

pfSense NAT al servidor en una segunda subred LAN detrás de un segundo enrutador interno (no funciona)

tag-icon • tag-icon firewall routing nat subnet pfsense
pfSense NAT al servidor en una segunda subred LAN detrás de un segundo enrutador interno (no funciona)

Tengo un firewall/enrutador pfSense que expone algunos servicios a mi IP pública.

Esto funciona bien, siempre que el servicio esté en la subred LAN principal ( 192.168.1.0/24), llamémosloLAN-A.

Por ejemplo, esto funciona:

public_ip:443 -> pfSense (NAT) -> 192.168.1.20:5443 (reverse proxy)

Además tengo una segunda LAN 192.168.88.0/24, llamémoslaLAN-B, que está detrás de unmicrotikenrutador encendido 192.168.1.111. En pfSense tengo una ruta estática para la red 192.168.88.0/24que se especifica 192.168.1.111como puerta de enlace para la misma.

DeLAN-AAhora puedo conectarme a hosts enLAN-B, por ejemplo 192.168.88.10, de forma transparente, lo mismo que para los hosts enLAN-A(aparte de un problema extraño conssh mencionado aquí, aún sin resolver). (Anfitriones enLAN-BTambién puede conectarse a Internet normalmente, porque elmicrotikenrutador especifica la pfSensecasilla 192.168.1.1como puerta de enlace para sus clientes).

Hasta ahora, todo bien. Pero ahora quiero exponer un servicio enLAN-B, digamos 192.168.88.10:10000vía NAT en mi IP externa. Entonces hago lo mismo que normalmente:

public_ip:10000 -> pfSense (NAT+Rule) -> 192.168.88.10:10000

Esto, sin embargo, no funciona (y nmapdesde fuera muestra el puerto como filtered, en qué lugar de la LAN se encuentra open). Entonces, ¿parece que la lógica NAT no conoce mi ruta estática?

Parece de alguna manera lógico, porque la ruta estática "vive" en el alcance de mi interfaz local ( LANBRIDGE) de pfSense y el firewall (NAT) entre WANy LANBRIDGE, por lo que probablemente no sepa por qué conexión 192.168.88.0/24pasa 192.168.1.111. ¿Pero cómo hacer que esto funcione?

Respuesta1

Encontré el problema (para referencia posterior y posiblemente ayude a otros):

La configuración descrita (OP) está bien en el pfSenselateral.

El problema era que elmicrotikEl enrutador debe reenviar (cadena de reenvío) las direcciones de origen reales (es decir, las que se conectan a la IP externa), que serían 0.0.0.0/0y no solo direcciones 192.168.1.0/24. Por razones de seguridad, la regla de reenvío puede limitarse a ciertos puertos si es necesario.

información relacionada