pfSense OpenVPN: llegar a una red detrás de otro router
El cliente necesita un prefijo empujado, pfSense necesita un siguiente salto alcanzable y el router remoto necesita un camino de vuelta al grupo. Tres propietarios, tres rutas.
Tu portátil llega a la LAN de pfSense a través de la VPN y aun así no logra llegar a un servicio dos saltos más adentro, y la diferencia es una decisión de enrutamiento por propietario. Tres dispositivos deben ponerse de acuerdo antes de que un paquete complete su viaje de ida y vuelta: el cliente, el cortafuegos y el router que realmente posee la red de destino. Si falla cualquiera de ellos, el síntoma parece idéntico.
Sigue un paquete por esas tres decisiones antes de cambiar una regla, porque cada propietario tiene un control distinto y un modo de fallo distinto.
Un paquete, tres decisiones de enrutamiento
El cliente decide si el destino pertenece al túnel, y solo puede decidir a partir de lo que sabe: una ruta empujada, una ruta local o una ruta predeterminada que ya lo cubre todo. pfSense decide adónde enviar el paquete a continuación, lo que para una red detrás de otro router significa una ruta estática a través de una puerta de enlace alcanzable en la interfaz correcta. El router de abajo decide si conoce un camino de vuelta al grupo de la VPN, y si no lo conoce, la respuesta se descarta o se envía a un lugar inútil. Cada decisión es independiente de las otras dos.
El fallo de cualquiera de ellas produce el mismo informe de usuario. Por eso el orden de depuración importa más que las herramientas.
Dale al cliente un prefijo, no una suposición
En un servidor pfSense SSL/TLS con una red de túnel IPv4 mayor que un /30, el campo IPv4 Local network(s) distribuye rutas a los clientes cuando se conectan. Añade allí el prefijo de abajo en lugar de confiar en que el cliente invente uno. Después lee la tabla real del cliente tras conectarse, porque un perfil con route-nopull o un filtro de rutas puede ignorar lo que envió el servidor. El servidor puede ser perfectamente correcto mientras el cliente no instala nada.
Otros modos de servidor y topologías tienen límites distintos, y la política por cliente o por conexión puede cambiar lo que recibe un cliente concreto. Verifícalo en el cliente que importa, no en el que probaste primero por casualidad.
Apunta pfSense al router interno
Una ruta estática en pfSense necesita una puerta de enlace definida y alcanzable, y la interfaz elegida para esa puerta debe ser la que realmente llega a ella, como describe la guía de rutas estáticas de Netgate. En un diseño ilustrativo, el enlace de tránsito es 192.168.77.1 en el cortafuegos y 192.168.77.2 en el router interno, con la red de servicios en 172.16.30.0/25 detrás. La ruta entonces nombra el prefijo y el siguiente salto, no la dirección del servicio. Usar una dirección de la red remota como puerta de enlace es una forma habitual de construir una ruta que parece correcta y no reenvía a ninguna parte.
Asignar un nombre a una interfaz no describe las redes que hay detrás. La ruta estática es esa descripción.
El lado remoto debe conocer el grupo
El router de abajo necesita una ruta de vuelta para el grupo, en este ejemplo 10.55.0.0/24 vía 192.168.77.1, salvo que una ruta predeterminada o un protocolo dinámico ya proporcionen una. La puerta de enlace del propio host del servicio debe llevar hacia ese router, lo que suele ser cierto cuando el router es su puerta predeterminada y falso cuando el host se configuró a mano. El enrutamiento por políticas en el cortafuegos también puede anular la tabla para tráfico concreto, así que comprueba si una regla selecciona otra puerta antes de concluir que la ruta es incorrecta.
Este diseño no requiere traducción, y mantener visible la dirección de origen del cliente permite que la red de abajo aplique su propia política.
Para la aceptación, sigue una petición nueva a través de la entrada del túnel, la salida interna del cortafuegos y la respuesta del destino. Si en cambio se usa la traducción deliberadamente, registra qué origen ve la red de abajo y cómo se espera que vuelva la respuesta.
Guarda el plan de los tres propietarios junto a la aplicación permitida, para que el siguiente administrador pueda reconstruir el camino en lugar de volver a descubrirlo.