pfsense: Verbindung zwischen zwei internen LANs nach 20 Sekunden unterbrochen

Question

Ich habe folgende Konfiguration:

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

Und dann:

PFSENSE LAN IP: 192.168.16.1
PFSENSE LAN IP: 192.168.67.1 (it's a virtual IP)

LAN 01UndLAN 02physisch verbunden sind (d. h. im selben Switch. Ich weiß, dass ich separate LANs oder zumindest VLANs auf ihnen verwenden sollte, aber ich kann diese Konfiguration derzeit nicht so einfach ändern).

Ich habe eine PFSENSE-Installation (2.2) im Einsatz, bei der Computer inLAN 02erhalten ihre IP-Adressen von einem DHCP-SERVER und verwenden PFSENSE als Standard-Gateway.

Hier ist mein Problem:

Wenn ich an einem Computer sitze, der sich aufLAN 02und ich ssh (oder jedes andere persistente Protokoll) auf einen Server aufLAN 01so was:

$ ssh -l myself 192.168.16.25

Ich verbinde mich ohne Probleme. Die Verbindung hält zwischen 20 und 30 Sekunden und wird dann ständig unterbrochen.

Meine Frage ist also:Was kann ich tun, um einen Verbindungsabbruch zu vermeiden?

Ich habe von beiden Seiten einen TCPdump ausgeführt und irgendwann wurden die Pakete dupliziert. Das sieht so aus:

Ich habe diese Option aktiviert und dachte, dass sie helfen würde, aber das war nicht der Fall.

Ich sollte erwähnen, dass genau diese Konfiguration mit einer LINUX-FIREWALL (iptables) einwandfrei funktioniert.

Irgendwelche Ideen?

Answer 1

Ich vermute, dass Ihre Auflistung von LAN1 und LAN2 als beide 192.168.1.0/24 falsch ist, da die Erfassung zeigt, dass eines offensichtlich 192.168.16.0 und eines 192.168.67.0 ist, hoffentlich beides /24.

Die Option zur statischen Routenfilterung ist hier nicht anwendbar.

Ich vermute, dass Ihre Netzwerke sich entweder überschneiden (keine /24-Maske auf beiden, vielleicht /16 auf einigen Hosts) oder dass eines der betroffenen Systeme auf beiden Netzwerken dual-homed ist, was zu asymmetrischem Routing führt.

Answer 2

Ich hatte ein sehr ähnliches Problem und das Problem war im Wesentlichen eine Variante des asymmetrischen Routings.

In meiner Topologie habe ich eine PFSENSE-Box mit 2 LAN-Schnittstellen – beide /24, aber definitiv unterschiedliche Subnetze. Dann habe ich einen L2\L3-Switch, der beide Schnittstellen mit dem Rest des Netzwerks in unterschiedlichen VLANs verbindet. An diesem Switch hängen auch kabelgebundene Benutzer und ein Segment, das alle drahtlosen Benutzer enthält. Die kabelgebundenen Benutzer befinden sich in einem Subnetz/VLAN und die drahtlosen in einem anderen – und beide dieser Subnetze sind das, was auf der PFSENSE-Box vorhanden ist. Alle Endpunkte verwenden die PFSENSE-IP für ihr jeweiliges Subnetz als ihre DG. Und schließlich hat der Switch auch eine IP in beiden der oben genannten Subnetze.

Mein Problem war, dass wenn ich drahtlos verbunden war und per SSH mit dem Switch verbunden war, die Verbindung zwar einwandfrei war, dann aber nach 20-30 Sekunden abbrach. Wie Sie wahrscheinlich bereits wissen, gingen die Rückpakete vom Switch direkt an meinen Computer, anstatt demselben Pfad wie die Pakete von meinem Computer zu folgen, da der Switch eine IP im selben Subnetz wie mein Computer hatte. Der Switch umging also im Wesentlichen einfach die PFSENSE-Box.

In vielen Situationen könnte dies tatsächlich gut funktionieren, insbesondere bei nicht zustandsbehafteten Vermittlern und/oder UDP-Sitzungen. Die PFSENSE-Box ist jedoch ein zustandsbehaftetes Gerät, sodass PFSENSE nach einigen Sekunden keine Antwort auf das TCP OPEN sieht und den Status beendet. Zur Bestätigung können Sie den TCP OPEN-Timeout-Wert von PFSENSE anpassen (System --> Erweitert --> Status-Timeouts) und dann beobachten, dass die Zeit, die zum Beenden der SSH-Sitzung benötigt wird, Ihrer Einstellung entspricht. Der Standardwert für diesen Wert beträgt erwartungsgemäß 30 Sekunden. Nach dem Entfernen der relevanten IP vom Switch – BAM – ist das Problem behoben.

Obwohl es in der beschriebenen Topologie des OP nicht ausdrücklich erwähnt wird, vermute ich, dass zwischen den relevanten Endpunkten ein Switch (oder ähnliches) vorhanden sein könnte. Vielleicht nicht, aber wenn ja, dann könnte es dasselbe Problem sein, das ich hier hatte. Alternativ könnte dieses Problem auftreten, wenn der Server in der Topologie des OP dual-homed ist.