Verständnisfrage Routing VPN - Zwei Gateways

Ach so :c)

Wenn Du es ohne Maskierung zum laufen bekommen möchtest, mach ein Trace Route, das sagt Dir dann wo es hängt oder wer nicht mit spielt...

Da dann bitte das "+" an der richtigen Stelle im Text klicken, damit das Foto auch im richtigen Kontext zum Text erscheint !
(Kann man auch noch nachträglich machen.)
Das ist vermutlich auch normal weil die Sophos, Firewall üblich, mit an Sicherheit grenzender Wahrscheinlichkeit den lokal, statisch gerouteten Verkehr auch durch ihr Regelwerk schickt und du dafür sicherlich dann keine Regel hast.
Das ist etwas nervig und in der Regel auch sinnfrei statisch lokal gerouteten Traffic über das FW Regelwerk zu zwingen aber üblicherwiese Default.

Die meisten Firewalls haben dafür einen Haken im Setup den man entsprechend setzen kann wie hier z.B. bei der bekannten pfSense Firewall:
Das sollte bei deiner Sophos Gurke auch irgendwo im Setup zu finden sein.
Damit hat der Spuk dann ein Ende und dein VPN sollte sauber geroutet werden !

Es ist zu bezweifeln das die Sophos im VPN Tunnel den Traffic NATet (Adress Translation) so wie oben vermutet. Das wäre für eine Firewall absolut unüblich und dürfte sehr wahrscheinlich auch nicht der Fall sein, so das diese Option (vermutlich) nicht helfen wird, da gar nicht vorhanden.
Eine "Maskierung" ala NAT ist generell der falsche Weg da was Performance kostet und oft eine Routing Einbahnstrasse ist weil so transparentes Routing verhindert wird.
Deine statische Route im Lancom und kein NAT im Tunnel zu verwenden ist also aus Netzwerk Sicht genau richtig ! Tücke ist eben nur das die Sophos diesen gerouteten Traffic auch durch ihr Regelwerk schickt und diese Regel dort vermutlich fehlt. Siehe oben...

Du solltest zusätzlich auch noch im Hinterkopf haben das die lokale Winblows Firewall alles per Default blockt was nicht aus dem lokalen Netzwerk kommt. Also auch alles was aus dem VPN IP Netz kommt.
Ist der RDP Terminalserver also eine Winblows Gurke, musst du in die "Firewall mit erweiterten Eigenschaften" Settings gehen und den RDP Dienst in den Absender IPs dort entweder auf "beliebig" klicken oder dediziert dein 10er Netz VPN Netz angeben.
Was auch geht ist 10.0.0.0 Maske 255.0.0.0 als Range dann lässt der RDP Dienst alles zu was von remote aus 10er Subnetzen kommt solltest du noch mehr davon haben...

Poste doch mal hier einen Ausdruck vom Trace, dann musst Du nicht mehr raten.

Einmal vom VPN Client zum Terminal Server und einmal vom Terminal Server zum VPN Client.
Einer dieser zwei Wege funktioniert ja nicht :c)

Dann hast du auch den obigen Thread auch nicht richtig gelesen oder verstanden !!!
Es muss logischerweise deaktiviert werden, da jede Firewall auch lokal gerouteten Traffic immer durch ihr Regelwerk schickt !!!
Man will ja gerade NICHT das lokal gerouter Traffic durch die Firewall rennt ! Deshalb deaktivieren !
Genau das sagt ja oben auch das pfSense Setup ! "Bypass Firewall rules for local traffic" !
Lesen und verstehen...
Sofern deine Sophos Gurke so eine Einstellung nicht hat kannst du den Traffic dann nur mit zusätzlichen Regeln freigeben auf dem LAN Port.
So eine schlechte Firewall kann die Sophos aber nicht sein das sie dieses Allerwelts Feature nicht hat ! Oder etwa doch..?!?

Nein, das ist Blödsinn ! Ist ja mehr oder minder das gleiche zu dem was du jetzt auch hast nur das du das eben auf dem lokalen LAN routest.
Was auch immer die mit ihrem omniösen "maskieren" meinen ?!?
Hier rennt das mit 3 verschiedenen VPN Gateways im lokalen Netz (2x pfSense und 1x Cisco Router) vollkommen fehlerlos. Sollte es auch, denn es ist ja rein nur simpelstes IP Routing.

Es ist auch gut möglich das am Lancom eine Firewall am lokalen LAN Port werkelt. Der RDP Server Traffic kommt ja immer zuerst am Lancom an, denn der ist ja Default Gateway des RDP Servers.
Ist dort auch eine Firewall aktiv die Zieltraffic ins 10.81.230.0er Netz blockiert, dann kommt logischerweise keine Client Session zustande, klar.
Es ist also sehr wichtig das du das am Lancom kontrollierst ob das der Fall ist. Wireshark ist ggf. dein bester Freund hier.

Der Lancom würde normalerweise immer ein ICMP Redirect an den RDP Server schicken weil er ja "sieht" das der Server die Sophos Gurke im eigenen Netz besser direkt den Traffic schicken kann. Der Redirect bewirkt das der Server dann direkt nach der Sophos ARPen würde und den Traffic dann OHNE Umweg über den Lancom direkt zur Sophos sendet.
Im Default ist das ICMP Protokoll aber in der lokalen Winblows Firewall deaktiviert, so das diese den Redirect gar nicht mitbekommt und weiterhin fröhlich den Lancom als "Durchlauferhitzer" und Umwegschleife für den VPN Traffic benutzt.
Firewalls blockieren in der Regel auch ICMP Redirects und auch hier müsste man diese explizit freigeben am LAN Port.
In Konstellationen wie der deinen macht das also durchaus Sinn um denn Netztraffic effektiv zu redirecten !
Deine wichtigsten ToDos sind also

• den VPN Traffic Flow durch den Lancom zu checken und ggf. anzupassen
• Ggf. ICMP Redirects in RDP Server, Lancom und Sophos aktivieren.

Wenn die Sophos mit solch einfachsten Designs nicht umgehen kann stellt sich natürlich grundsätzlich dann auch die Frage warum du das Default Gateway des RDP Servers nicht sinnigerweise dann umstellst auf die 192.168.100.31 ?!
Wenn darüber eh alle remoten RDP Sessions via VPN reinkommen würde das ja Sinn machen. Dann auf der Sophos die statischen Routen zu den Lancom Netzen (sofern da überhaupt welche sind ?!) eintragen und gut iss.
Das wäre ja dann die intelligenteste Lösung wenn die Sophos Gurke nicht einmal simpelstes IP Routing im Netzwerk richtig kann. Ein Grund von sowas die Finger zu lassen.

Das heißt doch schon, dass der VPN Client gar keine Route zum 192.168.100.x/24 erhalten hat. Er will direkt in sein Internet.

der Mitarbeiter von Sophos legt den Finger in die richtige Wunde. Auch Aqui hatte das bereits indirekt angesprochen, die Problematik aber nicht näher erläutert, was vermuten lässt, dass er die tiefer liegende Ursache dann doch nicht auf dem Schirm hat.

Das Problem ist, dass Du eine Dreiecksroute gebaut hast. Rein bezogen aufs Routing ist das zunächst gar kein Problem, wenn der Lancom rein als klassischer Router fungieren würde. Er ist aber hier als SPI-Firewall im Einsatz, die offenkundig das Regelwerk auch auf Traffic anwendet, welcher über das eingehende Interface auch wieder rausgeroutet wird. Dies bedeutet zunächst einmal, dass Du auf dem Lancom zumindest eine entsprechende Allow-Regel benötigen würdest. Wenn Du diese einrichten würdest, solltest Du aber feststellen, dass dennoch nur ICMP und u.U. auch UDP funktionieren werden - nicht aber TCP-Traffic. Hintergrund ist, dass eine SPI-Firewall den TCP-Handshake vollständig mitlesen und die TCP-Sequenznummern der nachgelagerten Pakete überwachen muss, um den bidirektionalen Traffic einer TCP-Session zuordnen zu können. Nur dann kann die Firewall den Antworttraffic dynamisch zulassen. Im vorliegenden Fall sieht der Lancom aufgrund der Dreiecksroute aber immer nur einen Teil der bidirektionalen Kommunikation. Folglich dropt der Lancom den Verkehr, weil er für ihn unplausibel ist.
Lösen kann man dies auf zwei Wegen:
1) man gewöhnt dem Lancom ab, diesen Traffic durch das Firewallregelwerk zu jagen
2) man schafft das asymmetrische Routing ab.
Letztere Option wäre die bessere. Dies zu erreichen gibt es verschiedene Wege - einige wurden bereits angesprochen. Der simpelste Weg blieb bislang jedoch unerwähnt: sorge per statischer Route auf dem Terminalserver dafür, dass er VPN-Clients direkt über die Sophos anspricht. Das Standardgateway des TS kann dann vorerst weiterhin auf den Lancom zeigen.

Gruß
sk

Richtig ! Manchmal übersieht man das Simpleste im Eifer des Gefechts...
route add 10.81.230.0 mask 255.255.255.0 192.168.100.31 -p
auf dem RDP Server (Winblows) sollte das Problem dann auch lösen...
Jetzt könnte man noch diskutieren ob nicht besser immer die Router im Netz auch zentral routen sollten und nicht die Endgeräte was dann für ein Glattziehen der Lancom Regel spricht aber im Sinne einer unkomplizierten Lösung gewinnt dann das Obige.

👍

Da wir gerade genau das gleiche Problem haben, das du hattest, eine Frage dazu:


Wie? Wo genau hast du diese Funktion gefunden, wir suchen exakt das....

Die Situation ist:

Es werden zwei Firewalls (große vom Rechenzentrum für quasi alles und die eine Sophos XG für VPN / RDP). Bei den Clients im Netzwerk das Default Gateway auf die große Nicht-Sophos gesetzt.


Ich mixe mal unsere Beschreibung mit dem Original, weil da schon so viel gepasst hat.


Das Problem ist:

Die VPN Verbindung wird zur Sophos Firewall sauber aufgebaut und die Pakete treffen im Log auf der Sophos Firewall ein. Wenn nun aber eine RDP Sitzung mit einem PC im internen Netzwerk aufgebaut wird, fehlt natürlich die Rückantwort des PCs, da dieser das Default Gateway anspricht und die große Nicht-Sophos-Firewall nicht weiß was sie mit den Paketen machen soll.


Die Frage also:

Wie können wir den Clients, die für die Vor-Ort-Arbeit den anderen Standard Gateway behalten müssen, während der VPN-RDP-Verbindung die Sophos XG als Gateway setzen?


Vielen Dank!