7
Session basiertes Routing
Moin in die Runde!
Habe ein Problem mit einer ZyWall USG300 und einem dynamischen Routing.
Bestehendes Problem:
Es wird eine USG300 mit drei normalen DSL Anschlüssen betrieben. Ziel ist es mehr Bandbreite für das dahinterliegende Netzwerk zu ermöglichen. Soweit auch kein Problem, ein Trunk, drei Anschlüsse, dynamische Lastverteilung der ZyWall.
Jetzt tritt aber das Problem auf, wenn ich eine Session beginne, das mal zehn Pakete über Anschluss A, dass zehn über B, zehn über C, usw. herausgeroutet werden. Beim normalen Surfen kein Problem. Wenn ich aber eine IPSec Verbindung, oder eine Onlinebanking Session betreiben bricht die Gegenseite sofort ab, sobald ich einen anderen Anschluss (und somit eine andere IP) nutze. Eine statische Route (über Anschluss A, B oder C) für jeden betroffenen User im LAN behebt das Ganze, widerspricht aber dem dynamischen Routing der Anfangsüberlegung, weil er dann immer diesen Anschluss nutzt. Dienstebasierend ist schlecht, da ich nicht weiß, welche Dienste alle genutzt werden.
Kann mir jemand helfen? Gibt es ein Session basiertes Routing ( Wenn nach IP XY, dann route immer über den Trunk A, B oder C )???
Besten Dank
equadrat22
Es wird eine USG300 mit drei normalen DSL Anschlüssen betrieben. Ziel ist es mehr Bandbreite für das dahinterliegende Netzwerk zu ermöglichen. Soweit auch kein Problem, ein Trunk, drei Anschlüsse, dynamische Lastverteilung der ZyWall.
Jetzt tritt aber das Problem auf, wenn ich eine Session beginne, das mal zehn Pakete über Anschluss A, dass zehn über B, zehn über C, usw. herausgeroutet werden. Beim normalen Surfen kein Problem. Wenn ich aber eine IPSec Verbindung, oder eine Onlinebanking Session betreiben bricht die Gegenseite sofort ab, sobald ich einen anderen Anschluss (und somit eine andere IP) nutze. Eine statische Route (über Anschluss A, B oder C) für jeden betroffenen User im LAN behebt das Ganze, widerspricht aber dem dynamischen Routing der Anfangsüberlegung, weil er dann immer diesen Anschluss nutzt. Dienstebasierend ist schlecht, da ich nicht weiß, welche Dienste alle genutzt werden.
Kann mir jemand helfen? Gibt es ein Session basiertes Routing ( Wenn nach IP XY, dann route immer über den Trunk A, B oder C )???
Besten Dank
equadrat22
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 141322
Url: https://administrator.de/contentid/141322
Printed on: April 26, 2024 at 14:04 o'clock
7 Comments
Latest comment
Das ist nicht nur bei IPsec so, sondern auch beim Surfen. Was du da oben beschreibst ist technisch gar nicht möglich und mit Routing hat es auch nicht das geringste zu tun sehr wohl aber mit Link Load Balancing !!
Innerhalb einer Session darf es niemals zu einem per packet Load Balancing kommen. Das ist auch logisch, wenn du dir nur einmal den Packetfluss einer Session vor Augen führst.
Du bauste eine TCP 80 (HTTP) Verbindung auf zu einem Zielserver. Da deine Zywall ja NAT macht ist z.B. die Absenderadresse die aktuelle IP des DSL Links 1, Session ist aufgebaut und Antwortpakete schickt die Zywall nun an den Server mit der Absender IP von DSL Link 3. Der TCP Stack im Server merkt aber nun das z.B. ACK Pakete zu einer bestehenden IP Session mit einmal mit einer komplett anderen Absender IP kommen (DSL 2). Dadurch gibt es sofort einen Session Reset und damit einen Abbruch.
Per Paket Load Balancing ist nur mit einer Multilink PPP Session supportet was aber so gut wie kein Provider anbietet und auch nur sehr wenige HW supportet. Deine Zywall kann es vermutlich auch nicht...
Die Zywall kann also niemals ein per Packet Load Balancing machen sondern immer nur ein sessionbasierendes Load Balancing das liegt in der Natur der (NAT) Sache.
Leider schreibst du nicht welche Art von IPsec du machst. AH geht so oder so nicht und ESP klappt nur mit NAT Traversal (NAT-T) wenn dein IPsec Client (oder der IPsec Server) kein NAT Traversal supportet, dann bleibt die Session NAT Prozess hängen.
Hier musst du immer mit statischem Port Forwarding am Router arbeiten und UDP 500 und das ESP (IP Protokoll Nummer 50) auf den IPsec Client forwarden. Sonst wird es generell nichts der IPsec Session !
Innerhalb einer Session darf es niemals zu einem per packet Load Balancing kommen. Das ist auch logisch, wenn du dir nur einmal den Packetfluss einer Session vor Augen führst.
Du bauste eine TCP 80 (HTTP) Verbindung auf zu einem Zielserver. Da deine Zywall ja NAT macht ist z.B. die Absenderadresse die aktuelle IP des DSL Links 1, Session ist aufgebaut und Antwortpakete schickt die Zywall nun an den Server mit der Absender IP von DSL Link 3. Der TCP Stack im Server merkt aber nun das z.B. ACK Pakete zu einer bestehenden IP Session mit einmal mit einer komplett anderen Absender IP kommen (DSL 2). Dadurch gibt es sofort einen Session Reset und damit einen Abbruch.
Per Paket Load Balancing ist nur mit einer Multilink PPP Session supportet was aber so gut wie kein Provider anbietet und auch nur sehr wenige HW supportet. Deine Zywall kann es vermutlich auch nicht...
Die Zywall kann also niemals ein per Packet Load Balancing machen sondern immer nur ein sessionbasierendes Load Balancing das liegt in der Natur der (NAT) Sache.
Leider schreibst du nicht welche Art von IPsec du machst. AH geht so oder so nicht und ESP klappt nur mit NAT Traversal (NAT-T) wenn dein IPsec Client (oder der IPsec Server) kein NAT Traversal supportet, dann bleibt die Session NAT Prozess hängen.
Hier musst du immer mit statischem Port Forwarding am Router arbeiten und UDP 500 und das ESP (IP Protokoll Nummer 50) auf den IPsec Client forwarden. Sonst wird es generell nichts der IPsec Session !
WOW,
klingt gut und leuchtet mir ein.
Also dürfte das Phänomen einen anderen Grund haben. Wie gesagt, wenn ich keine feste Route für den Client einstelle klappt es mit der VPN Einwahl des Teilnehmers´nicht. Onlinebanking geht auch nicht. Normales surfen geht aber.
Wo könnte denn dann der Haken sein?
Welche Art von VPN genau genutzt wird kann ich nicht sagen, da nicht mein Gerät. Gehen wir aber davon aus, dass alle theoretischen Verbindungen laufen sollten.
klingt gut und leuchtet mir ein.
Also dürfte das Phänomen einen anderen Grund haben. Wie gesagt, wenn ich keine feste Route für den Client einstelle klappt es mit der VPN Einwahl des Teilnehmers´nicht. Onlinebanking geht auch nicht. Normales surfen geht aber.
Wo könnte denn dann der Haken sein?
Welche Art von VPN genau genutzt wird kann ich nicht sagen, da nicht mein Gerät. Gehen wir aber davon aus, dass alle theoretischen Verbindungen laufen sollten.
Hallo,
das VPN-Problem ist von aqui schon sehr gut erklärt worden.
Du solltest versuchen, SSL-VPN zu realisieren, falls es die Gegenstelle unterstützt..
Wenn du Onlinebanking über Browser per HTTPS nutzen möchtest, so empfehle ich Protocol-Binding. Damit bindest du bspw. sämtliche HTTPS-Angelegenheiten an WAN1.
Wie das mit der Zywall zu machen ist, weiß ich nicht. Ich habe das mit diversen Netgear Dual-WAN-Routern so gemacht.
das VPN-Problem ist von aqui schon sehr gut erklärt worden.
Du solltest versuchen, SSL-VPN zu realisieren, falls es die Gegenstelle unterstützt..
Wenn du Onlinebanking über Browser per HTTPS nutzen möchtest, so empfehle ich Protocol-Binding. Damit bindest du bspw. sämtliche HTTPS-Angelegenheiten an WAN1.
Wie das mit der Zywall zu machen ist, weiß ich nicht. Ich habe das mit diversen Netgear Dual-WAN-Routern so gemacht.
@equadrat22
Du verwechselst hier wohl etwas... Was genau meinst du mit "...wenn ich keine feste Route für den Client einstelle" ???
Eine feste Route für einen Client einzustellen ist doch Unsinn, denn du weisst doch gar nicht in welchen der 400.000 IP Netzen des Internes sich dein Client befindet oder hast du soviel statische Routen eingestellt ?? Oder meinst du mit dem statischen Routen das z.B. IPsec Sessions nur Link 2 von deinen 3 aktiven Links nutzen ??
Dein Problem ist vermutlich folgendes:
Für deinen Client musst du ja logischerweise eine der 3 DSL IPs angeben von einem deiner 3 Links als Tunnel Endpunkt bzw. VPN Ziel. Hast du die Zywall nun nicht so eingestellt das sie bei eingehenden IPsec auch wieder als Antwort genau diesen Link nimmt kann es passieren das sie ein Link Load Balancing macht und z.B. diese Session of Link 1 beantwortet.
Ist aber Link 2 vom VPN Client angesprochen worden antwortet die Zywall ja nun wieder mit einer anderen IP und IPsec vermutet sofort (und richtigerweise) eine "Man in the Middle" Attacke und bricht augenblicklich den Verbindungsaufbau ab.
Genau also was du siehst und das auch richtigerweise.
Wenn die Zywall also auch dein VPN Server ist musst du zwangsläufig IPsec auf einen der 3 Links festlegen. Es darf dort kein Load Balancing geben. IPses ist dafür nicht gemacht !
Normalerweise müsste die Zywall ein sog. Nailing machen für eingehende IPsec Sessions aber ob das bei so Billig FWs auch umgesetzt wird ist fraglich. Konfigurierbar muss es aber in jedem Falle sein !!
Du verwechselst hier wohl etwas... Was genau meinst du mit "...wenn ich keine feste Route für den Client einstelle" ???
Eine feste Route für einen Client einzustellen ist doch Unsinn, denn du weisst doch gar nicht in welchen der 400.000 IP Netzen des Internes sich dein Client befindet oder hast du soviel statische Routen eingestellt ?? Oder meinst du mit dem statischen Routen das z.B. IPsec Sessions nur Link 2 von deinen 3 aktiven Links nutzen ??
Dein Problem ist vermutlich folgendes:
Für deinen Client musst du ja logischerweise eine der 3 DSL IPs angeben von einem deiner 3 Links als Tunnel Endpunkt bzw. VPN Ziel. Hast du die Zywall nun nicht so eingestellt das sie bei eingehenden IPsec auch wieder als Antwort genau diesen Link nimmt kann es passieren das sie ein Link Load Balancing macht und z.B. diese Session of Link 1 beantwortet.
Ist aber Link 2 vom VPN Client angesprochen worden antwortet die Zywall ja nun wieder mit einer anderen IP und IPsec vermutet sofort (und richtigerweise) eine "Man in the Middle" Attacke und bricht augenblicklich den Verbindungsaufbau ab.
Genau also was du siehst und das auch richtigerweise.
Wenn die Zywall also auch dein VPN Server ist musst du zwangsläufig IPsec auf einen der 3 Links festlegen. Es darf dort kein Load Balancing geben. IPses ist dafür nicht gemacht !
Normalerweise müsste die Zywall ein sog. Nailing machen für eingehende IPsec Sessions aber ob das bei so Billig FWs auch umgesetzt wird ist fraglich. Konfigurierbar muss es aber in jedem Falle sein !!
Sorry aqui,
wenn man versucht sich kurz zu fassen geht leider das Ein oder Andere unter. Also jetzt noch einmal ausführlicher.
Ich habe die Zywall mit mehreren DSL Anschlüssen. WAN1, WAN2 und WAN3. Dahinter ein LAN. In diesem LAN befinden sich ca. 50 Clients. Auf diese habe ich keinen Zugriff, da dieses Kundengeräte sind. Diese Kunden können und dürfen auch alle Dienste nutzen die sie wollen (VPN, Banking, etc.). Es ist nun des Öfteren vorgekommen, dass sich ein Kunde meldet, dass er mit seinem VPN Client (auf einem Rechner installiert) keine Verbindung zu seinem Firmenserver herstellen kann. Andere meldeten sich, dass sie kein Homebankng machen können.
Daraufhin konnte ich nun auf die schnelle eine Lösung schaffen, indem ich eine "feste Route" konfiguriert habe. Es gibt nun vier Trunks. Trunk1 beinhaltet alle Leitungen, Trunk2 nur Leitung1, Trunk3 nur Leitung2 und Trunk4 Leitung3. Ich sage nun, wenn Client A mit fester IP X (ist mir bekannt) eine Verbindung aufbaut, dann immer über Trunk2, Client B mit IP Y immer über Trunk3, ... Diese Lösung führt erstmal dazu das alles läuft, widerspricht aber der Absicht das load balancing der Zywall zu überlassen.
Besten Dank für Deine Hilfe.
wenn man versucht sich kurz zu fassen geht leider das Ein oder Andere unter. Also jetzt noch einmal ausführlicher.
Ich habe die Zywall mit mehreren DSL Anschlüssen. WAN1, WAN2 und WAN3. Dahinter ein LAN. In diesem LAN befinden sich ca. 50 Clients. Auf diese habe ich keinen Zugriff, da dieses Kundengeräte sind. Diese Kunden können und dürfen auch alle Dienste nutzen die sie wollen (VPN, Banking, etc.). Es ist nun des Öfteren vorgekommen, dass sich ein Kunde meldet, dass er mit seinem VPN Client (auf einem Rechner installiert) keine Verbindung zu seinem Firmenserver herstellen kann. Andere meldeten sich, dass sie kein Homebankng machen können.
Daraufhin konnte ich nun auf die schnelle eine Lösung schaffen, indem ich eine "feste Route" konfiguriert habe. Es gibt nun vier Trunks. Trunk1 beinhaltet alle Leitungen, Trunk2 nur Leitung1, Trunk3 nur Leitung2 und Trunk4 Leitung3. Ich sage nun, wenn Client A mit fester IP X (ist mir bekannt) eine Verbindung aufbaut, dann immer über Trunk2, Client B mit IP Y immer über Trunk3, ... Diese Lösung führt erstmal dazu das alles läuft, widerspricht aber der Absicht das load balancing der Zywall zu überlassen.
Besten Dank für Deine Hilfe.
Das war schon klar aber du benutzt die Worte routen, Trunk usw. völlig aus dem Zusammenhang gerissen bzw. artfremd vermutlich in Unkenntnis deren wirklicher Bedeutung, deshalb ist etwas manchmal etwas schwierig deinen Ausführungen zu folgen...nundenn.
Das Verhalten was du schilderst ist eigentlich ein vollkommen klassisches Link Load Balancing was andere Router wie z.B. die von Draytek aus dem FF beherrschen...auch mit Homebanking und IPsec Sessions.
Das Verhalten, zumal du auch schreibst..des Öfteren vorgekommen was darauf schliessen lässt das es nicht immer vorkommt, lässt dann eher auf einen Firmware Bug bzw. eine unsaubere Implememtation dieser Funktion in der Zywall schliessen. Ggf. aber auch ein zu schnelles Austimen der NAT Session Tabelle. Ggf. solltest du das tunen wenn das konfigurierbar ist wie in besseren Systemen..
Das du das aktuellste Firmware Image geflasht hast setzen wir hier mal vorauss und sollte nicht zur Diskussion stehen !
Ein Nailing von Sessions so wie du es machst ist eigentlich überflüssig, da es gar nicht passieren darf und zeigt wie oben bereits bemerkt das es zu Resourcen Probleme führt durch vermutlichen Sessionabbruch da die NAT Tabelle inkonsistent ist oder eben durch einen Bug.
Das kann man aber ohne genauere Analyse des syslogs der Zywall (sofern sie sowas überhaupt hat ??) nie beantworten. Außerdem wäre es hilfreich eine soclhe abgebrochene Session mal zu sniffern um zu sehen was dort genau passiert um die Zywall Hotline damit zu konfrontieren.
Vermutlich hast du das aber noch nicht gemacht, oder ?
Das Verhalten was du schilderst ist eigentlich ein vollkommen klassisches Link Load Balancing was andere Router wie z.B. die von Draytek aus dem FF beherrschen...auch mit Homebanking und IPsec Sessions.
Das Verhalten, zumal du auch schreibst..des Öfteren vorgekommen was darauf schliessen lässt das es nicht immer vorkommt, lässt dann eher auf einen Firmware Bug bzw. eine unsaubere Implememtation dieser Funktion in der Zywall schliessen. Ggf. aber auch ein zu schnelles Austimen der NAT Session Tabelle. Ggf. solltest du das tunen wenn das konfigurierbar ist wie in besseren Systemen..
Das du das aktuellste Firmware Image geflasht hast setzen wir hier mal vorauss und sollte nicht zur Diskussion stehen !
Ein Nailing von Sessions so wie du es machst ist eigentlich überflüssig, da es gar nicht passieren darf und zeigt wie oben bereits bemerkt das es zu Resourcen Probleme führt durch vermutlichen Sessionabbruch da die NAT Tabelle inkonsistent ist oder eben durch einen Bug.
Das kann man aber ohne genauere Analyse des syslogs der Zywall (sofern sie sowas überhaupt hat ??) nie beantworten. Außerdem wäre es hilfreich eine soclhe abgebrochene Session mal zu sniffern um zu sehen was dort genau passiert um die Zywall Hotline damit zu konfrontieren.
Vermutlich hast du das aber noch nicht gemacht, oder ?
Hallo,
ist zwar schon etwas länger still in diesem Thread, aber vielleicht helfen meine Erläuterungen noch anderen, die wie ich beim googlen hierüber fallen...
Das beschriebene Verhalten ist kein Bug in der Firmware der Zywall. Solange eine TCP-Session aktiv ist, wird der Traffic auch über den selben WAN-Link geführt (und ggf. auf die ursprünglich verwendete öffentliche IP-Adresse genattet).
Es ist jedoch _nicht_ so, dass es eine lange TCP-Session gäbe, solange man sich mit einem Browser auf einer Website befindet. Vielmehr werden ständig TCP-Sessions auf- und abgebaut. Das kann man mit einem Sniffer oder im Firewalllog sehr schön beobachten. Sobald aber eine neue Session aufgebaut wird, schlägt der Loadbalancing-Algorithmus erneut zu und verteilt die neue Session ggf. auf einen anderen WAN-Link. Normalerweise ist dies dem Zielserver auch "Wurst", denn bis zum Layer 4 ist alles ok - innerhalb der selben (TCP-)Session wechselt die Source-IP nicht.
Ein Problem entsteht aber dann, wenn auf höheren Layern eine Session-Logik zwischen Server und Client etabliert wurde und diese Logik aus Sicherheitsgründen vom Server mit der Source-IP des Clients verknüpft wurde. Dies wird häufig gemacht, wenn die Website eine Authentifizierung für den Zugriff auf personalisierte Daten erfordert (wie z.B. beim Onlinebanking - siehe Sachverhalt).
Um dieses Problem zu umgehen hat jeder halbwegs brauchbare Multi-WAN-Router eine Logik, wonach er innerhalb eines gewissen Zeitfensers Traffic eines Clients zum gleichen Zielserver über die selbe WAN-Strecke schiebt. Sowohl bei den ZyNOS- als auch bei den Linux-basierenden Zywalls ist diese Funktion (sofern die Firmware nicht völlig veraltet ist) nicht nur übers CLI sondern sogar über das WebGUI konfigurierbar. Siehe http://www.zyxel.com/web/support_knowledgebase_detail.php?KnowledgeBase ... Es ist zu vermuten, dass diese Option hier nicht gesetzt oder das Timeout zu kurz gewählt wurde.
Gruß
Steffen
ist zwar schon etwas länger still in diesem Thread, aber vielleicht helfen meine Erläuterungen noch anderen, die wie ich beim googlen hierüber fallen...
Das beschriebene Verhalten ist kein Bug in der Firmware der Zywall. Solange eine TCP-Session aktiv ist, wird der Traffic auch über den selben WAN-Link geführt (und ggf. auf die ursprünglich verwendete öffentliche IP-Adresse genattet).
Es ist jedoch _nicht_ so, dass es eine lange TCP-Session gäbe, solange man sich mit einem Browser auf einer Website befindet. Vielmehr werden ständig TCP-Sessions auf- und abgebaut. Das kann man mit einem Sniffer oder im Firewalllog sehr schön beobachten. Sobald aber eine neue Session aufgebaut wird, schlägt der Loadbalancing-Algorithmus erneut zu und verteilt die neue Session ggf. auf einen anderen WAN-Link. Normalerweise ist dies dem Zielserver auch "Wurst", denn bis zum Layer 4 ist alles ok - innerhalb der selben (TCP-)Session wechselt die Source-IP nicht.
Ein Problem entsteht aber dann, wenn auf höheren Layern eine Session-Logik zwischen Server und Client etabliert wurde und diese Logik aus Sicherheitsgründen vom Server mit der Source-IP des Clients verknüpft wurde. Dies wird häufig gemacht, wenn die Website eine Authentifizierung für den Zugriff auf personalisierte Daten erfordert (wie z.B. beim Onlinebanking - siehe Sachverhalt).
Um dieses Problem zu umgehen hat jeder halbwegs brauchbare Multi-WAN-Router eine Logik, wonach er innerhalb eines gewissen Zeitfensers Traffic eines Clients zum gleichen Zielserver über die selbe WAN-Strecke schiebt. Sowohl bei den ZyNOS- als auch bei den Linux-basierenden Zywalls ist diese Funktion (sofern die Firmware nicht völlig veraltet ist) nicht nur übers CLI sondern sogar über das WebGUI konfigurierbar. Siehe http://www.zyxel.com/web/support_knowledgebase_detail.php?KnowledgeBase ... Es ist zu vermuten, dass diese Option hier nicht gesetzt oder das Timeout zu kurz gewählt wurde.
Gruß
Steffen