Tengo la siguiente configuración:
LAN 01: 192.168.16.0/24 (LAN for internal servers)
LAN 02: 192.168.67.0/24 (LAN for workstations)
WAN: X.X.X.X
Y luego:
PFSENSE LAN IP: 192.168.16.1
PFSENSE LAN IP: 192.168.67.1 (it's a virtual IP)
LAN 01yLAN 02están conectados físicamente (es decir, en el mismo conmutador. Sé que debería usar LAN separadas o al menos VLAN en ellas, pero no puedo cambiar fácilmente esta configuración por ahora).
Tengo una instalación de PFSENSE (2.2) funcionando donde las computadoras enLAN 02obtenga sus direcciones IP de un SERVIDOR DHCP y use PFSENSE como puerta de enlace predeterminada.
Aquí está mi problema:
Si me siento frente a una computadora que reside enLAN 02y hago ssh (o cualquier otro protocolo persistente) en un servidor que reside enLAN 01como esto:
$ ssh -l myself 192.168.16.25
Me conecto sin problemas. La conexión dura entre 20 y 30 segundos y luego se interrumpe constantemente.
Entonces mi pregunta es:¿Qué puedo hacer para evitar que se caiga la conexión?
Hice un tcpdump desde ambos lados y, en algún momento, los paquetes comienzan a duplicarse. Se parece a esto:
Tengo esta opción habilitada y pensé que ayudaría, pero no fue así.
Debo mencionar que exactamente esta misma configuración, usando un FIREWALL de LINUX (iptables) funciona perfectamente.
¿Algunas ideas?
Respuesta1
Supongo que su listado de LAN1 y LAN2 como 192.168.1.0/24 es incorrecto dado que la captura muestra que uno es 192.168.16.0 y el otro es 192.168.67.0 aparentemente, con suerte ambos /24.
La opción de filtrado de rutas estáticas no tiene aplicabilidad aquí.
Supongo que tiene redes superpuestas (no una máscara /24 en ambos, tal vez /16 en algunos hosts), o uno de los sistemas afectados tiene doble conexión en ambas redes, lo que provoca un enrutamiento asimétrico.
Respuesta2
Tuve un problema muy similar y el problema era esencialmente una variación del enrutamiento asimétrico.
Con mi topología, tengo una caja PFSENSE con 2 interfaces LAN, ambas /24 pero definitivamente con subredes diferentes. Luego tengo un conmutador L2\L3 que conecta ambas interfaces al resto de la red en diferentes VLAN. También cuelgan de este interruptor los usuarios cableados y un segmento que tiene todos los usuarios inalámbricos. Los usuarios cableados están en una subred\VLAN y los inalámbricos en otra, y ambas subredes son las que existen en la caja PFSENSE. Todos los puntos finales utilizan la IP de PFSENSE para su subred respectiva como su DG. Y finalmente, el conmutador también tiene una IP en las dos subredes antes mencionadas.
Mi problema era que si estaba conectado de forma inalámbrica y mediante SSH al conmutador, me conectaría bien y luego pasaría entre 20 y 30 segundos. Como probablemente ya se habrá dado cuenta, debido a que el conmutador tenía una IP en la misma subred que mi máquina, los paquetes devueltos desde el conmutador irían directamente a mi máquina en lugar de seguir la misma ruta que los paquetes de mi máquina. Básicamente, el cambio simplemente eludiría la caja PFSENSE.
En muchas situaciones, esto podría funcionar bien, especialmente para intermediarios sin estado y/o sesiones UDP. Sin embargo, la caja PFSENSE es un dispositivo con estado, por lo que después de unos segundos, PFSENSE no ve respuesta al TCP OPEN y termina eliminando el estado. Para confirmar, puede modificar el valor de tiempo de espera de APERTURA de TCP de PFSENSE (Sistema --> Avanzado --> Tiempos de espera de estado) y luego observar que el tiempo que tarda la sesión SSH en finalizar seguirá lo que haya configurado. El valor predeterminado para este valor es, como se esperaba, 30 segundos. Al eliminar la IP relevante del conmutador (BAM), se solucionó el problema.
Si bien no se menciona específicamente en la topología descrita del OP, sospecho que puede haber un cambio (o similar) entre los puntos finales relevantes. Quizás no, pero si es así, podría ser el mismo problema que tuve aquí. Alternativamente, si el servidor en el topo del OP tiene doble alojamiento, entonces ocurriría este problema.