Asymmetrisches Routing - keine Verbindung

Hi,
Ist logisch, ja.

By design TCP

Dann musst Du noch ein Transport-Netz zwischen Default-Router und VPN-Router einrichten. Das muss nicht zwangsweise ein eigenes physischens Segment sein (oder VLAN). Es sollte auch reichen, wenn Du dafür einfach ein anderes logisches Netz verwendest, z.B. 10.0.10.0/24. Wobei ein eigenes Segment natürlich auch sehr sinnvoll wäre.

E.

Nein, dein gravierender Denkfehler beginnt aber schon vorher !
Bedeutet, Clients aus dem Netz "10.0.0.0/24" welche auf das VPN Netz "192.168.1.0/24" zugreifen möchten, schicken die Datenpakete an ihr default Gateway "10.0.0.1/24"
...ist falsch. Das wäre sehr unökonomisch im TCP/IP und deshalb gibt es ja das ICMP Protokoll !
Die Clients schicken zwar ihre Pakete aber schon beim Verbindungsaufbau "merkt" das default Gateway durch die dort gesetzte statische Route (L3 FIB), das der Client im selben IP Segment sitzt wie das 2te lokale Gateway das ins 192.168.1.0er Netz routet.
Daraufhin schickt es ein ICMP Typ 5 Paket, sprich ein ICMP Redirect an den Client und informiert ihn mit diesem Redirect das er das Gateway im lokalen Netz direkt erreichen kann.
Damit ARPt der Client dann nach dem .254er Gateway und spricht dieses nun direkt ohne Umweg über die .1 an.
Nimm dir einen Wireshark und dann kannst du das auch live im Netz sehen !
Kein Umweg also und kein asymetrisches Routing !

Das deine Verbindung nicht zustande kommt hat also rein gar nichts mit dem Routing oder der Wegefundung zu tun.
Das ICMP klappt aber TCP nicht spricht zu 98% dafür das du irgendwo de facto ein Firewall Problem auf der Strecke hast.
Auch wenn du behauptest das es das nicht ist.
Deinen Äußerung:
ist schon irgendwie komisch. Das muss ja zwangsweise so sein, ansonsten kommt der VPN Tunnel doch gar nicht zustande ?
Die Frage ist irgendwie naiv. Mit dem Auto verglichen wäre das so als wenn du fragst warum das Auto färt wenn du den Tank vollmachst und warum es nicht fährt wenn der Tank leer ist...
Was erwartest du von einem Administrator Forum was man auf sowas antworten soll außer "Ja, dem ist nun mal so" ???

Hallo,

Bitte beachten: dein default Gateway 10.0.0.1 /24 und dein VPN Gateway 10.0.0.254/24 liegen im selben Netz!
Ein Routing innerhalb eines Netzes kann nicht funktionieren.....

brammer

...wenn er so intelligent war eine statische Route auf dem Default Gateway ala
ip route 192.168.1.0 mask 255.255.255.0 gateway 10.0.0.254
einzugeben dann funktioniert es schon !
Mit dem ICMP Redirect (s.o.) dann auch direkt vom Client.
Fragt sich nur ob er es denn war...?

Hallo tvprog1,

wie Du bereits richtiger Weise festgestellt hast, handelt es sich bei Deinem Szenario um sog. asymmetrisches Routing - d.h. Pakete in die eine Richtung nehmen zumindest teilweise einen anderen Weg, als die Pakete in die andere Richtung. Bezogen rein auf die Wegefindung und das Packetforwarding stellt dies auch kein Problem dar. Diese beginnen erst, wenn ein Hop auf der Strecke kein Router (mit ggf. statischen ACLs) , sondern eine Firewall ist, die den Status einer Verbindung berücksichtigt (SPI - stateful packet inspection). Eine SPI-Firewall muss (je nach Implementierung zumindest bei TCP-Traffic) die Pakete für beide Richtungen sehen, da sie anderenfalls den Status der Verbindung nicht auswerten kann. Sieht sie die Antwortpakete nicht, unterbricht sie den Traffic, weil er nicht plausibel ist. Im Falle einer TCP-Verbindung wird sie bereits beim Verbindungsaufbau eingreifen, da sie den TCP-Handshake nicht komplett mitverfolgen kann.
Das Verhalten Deines Default-Gateways weisst also darauf hin, dass es sich um eine durchaus brauchbare SPI-Firewall handelt. Reine Heimanwender-Gateways wie Fritzboxen und Möchtegern-Firewalls von Netgear, Ciscos RV-Serie (ehem. Linksys) usw. inspizieren den Traffic, der auf den selben Interfaces ein- und ausgeht schlicht nicht und haben daher damit (m.E. fälschlicher Weise) kein Problem. Leider schreibst Du nicht, um welches Modell es sich bei Deinem Default-Gateway handelt. U.U. wäre es durchaus möglich, Deinem Gerät beizubringen, dass dies erlaubt sein soll.
Besser wäre freilich, wenn keine asymmetrische Route vorhanden wäre. Der Lösungsvorschlag von emeriks, den VPN-Router in ein Transfernetz zu stellen, wäre aus meiner Sicht der Königsweg!

Der Hinweis von aqui auf ICMP Redirect verkennt den grundsätzlichen Design-Unterschied zwischen einem Router und einer guten Firewall. Der Aufgabenfokus eines Routers liegt auf optimaler Wegefindung und schnellem Packetforwarding. Eine Firewall hingegen hat in erster Linie die Aufgabe, konfigurierte Richtlinien durchzusetzen. Traffic per ausgehender ICMP Redirects von sich wegzuleiten, widerspricht grundsätzlich dieser Aufgabenstellung - eine Firewall soll alles inspizieren und durch ihr Regelwerk leiten, was sie an Traffic zu sehen bekommt! Eingehende ICMP Redirects sind auf einer Firewall ohnehin zu unterbinden, da sie naturgemäß erhebliches Mißbrauchspotenzial beinhalten. Aus diesem Grunde wird bei der Härtung eines dedizierten Firewall-Betriebssystems in der Regel der gesamte ICMP Redirect betreffende Code aus dem TCP/IP-Stack entfernt oder diese Funktionalität per Default deaktiviert und kann bestenfalls explizit wieder aktiviert werden - und zwar unabhängig davon, was das Firewallregelwerk besagt.
Ich hoffe, an dieser Stelle wird auch klar, weshalb renomierte Hersteller wie Cisco und Juniper sowohl Router (mit ggf. optionalem Firewall-Featureset) als auch dedizierte Firewalls im Portfolio haben. Der Aufgabenschwerpunkt und damit der Fokus für Funktions- und Designentscheidungen ist ein anderer.
Es ist also sehr wahrscheinlich, dass Dein Default-Gateway richtiger Weise keinen ICMP Redirect sendet, weil es eben in erster Linie eine Firewall und kein Router ist. Mit Sicherheit kann man dies aber nur sagen, wenn man sich den Traffic mal per Wireshark ansehen würde. Es kann auch sein, dass schlicht der Client die Redirects ignoriert oder ausfiltert. Aufgrund des erheblichen Mißbrauchspotentials wird diese Funktion in neueren Client-OS häufig deaktiviert oder durch eine "Desktop-Firewall" ausgefiltert. Ich meine mich z.B. zu erinnern, dass in der Windowsfirewall zumindest ab Win7 ICMP Redirects per Default geblockt werden.

Gruß
Steffen

Woher weisst du das so genau ?? Hast du einen detailierten Wireshark Trace ??
Wenn es wirklich stimmt ist es definitiv KEIN Netzwerk Problem mehr, da hast du Recht ! Jedenfalls keins was auf der Wegefindung (Routing) basiert.
Wenn dem wirklich so ist bleibt eigentlich nur ein MTU Problem !!!
Kann es sein das der VPN Tunnelrouter nicht entsprechend angepasst ist ??
Hier musst du zwingend einen MTU Anapssung machen, da du den VPN Overhead berücksichtigen musst. Zusätzlich auch noch PPPoE sollte es ein DSL Link sein ?!
Ist das nicht passiert negotiaten die Endsysteme 1500 Byte Paket Size Bei der MTU Negotiation. Real können aber im VPN dann nur 1390 Byte passieren.
Der VPN Router schmeisst dann alle diese Pakete weg die größer 1390 Byte sind. Das ist das fiese an dem Problem da du für kleinere Pakete keinen Fehler siehst im Wireshark.

Eigentlich sollte ein guter VPN Router diese MTU Anpassung bei VPN selber machen. Nur billige Schrotteile machen das nicht und erzwingen eine manuelle Konfig des Admins.
Das wäre möglich das das hier der Fall ist.
Mache einfach mal einen Ping mit einer 1500 Byte Paketlength (-l 1500) zum Ziel und check ob die ankommt !
Wenn nicht gehe Schritt für Schritt nach unten.
Der Break Even Point bei nicht angepasster MTU im VPN liegt so um die 1390 Byte je nachdem WAS für einen Art VPN (Protokoll und Verfahren) du verwendest und ob mit oder ohne GRE Tunnelinterface.
Leider schreibst du dazu ja rein gar nix, deshalb ist eine zielführende Hilfe nicht möglich

Sorry, meine Antwort war etwas platt.
Habe das auch schon mehrfach so beobachten müssen, dass, wenn man solche Doppelhops im selben Subnet hat, einige TCP-Verbindungen nicht zustande kommen. Oder laufend abbrechen. Ich bin da jetzt nicht ganz so fit, wie es @aqui offenbar ist.
Ich kann aber in jedem Fall das bestätigen, was @aqui geschrieben hat: Wenn beide Router mit dem Client im selben Netz sind, dann bekommt der Client von seinem Default-GW "gesagt", dass er sich doch bitte schön direkt an dan anderen Router wenden soll. D.h. die Kommunikation geht dann vollständig über den 2. Router. Ich weiß jetzt bloß nicht, ob sich der Client das dann merkt, und bei neuen TCP Session sofort über den anderen Router geht, oder ob das Spiel dann bei jeder TCP Session von vorne los geht. Falls letzteres, würde es mir meine eigenen Beobachtungen scheinbar erklären, warum da Session wegbrechen könnten.

Warum nicht? Wenn Du kein abgetrenntes Segment (oder auch VLAN) hast oder bauen kannst, dann könntest Du doch aber immer noch ein anderes IP-Subnet nehmen. Damit würde zumindest Routing-technisch alles "sauber" sein.

Nein, es ist sehr wahrscheinlich die logische Folge von Stateful Packet Inspection. Siehe mein Beitrag oben.

Gruß
Steffen

Womit du zweifelsfrei natürlich Recht hast aber der TO hat nicht klar benannt ob es ein Router oder eine SPI Firewall ist.
Das zu unser Ehrenrettung