Frage wg. Probleme mit statischer Route

bon-go

Hallo Forum,

gibt es in der aktuellen 2.4.4p3 ein Problem mit statischen Routen ähnlich https://redmine.pfsense.org/issues/1950?

Wir haben vor kurzer Zeit bei zwei Installationen die bisherigen sonstigen Router je durch eine neue pfSense ersetzt, es gibt in den LAN Netzen jeweils noch einen weiteren Router zu einem Ziel in einem Fremdnetz und damit gibt es von Anfang an Probleme mit dem asymmetrischen Routing. Ein Haken bei System / Advanced / Firewall & NAT / Bypass firewall rules for traffic on the same interface reicht nicht so wie es z.B. in https://docs.netgate.com/pfsense/en/latest/book/routing/static-routes.html beschrieben ist. Die jetzige Lösung besteht darin die in der pfSense Dokumentation beschriebenen weiteren 2 Firewall Regeln auch noch anzulegen (an sich sollte das ja nicht nötig sein) und dazu habe ich gar noch Outbound NAT mit Static Port für das betreffende Ziel aktiviert. Erst dann klappt das, bis jetzt reibungslos, sind aber noch am testen.

Jemand ein ähnliches Problem bekannt?

Danke im Voraus für's Lesen und Antworten ;)

JeGr

Also ein "ähnliches" Problem wie ein 7 Jahre altes geschlossenes (weil gelöstes) Ticket ist mal sehr vage beschrieben ;)
Dazu lieferst du leider keinerlei Details. Ja du hast einen zweiten Router im LAN. Aber solang du rein gar nichts zu Netzen, Traffic Flow etc. schreibst kann auch niemand beurteilen, ob das totaler Quatsch ist oder ob da tatsächlich ein Fehler in der Logik oder im Denken ist.

Der Haken funktioniert zumindest bei uns bestens bei entsprechenden Szenarien von asymmetrischem Routing oder NAT Reflection wo solcher Verkehrt auftreten kann. Warum das bei dir nicht läuft und warum du Regeln UND NAT brauchst kann dir niemand aus der Glaskugel lesen wenn nicht mehr Details bekannt sind. Ich würde voraussagen, dass deine Voraussetzungen andere sind und das daher sehr gut sein kann und normal ist. Lasse mich aber gern von anderen Dingen überzeugen.

bon-go

Bisher:

Das ist ein merkwürdiges Problem mit langem Text (sorry dafür im Voraus): die TCP Verbindungen von Windows Client PC (Windows 7 ( 8.1 / 10) zu einem entfernten Windows Terminalserver (2008R2) über einen separaten Router im eigenen LAN werden regelmäßig für rd. 20-30 sek. unterbrochen und ich habe keine zündende Idee mehr warum das so ist. Ein vom Client PC auf den TS parallel laufender dauerhafter Ping zeigt keine Unterbrechung, UDP Verbindungen funktionieren scheinbar dauerhaft, es geht wohl nur um TCP. Das betrifft alle Clients wahllos, nicht gleichzeitig. Das betrifft auch die Druckaufräge die vom TS wieder an den Netzwerkdrucker (neben den Clients stehend) gesendet werden: diese werden auch unterbrochen und der Ausdruck verzögert sich dadurch erheblich. Insbesonders wenn Tastatureingaben am TS (z.B. in einem Editor) gemacht werden treten die Hänger einigermaßen reproduzierbar meist innerhalb einer Minute auf. Die RDP Sitzung hängt dann, wird nach einem Timeout kurz getrennt, automatisch wieder verbunden und erst dann sind die Eingaben wieder möglich. Alle zwischendurch getätigten Eingaben / übertragenen Daten sind weg. Das gleiche passiert auch mit neu aufgesetzten Clients und Test VM ohne weitergehene Konfigurationen. Änderungen an den RDP Verbindungseinstellungen auf den Clients brachten keine Verbesserung. Die statische Route am LAN Interface ist soweit ich das weiss und bisher auch anderswo umgesetzt habe richtig eingerichtet, der Haken bei 'Bypass firewall rules for traffic on the same interface' ist gesetzt - siehe https://docs.netgate.com/pfsense/en/latest/book/routing/static-routes.html.

Dazu muss ich anmerken: das hat alles schon längere Zeit funktioniert bis eine pfSense in Spiel kam.

Zentraler Router war bis vor kurzem ein Windows Server mit Routing und RAS welcher gegen eine pfSense Installation (Hardware Supermicro 5018D-FN8T) getauscht wurde. Der Terminalserver ist an einem anderen Standort in einem anderen Netzwerk und wird nicht von uns betreut. Die Verbindung dort hin stellt ein vom Fremdanbieter bereitgestellter separater Cisco VPN Router her. In der pfSense ist (so wie ehemals am Windows Server mit R&R auch) dieser Router als weiterer Gateway eingetragen, dazu noch eine statischen Route für das betreffende entfernte Netzwerk über diesen Gateway, Haken bei 'Bypass firewall ...' rein und gut ist. Die PC Clients bekommen normalerweise per DHCP die pfSense als Standardgateway mitgeteilt und wenn die eine RDP Verbindung (per IP, keine DNS Nutzung, kein RDP Gateway) in das entfernte Netzwerk aufbauen wollen wird der Traffic an der pfSense zu dem sep. Cisco Router im Netzwerk als Router für das entfernte Netzwerk umgeleitet und gut ist. So die Idee und Umsetzung, alles kein Hexenwerk, oft genug anderswo gemacht. Mit dem ehem. Windows Server als Router und einer statischen Route in diesem hat das auch über Jahre funktioniert. Mit der pfSense geht das von Anfang an nicht. Wenn wir den PC und den Druckern den Cisco Router als Standardgateway geben dann funktioniert alles so wie es soll aber das kann nicht die Lösung sein. Auf den Cisco Router haben wir keinen Zugriff und auf dem TS auch keine weitergehenden Rechte um irgendwelchen exotischen Dinge zum Monitoring zu installieren. Das ist halt ein Produktivsystem was von vielen anderen auch benutzt wird. Wir haben keine Möglichkeit gefunden das Problem anderswo funktionierend (also mit diesem Problem) nachzustellen. Recherchen im Internet haben bisher auch nichts schlüssiges ergeben. Die Routing Tabelle der pfSense sieht gut aus. Ich vermute ein Problem mit den Firewall Regeln ähnlich wie es früher schon einmal gab, siehe https://redmine.pfsense.org/issues/1950.

Die pfSense hat keine wesentliche komplizierte Einrichtung: aktuelle 2.4.4p3 Standardinstallation, 1x WAN Anschluss mit fester IP (TCom Standleitung), 1x LAN, 2 weitere Netzwerke an zwei weiteren NIC (nur Zugriff dort hinein, kein Routing, keine Gateways dort hinein, auch mal abgeschalten - ohne Änderung), den zusätzlichen Gateway + die statische Route in das Fremdnetz darüber, Haken gesetzt bei System / Advanced / Firewall & NAT / Bypass firewall rules for traffic on the same interface, DNS per Resolver, DHCP Server an LAN, IPsec VPN, OpenVPN, außer 'OpenVPN Client Export' keine Pakete installiert, im Prinzip rein nur IPv4 Nutzung an der Firewall und in den Netzwerken und gut ist.

Als Bonus: das ganze existiert ein zweites mal und das Problem ist exakt das gleiche. Anderer Standort, nur minimal anderes Netzwerk, auch dort wurde ein Windows Server mit Routing und RAS (zeitgleich zur ersten Installation) ersetzt durch eine baugleiche pfSense, die Clients in diesem Netzwerk verbinden sich auch über einen sep. Cisco VPN Router (des gleichen Fremdanbieters) in das gleiche entfernte Netzwerk und nutzen den gleichen entfernten Terminalserver und haben das gleiche RDP Problem. Die beiden pfSense sind untereinander nicht verbunden. Beide wurden separat installiert, Installation ist nicht kopiert.

Wir können und wollen das Szenario auch nicht einfach so wieder zurückbauen. Wir könnten maximal noch mit einem gewissem Aufwand die Hardware testweise z.B. gegen eine APU4C4 tauschen, die Konfiguration nach NIC Anpassung übernehmen (oder neu einrichten, wie gesagt kein Hexenwerk) und damit ausschließen dass es ein hardwarespezifisches Problem der pfSense ist.

Die Idee war noch dass MTU / MSS nicht passt aber Änderungen diesbzgl. haben nichts gebracht. Auf der pfSense unter States sehe ich zeitweilig immer 2 Verbindungen von einem Client zum RDP Port des Zielsystem (eine mit dem State CLOSED:SYN_SENT und die andere mit SYN_SENT:CLOSED) und diese States verschwinden in dem Moment wenn die RDP Verbindung unterbrochen wird. Manchmal ist dabei (oder auch allein) noch eine Verbindung mit dem State ESTABLISHED:ESTABLISHED - wie für asymmetrisches Routing erklärbar - zu sehen und RDP ist dennoch nicht verbunden.

Ich habe nun schon wie in der pfSense Doku zusätzlich angegeben extra noch eine Firewall Regel an LAN und eine floating Regel eingerichtet - hat auch nichts gebracht. Des weiteren habe ich Outbound NAT auf Hybrid gestellt und zusätzlich noch ein manuelles Mapping für Verbindungen in dieses Netzwerk für TCP Verbindungen zu Port 3389 und Static Port gesetzt. Erst wenn diese zwei zusätzlichen Einrichtungen vorgenommen wurden scheint es nach einem Neustart eine ganze Zeit lang vernünftig zu laufen (die bypass firewall rules Option allein reicht absolut nicht aus wie es eigentlich sein sollte). Heute hat es uns nun wieder eingeholt und das Spielchen und die Sucherei begann von vorn. Ich verstehe schon nicht warum ich drei Einstellungen vornehmen muss wenn es doch auch eine allein tun sollte.

Ich habe sonst wie gesagt keine zündende Idee mehr warum die RDP Pakete der Clients (TCP) wenn die über die statische Route der pfSense zum Cisco VPN Router laufen anstatt direkt zu diesem (als Gateway und dann über den VPN Tunnel zu dem Terminalserver) scheinbar aussetzen. Asymmetrische Routing hin oder her, das muss die pfSense doch können. Das passiert nicht unbedingt zeitgleich auf mehreren Client PC. Das passiert auch wenn gar nur zwei Client PC Verbindung zum entfernten TS haben, also kein Mengenproblem. Sonst sind keinerlei Auffälligkeiten von Verbindungsproblemen über die pfSense feststellbar. Alle andere funktioniert augenscheinlich wie es soll. Großes Equipment zum Testen dieser Verbindung kann ich halt nicht nutzen weil der separate Router und der Endpunkt nicht unter meiner administrativen Kontrolle stehen.

Das wäre meine ursprüngle Frage gewesen. Wie vorhin bereits beschrieben: erst einmal gelöst aber ich hätte gern gewusst warum das so sein muss. Woanders geht es auch ohne solche Umstände.

JeGr

@bon-go said in Frage wg. Probleme mit statischer Route:

Wie vorhin bereits beschrieben: erst einmal gelöst aber ich hätte gern gewusst warum das so sein muss. Woanders geht es auch ohne solche Umstände.

Da kann ich leider nur die Schultern zucken, nach der Wand aus Text. Zum Einen haben wir - wo immer so eine Konstellation entsteht - versucht, asymmetrisches Routing zu vermeiden - also gar keinen Fremdrouter reinbringen lassen, sondern gleich klarstellen: Tunnel machen wir selbst und gut ist. Nur in extrem renitenten und beratungsresistenten Fällen wollen Dienstleister unbedingt einem ihre Hardware aufschwatzen. Ist jetzt natürlich kein Lösungsansatz aber schlichtweg eine Sache die man immer zuerst versuchen sollte.

Ansonsten hatten wir solche Konstellationen schon und die haben reibungslos funktioniert. Witzig daran, dass das kein super-duper-Cisco war, sondern meist irgendwelche einfacheren Teile. Das letzte was schon etwas her ist, war ein Lancom als zweiter Router mit im Spiel. Route drauf gesetzt, Bypass an und gut.

Aber: was hire mit reinspielen könnte(!) ist, dass wir generell NAT immer manuell auf ein Mindestmaß konfigurieren. Kein Hybrid, kein Automatisch. Zusätzlich PureNAT bzw. disabled als default. Bypass und Auto-Creation of NAT Oubound Rules (für PureNAT und Redirects).

Was ich mir vorstellen könnte, weil mir da ASAs auch schon ein paar Mal in die Suppe gespuckt haben ist, dass die außer dem VPN da irgendwas Routing oder Masquerading mäßiges eingestellt haben, was die Pakete ggf. nochmal umschreibt und daher die pfSense abwirft. Tatsächlich debuggen ließe sich das aber wahrscheinlich nur direkt an einem Client und der Sense um dann mal direkt mit nem TCPDump zu loggen, was raus und reingeht und worüber und wie - und was sich nach Einfügen der Regeln ändert. Das ist aber kein Problem "das muss die pfSense doch können", sondern diese Aussetzer sehen mir eher danach aus, als würde zwischen der ASA und der pfSense was schief laufen wobei ich da der Erfahrung nach (und weil schon einige Male vorgekommen, nicht weil ich pfSense in Schutz nehmen will) eher in Richtung ASA tippe. Klar, wenn man die direkt einträgt geht immer alles. Auch mit dem Windows vorher, wobei ich da vorsichtig wäre, da (ich vermute ISA Server?) die auch einiges an automatik-Proxy und sonstigen kleinen Schweinereien mit eingebaut haben.

Andere Frage um den ganzen Nonsense mit Asymmetrie wegzubekommen: Du schreibst der andere Dienstleister bringt die ASA eben dahin und die muss da sein. Gut angenommen. Aber habt ihr mal versucht, ob ihr die nicht einfach direkt an einen extra Port an der Sense hängen könntet? Also extra Interface (TS_DMZ oder sowas), direkt ASA dahin, anderes Netz dazwischen (sollte der Dienstleister ja konfigurieren können) und dann einfach "richtig" routen? Müsste der Dienstleister nur auf beiden Seiten eben das TS_DMZ Transfernetz noch mit ins IPSec aufnehmen (muss aber nicht, weil daher ja eigentlich kein Traffic zum TS kommt) und das ASA Interface in ein anderes Netz konfigurieren und fertig. Dann gibts kein Verbiegen und kein umrouten mehr, sondern einfach klassiches Routing, normale Firewall-Regeln rein und fertig ist der Lack. Wenn ihr schon die ASA nicht loswerdet und selbst den Tunnel machen könnt, wäre das die einfachste Methode anstatt das Ding im gleichen Netz zu haben. Ich würde das tatsächlich vorziehen, weil man dann auch sauber das Filtering ordentlich zentral an einer Stelle (Sense) hat und so auch auf dem TS_DMZ Interface eingehend auf den TS (oder gar keine eingehenden Verbindungen) beschränken kann. Wenn ihr nämlich nur von euch aus auf den TS müsst, der aber nicht zu euch, wäre die Methode wesentlich besser aus Security Sicht, weil dann ein Durchgriff in euer Netz nicht möglich ist. So müsst ihr der ASA und dem Dienstleister trauen (ob der seine ASAs auch geupdated hat von den letzten Bugs etc.).

Vielleicht bringt euch das etwas weiter in der Analyse oder im Bezug auf sicherer umbauen :)

Grüße

bon-go

Erstmal vielen lieben Dank für deine Mühe diese Wand aus Text zu lesen, dich damit zu befassen und auch noch so umfassend drauf zu antworten. Das was du in Bezug auf NAT geschrieben hast hilft mir schon mal einiges weiter. Ich lass es grad noch so wie ich es zuletzt eingestellt hab, es wird noch selektiv getestet. Das nächste wäre dann an dieser Schraube rumzudrehen oder s.u. .

Log auf der pfSense habe ich mich mit befasst, ist halt nur eine Seite. Das parallel an den Testclients oder über ein MITM Device zu fahren hatte ich noch nicht gemacht, wird aber werden müssen wenn wir die ursächlichen Probleme erkennen wollen. Alles Aufwand, wollte ich vermeiden wenn geht, trägt u.U. nicht zur Lösung bei wenn die Konstellation bleibt wie sie ist, man würde evtl. nur erfahren warum es nicht funktioniert.

An dem Windows Server (kein ISA, auch deswegen und weil alt: Rauswurf) war nichts spezielles eingerichtet. Den hab ich noch da und kann den auch so starten, hab das mehrfach kontrolliert - nichts besonderes gefunden.

Auch wenn mir das die liebste Lösung wäre: wir können dem Kunden und dem TS Dienstleister - der doch einiges größer ist und mit dem TS und der Software darauf deutschlandweit operiert - im Moment schlecht verklingeln dass wir - die wir nachträglich dazugekommen sind - mal eben sagen und vorschreiben wie der VPN Tunnel aufgebaut wird. Da geht erstmal kein Weg rein. Da kommt dann auch der Spruch 'das ging bisher ja auch' und 'andere machen das auch' usw. . Müssen wir wohl absehbar mit leben. Die von dir angesprochene Alternative - die mir sehr gefällt - den Cisco umzukonfigurieren so dass der in eine DMZ kommt - sprich einfach ein anderes LAN Segment und eine weitere Zielroute zuzuweisen - wird für die 'einfach zu aufwändig', hatten wir schon kurz angesprochen, wollen die nicht mal eben so machen. Die Alternative wäre das primäre Netzwerk umzukonfigurieren aber auch das steht im Moment in keinem Verhältnis, da sind wir länger beschäftigt. Da ist sehr viel zu beachten, da laufen an dem einen Standort x Server und xx Diagnosegeräte, wird wohl eher nicht passieren. Wenn sich das Problem weiterhin manifestiert werde ich den Kunden so richtig gut überzeugen müssen (Argument ASA Updates und Pflege, weiss kein Mensch hier) und mit dem Kunden zusammen dem Dienstleister die Pistole auf die Brust setzen dass der die Cisco entspr. umkonfiguriert. Das ist einer der letzten Wege, erfordert Überzeugungsarbeit, wäre aber eine saubere Lösung. Das mit dem Routing der Druckjobs in das Kundennetz lässt sich auch lösen, müssen die an der ASA machen.

Aktuell läuft es zeitweilig unter Beobachtung mit einem Testclient. Falls das dennoch bleibt ist der nächste Schritt mehr Dumps zu erzeugen und damit das Problem einzukreisen sofern es bleibt. Danach läuft es auf Überzeugung des Kunden und Druck auf den TS Dienstleister hinaus.

Danke für deine Hilfe, ich bleibe dran, das Thema ist noch nicht durch weil wir das noch testen lassen.

Grüße