Reportar un posible bug de algo que ya he tratado en el foro sin respuesta
-
Hola. Estoy teniendo un problema con Multi-WAN, alta disponibilidad y policy routing que creo que podría ser un bug. No lo quiero repetir aquí, que mi intención no es duplicar el hilo del problema o posible bug. Pero ningún experto/desarrollador me contesta y en las instrucciones de reportar bugs indican que los bugs no confirmados se pongan aquí o en la lista de correo.
En reddit también lo he comentado y al menos me ha contestado una persona con un problema similar, que parece que también considera que algo falla en Pfsense.
¿Algún consejo? ¿Lo intento por la lista de correo?
Gracias -
La IP Virtual tanto de la LAN como la WAN del Pfsense, están virtuales en ambos nodos?
Recuerda que al ser virtuales, no deben estar activas físicamente en la interfaz en ninguno de los 2 nodos.
IP virtual carp 192.168.1.1
ip lan nodo A 192.168.1.2
ip lan nodo B 192.168.1.3Lo mismo para la wan. Es decir que vas a perder 2 Ip publicas en general (una por nodo) corríjanme si me equivoco.
No he usado en producción CARP solo en laboratorio, pero el concepto es el mismo de heartbeat pacemaker, que si los he usado full.
-
Gracias j.sejo1 por tu respuesta. Ya me has hecho más caso que en la sección del problema en cuestión ;D
Te comento. Estoy utilizando IP virtuales tanto para la LAN como para las dos WAN. Y utilizándolas en el NAT cuando los paquetes van fuera de la LAN o de las propias WAN.
Aparentemente la configuración funciona estupendamente, excepto con las reglas del firewall para enrutar según qué tráfico por el gateway de una WAN que no sea el por defecto del sistema.
En este último caso, el tráfico se enruta bien, pero las conexiones establecidas (enrutadas mediante esa regla) se quedan congeladas si se cambia de nodo maestro de CARP.Pongo un ejemplo para intentar que se entienda mejor.
Configuración:-
El nodo1 está como maestro del cluster. Nodo2 es el esclavo o backup.
-
GW1 (de WAN1) es el gateway por defecto
-
GW2 (de WAN2) es el gateway para el tráfico que proviene de LAN (con una regla del firewall).
-
Se hace NAT usando la VIP de WAN1 para el tráfico de LAN que sale por WAN1.
-
Se hace NAT usando la VIP de WAN2 para el tráfico de LAN que sale por WAN2.
Pasos para recrear la situación:
-
Establezco una conexión desde LAN hacia el exterior. Como un ssh. Acorde a las reglas del firewall sale por WAN2. Funciona bien
-
Sin cerrar la conexión, deshabilito CARP en nodo1, de manera que nodo2 se pone de master con todas las VIP.
-
La conexión que tenía establecida (por ssh) desde la LAN se queda congelada.
-
Ejecutando tcpdump en el nodo2 (ahora master) veo que:
-
El tráfico de la LAN entra por la interfaz LAN, como es de esperar. Con las mismas IP de origen/destino que cuando el nodo1 estaba como master.
-
El tráfico está intentando salir por WAN1 y utilizando la VIP de WAN2. En lugar de estar saliendo por WAN2, como indican las reglas del firewall.
-
-
Si cierro el cliente ssh y vuelvo a lanzarlo, entonces el tráfico sí se enruta por WAN2, como es de esperar
Así pues, el problema lo tengo con las conexiones que ya están establecidas cuando se cambia de master de CARP. Para las que pfSense parece ignorar las reglas del policy routing y las intenta enrutar por el gateway por defecto. A pesar de que con tcpdump he comprobado que el tráfico sigue entrando por la interfaz LAN.
-
-
La única forma de probarlo (yo para ayudarte) es montando un LAB.
Busca por si acaso el tema de conexión persistente.
Por que una cosa es que tengas un pfsense en HA y estés descargando algo de internet o viendo youtube y cuando se cae el Nodo-A por cuestiones de segundo la descarga se detiene pero luego continua.
Y otra cosa es que tengas un SSH corriendo y se te congele o mejor dicho pierdas la conexión.
Por eso, creo que todo esta en buscar el alcance del pfsense en HA respecto a las conexiones persistentes.
Saludos.
-
Hola j.sejo1. En la sección de Multi-WAN hemos contrastado pruebas similares Derelict y yo. A él le funciona sin problemas un laboratorio virtual que ha montado y que a mí me sigue fallando. No me ha pasado su configuración y estoy a la espera de si me confirma qué reglas de firewall y NAT ha utilizado él.
A mi modo de ver tiene que haber algo en mi configuración, o en mi manera de utilizar pfSense, que se empeña en ignorar el policy routing para las conexiones ya establecidas cuando cambio de nodos master/backup. Lo cierto es que el NAT sí que lo mantiene, pero para el enrutado parece basarse directamente en la tabla de rutas del sistema. Motivo por el que no se trata de que se pierda algún paquete, sino que se intenta enrutar por el gateway por defecto (en lugar del que configuro con policy routing) y pierda las conexiones.
-
Gracias j.sejo1 por tu respuesta. Ya me has hecho más caso que en la sección del problema en cuestión ;D
Te comento. Estoy utilizando IP virtuales tanto para la LAN como para las dos WAN. Y utilizándolas en el NAT cuando los paquetes van fuera de la LAN o de las propias WAN.
Aparentemente la configuración funciona estupendamente, excepto con las reglas del firewall para enrutar según qué tráfico por el gateway de una WAN que no sea el por defecto del sistema.
En este último caso, el tráfico se enruta bien, pero las conexiones establecidas (enrutadas mediante esa regla) se quedan congeladas si se cambia de nodo maestro de CARP.Pongo un ejemplo para intentar que se entienda mejor.
Configuración:-
El nodo1 está como maestro del cluster. Nodo2 es el esclavo o backup.
-
GW1 (de WAN1) es el gateway por defecto
-
GW2 (de WAN2) es el gateway para el tráfico que proviene de LAN (con una regla del firewall).
-
Se hace NAT usando la VIP de WAN1 para el tráfico de LAN que sale por WAN1.
-
Se hace NAT usando la VIP de WAN2 para el tráfico de LAN que sale por WAN2.
Pasos para recrear la situación:
-
Establezco una conexión desde LAN hacia el exterior. Como un ssh. Acorde a las reglas del firewall sale por WAN2. Funciona bien
-
Sin cerrar la conexión, deshabilito CARP en nodo1, de manera que nodo2 se pone de master con todas las VIP.
-
La conexión que tenía establecida (por ssh) desde la LAN se queda congelada.
-
Ejecutando tcpdump en el nodo2 (ahora master) veo que:
-
El tráfico de la LAN entra por la interfaz LAN, como es de esperar. Con las mismas IP de origen/destino que cuando el nodo1 estaba como master.
-
El tráfico está intentando salir por WAN1 y utilizando la VIP de WAN2. En lugar de estar saliendo por WAN2, como indican las reglas del firewall.
-
-
Si cierro el cliente ssh y vuelvo a lanzarlo, entonces el tráfico sí se enruta por WAN2, como es de esperar
Así pues, el problema lo tengo con las conexiones que ya están establecidas cuando se cambia de master de CARP. Para las que pfSense parece ignorar las reglas del policy routing y las intenta enrutar por el gateway por defecto. A pesar de que con tcpdump he comprobado que el tráfico sigue entrando por la interfaz LAN.
Hola
una duda puedes colocar las ip CARP de tu laboratorio y las de NAT
-
-
Hola. Por supuesto.
En el hilo en inglés al que comencé haciendo referencia en este hilo puse unas capturas con una de las configuraciones que he probado varias veces. También adjunté en ese mensaje los ficheros de configuración.Según los expertos lo que yo quiero hacer es totalmente posible y que lo usa mucha gente. Pero después de haber probado el sistema en un entorno real con enlaces agregados y VLAN, y también en un entorno virtual sin agregación de enlaces ni VLAN, la situación con la que me encuentro es la misma.
-
Gracias j.sejo1 por tu respuesta. Ya me has hecho más caso que en la sección del problema en cuestión ;D
Te comento. Estoy utilizando IP virtuales tanto para la LAN como para las dos WAN. Y utilizándolas en el NAT cuando los paquetes van fuera de la LAN o de las propias WAN.
Aparentemente la configuración funciona estupendamente, excepto con las reglas del firewall para enrutar según qué tráfico por el gateway de una WAN que no sea el por defecto del sistema.
En este último caso, el tráfico se enruta bien, pero las conexiones establecidas (enrutadas mediante esa regla) se quedan congeladas si se cambia de nodo maestro de CARP.Pongo un ejemplo para intentar que se entienda mejor.
Configuración:-
El nodo1 está como maestro del cluster. Nodo2 es el esclavo o backup.
-
GW1 (de WAN1) es el gateway por defecto
-
GW2 (de WAN2) es el gateway para el tráfico que proviene de LAN (con una regla del firewall).
-
Se hace NAT usando la VIP de WAN1 para el tráfico de LAN que sale por WAN1.
-
Se hace NAT usando la VIP de WAN2 para el tráfico de LAN que sale por WAN2.
Pasos para recrear la situación:
-
Establezco una conexión desde LAN hacia el exterior. Como un ssh. Acorde a las reglas del firewall sale por WAN2. Funciona bien
-
Sin cerrar la conexión, deshabilito CARP en nodo1, de manera que nodo2 se pone de master con todas las VIP.
-
La conexión que tenía establecida (por ssh) desde la LAN se queda congelada.
-
Ejecutando tcpdump en el nodo2 (ahora master) veo que:
-
El tráfico de la LAN entra por la interfaz LAN, como es de esperar. Con las mismas IP de origen/destino que cuando el nodo1 estaba como master.
-
El tráfico está intentando salir por WAN1 y utilizando la VIP de WAN2. En lugar de estar saliendo por WAN2, como indican las reglas del firewall.
-
-
Si cierro el cliente ssh y vuelvo a lanzarlo, entonces el tráfico sí se enruta por WAN2, como es de esperar
Así pues, el problema lo tengo con las conexiones que ya están establecidas cuando se cambia de master de CARP. Para las que pfSense parece ignorar las reglas del policy routing y las intenta enrutar por el gateway por defecto. A pesar de que con tcpdump he comprobado que el tráfico sigue entrando por la interfaz LAN.
Tendrias que ver si el problema lo tenes realmente con todas las conexiones activas o solo lo probaste con SSH.
SSH es un tipo de conexion segura, supongo que al cambiar el enrutamiento de wan1 a wan2, SSH ve que la ip cambio y por una cuestion de seguridad la conexion se rompe, algo parecido a lo que pasa con HTTPS cuando se hace balanceo de carga, al ser una conexion segura se toma el cambio de ip como un posible ataque y se interrumpe la conexion de forma automatica por seguridad.
Intenta establecer una conexion por telnet que es no seguro y ve si te corta. -
-
Gracias rosendogarcia por tu respuesta.
El problema (como he descrito en varios ejemplos del hilo en inglés) lo tengo tanto tanto con SSH como con ping, que usa ICMP. Por lo que descarto que ataña a la conexión segura.
Tengo pendiente simplificar al máximo el montaje físico, prescindiendo de enlaces agregados por ejemplo. En las pruebas con máquinas virtuales he tenido el mismo problema y quiero descartar que pueda estar afectado también por algún despiste en VirtualBox.
