pfSense como servidor y cliente VPN: dos caminos, un solo router

Un solo equipo puede mirar en dos direcciones a la vez: los usuarios itinerantes se conectan hacia dentro, y la misma caja se conecta hacia fuera a un proveedor de salida para que el tráfico seleccionado salga por otra red. Habilitar ambos servicios lleva minutos; hacerlos convivir exige un diseño, porque el segundo rol reescribe la tabla de rutas de la que depende el primero. Tres condiciones deciden si el arreglo funciona, a saber, si el servicio de entrada conserva su propia ruta de retorno, si el túnel de salida sigue alcanzando a su par y si el tráfico que querías reenviar queda seleccionado para la salida. Si fallas en una, obtienes dos túneles que ambos informan de conectado mientras nada útil cruza entre ellos. Las comprobaciones de abajo establecen cada condición en el orden en que suelen aparecer los fallos.

Nombra los dos roles antes de tocar cualquier ajuste

Anota cuatro hechos por cada instancia: su par remoto, su material de autenticación, el conjunto de direcciones que reparte y las redes que tiene detrás. Las dos instancias son objetos separados en el equipo y también deben seguir separadas en tus notas. Casi todos los síntomas confusos posteriores vienen de mezclar sus valores, y dos instancias que comparten un juego de notas es cómo el conjunto equivocado acaba en el campo equivocado.

El servicio de entrada necesita una red de túnel que no se solape con las direcciones del túnel de salida ni con ninguna red privada que el equipo enrute. El solapamiento es el único error que produce síntomas en ambos roles a la vez, y es mucho más barato detectarlo sobre el papel. Compara ambos conjuntos y cada red privada enrutada en un solo lugar antes de configurar cualquiera de los servicios.

El hardware compartido no implica credenciales compartidas, y un certificado de cliente del conjunto de acceso remoto no debería servir contra el proveedor de salida. El material separado también convierte la revocación en una decisión local en lugar de un evento para toda la flota.

Mantén las respuestas del servidor en el camino WAN

Las respuestas que el equipo genera por sí mismo son la primera víctima de una ruta por defecto descuidada. Cuando llega un paquete encapsulado de un usuario itinerante, la respuesta es tráfico de origen local y tiene que salir por la interfaz por la que llegó ese usuario. Si el cliente de salida instaló una ruta por defecto que la captura, la respuesta entra en el túnel equivocado y la sesión se atasca mientras el servicio aún parece sano.

No hay una sola casilla que lo resuelva, porque la decisión va sobre qué tráfico puede capturar el cliente de salida. O bien no traes ninguna ruta y diriges solo lo que selecciones, o bien traes rutas y añades las excepciones que mantienen en marcha los servicios propios del equipo. Escribe la elección junto a la instancia, o la siguiente persona supondrá la otra.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Lee la tabla de rutas por la coincidencia más larga y no por el orden en que configuraste algo. La pregunta es qué entrada gana para la dirección del par de salida y qué entrada gana para la respuesta del servicio de entrada, y esas dos respuestas pueden diferir.

No dejes que el túnel de salida se coma su propio extremo

El cliente de salida tiene que alcanzar la dirección pública de su par para establecer el túnel siquiera. Si esa dirección se enruta dentro del túnel, el cliente se persigue la cola: el transporte nunca sube, o sube y cae en el momento en que se instala la ruta. El registro parece un tiempo de espera de autenticación y no una falla de enrutamiento, y por eso la ruta merece la primera comprobación.

Comprueba la ruta antes de las credenciales y de nuevo una vez arriba el túnel, porque una entrada puede ser correcta al arrancar y equivocada un minuto después. La dirección del par debe apuntar al camino WAN ordinario, nunca al dispositivo de túnel. Cuando el transporte se estabiliza, la pregunta interesante pasa al tráfico reenviado, que es la decisión siguiente.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Elige qué usuarios reciben la salida

La política de origen corresponde a la entrada donde el tráfico entra al equipo, así que selecciona el conjunto de acceso remoto, o identidades más estrechas dentro de él. Conserva los destinos privados y las excepciones de gestión que nunca deben enviarse a la salida, y coloca esas reglas antes de la amplia. El camino de salida necesita entonces su propia traducción o un arreglo de retorno enrutado, que para la mayoría de los diseños significa NAT de salida en la interfaz de salida que cubra el conjunto. La traducción no elige una salida; solo reescribe lo que ya ha salido, así que una regla NAT en una WAN ajena no cambia nada en la selección.

Confirma que el extremo remoto permite el tráfico reenviado de este diseño, porque algunos proveedores sí y otros no. La diferencia se ve como un túnel que conecta y no transporta nada, lo que es fácil de leer mal como un fallo local. Prueba los tres flujos por separado, porque fallan de forma independiente y dos de tres es un diseño a medio construir.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

El primer comando es la conexión exterior del usuario itinerante, y funciona cuando el cliente informa que la secuencia de inicialización se ha completado. El segundo, ejecutado desde ese portátil conectado, debería informar de la dirección del proveedor de salida en lugar de tu dirección WAN. El tercero se ejecuta en el equipo ligado a una dirección del conjunto, y prueba la política de origen para el tráfico reenviado sin implicar a ningún usuario remoto. Si en cambio responde desde la WAN, la política no coincidió, y ninguna cantidad de edición de NAT arregla un problema de selección.

Decide qué ocurre cuando la salida falla

Escribe el comportamiento ante el fallo antes de que ocurra: cuando el túnel de salida cae, ¿los usuarios vuelven a la WAN ordinaria o quedan bloqueados hasta que la salida regresa? Ambas respuestas son defendibles, y el equipo no elegirá por ti. Una ruta eliminada o una política que apunta a una puerta de enlace muerta no producen automáticamente un resultado de bloqueo total. Si quieres bloqueo, la política tiene que decirlo explícitamente, y hay que probarlo quitando la salida en lugar de razonar sobre ella. Si quieres retroceso, publícalo a los usuarios, porque el tráfico que toma en silencio el camino ordinario es exactamente el tráfico que alguien creía cubierto.

Desactiva la instancia de cliente, observa a qué puede llegar todavía un usuario conectado y vuelve a arrancarla. Una petición que expira es el resultado de bloqueo total que pediste; una que responde con la dirección WAN es el retroceso que no documentaste. Repite la comprobación para IPv6 y para DNS, porque una política escrita para IPv4 no dice nada sobre el tráfico AAAA y un resolutor empujado por cualquiera de los túneles responde desde donde realmente sale la consulta.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

La receta de Netgate para OpenVPN enrutado muestra cómo encajan la política de origen, la asignación de interfaces y la traducción de salida, y su alcance entre sitios es la parte que no hay que copiar entera. Lo que no te dirá es cuál de las tres condiciones de arriba ya ha roto tu propio diseño.