Hallo,
in unserem Bürgernetz möchte sich ein Mitglied über eine VPN-Verbindung mit seinem Firmennetz (feste IP) verbinden. Leider kommt es dabei immer wieder zu Verbindungsbabbrüchen. Den Grund dafür ist das Wechseln der WAN-IP durch den Loadbalancer (wir benutzen den 1821+).
Deshalb habe ich zur Lösung des Problems einen Eintrag in der Routing Tabelle gemacht, der den kompletten Verkehr zur festen IP des Firma über einen der drei DSL-Anschlüsse routet. Den Routing-Eintrag hab ich testweise mit der IP der Seite www.wieistmeineip.de angelegt und die Funktion durch die IP-Anzeige erfolgreich getestet.
=> Leider hat dieser Routingeintrag nichts geholfen. Immer noch Verbindungsabbrüche beim VPN
Zweiter Versuch: Da die VPN-Verbindung den TCP-Port 1723 sowie das GRE Protokoll (Nr.47) nutzt habe ich zwei seperate Firewall-Regeln verfasst, die sämtlichen Traffic zum Port 1723 sowie alle Daten mit GRE-Protokoll über einen Routing-Tag einem festen DSL-Anschluss zuweist.
=> Leider hat auch das die Situation nicht verbessert.
Als letzer Versuch habe ich dann über eine Firewall Regel den gesamten Traffic der lokalen IP des Mitgliedes über einen festen DSL-Anschluss geleitet. (D.h. das Mitglied nutzt nun einen DSL-Anschluss und nicht den Loadbalancer).
=> Jetzt funktioniert es !!!
Leider ist der letzte (und einzige funktionierende) Lösungsansatz nicht meine favorisierte Lösung. D.h. ich würde gerne die Regel an die feste IP des Firmennetzes oder an irgendwelche Ports oder Protokolle binden.
Hat hier jemand eine Idee warum das nicht funktioniert???
Vielen Dank schonmal !!!
Gruß Hardy
Problem mit VPN-Verbindung und Loadbalancing
Moderator: Lancom-Systems Moderatoren
Hi Hardy,
da der User PPTP benutzt, brauchst du eigentlich gar keine besonderen Vorkehrungen, um das wechseln des Ports zu verhindern - es sei denn du hättest den TCP-Timeout der Maskierung/Firewall auf weniger als 60 Sekunden gesetzt.
Die Firewall erkennt PPTP und weist den GRE-Paketen den selben DSL-Port zu wie auch der (TCP-)Steuerverbindung zugewiesen wurde. Über die Steuerverbindung läuft i.A. nach 60 Sekunden ein "Keep-Alive"-Paket (Echo-Request/Echo-Reply). Wenn der TCP-Timeout der Firewall nun kleiner ist als diese 60 Sekunden, dann fliegt die PPTP-Session natürlich "raus" wenn keine Nutzsdaten übertragen werden. Ist er größer, dann hält das Keep-Alive die Session am Leben...
Gruß
Backslash
da der User PPTP benutzt, brauchst du eigentlich gar keine besonderen Vorkehrungen, um das wechseln des Ports zu verhindern - es sei denn du hättest den TCP-Timeout der Maskierung/Firewall auf weniger als 60 Sekunden gesetzt.
Die Firewall erkennt PPTP und weist den GRE-Paketen den selben DSL-Port zu wie auch der (TCP-)Steuerverbindung zugewiesen wurde. Über die Steuerverbindung läuft i.A. nach 60 Sekunden ein "Keep-Alive"-Paket (Echo-Request/Echo-Reply). Wenn der TCP-Timeout der Firewall nun kleiner ist als diese 60 Sekunden, dann fliegt die PPTP-Session natürlich "raus" wenn keine Nutzsdaten übertragen werden. Ist er größer, dann hält das Keep-Alive die Session am Leben...
Gruß
Backslash
Hallo backslash,
Oder kann es sein, daß die Steuerverbindung nicht alle 60 Sekunden ein "Keep-Alive"-Paket schickt? Wie kann ich das überprüfen?
Gruß Hardy
wo kann ich denn den TCP-Timeout in der Lancom Firewall einstellen?es sei denn du hättest den TCP-Timeout der Maskierung/Firewall auf weniger als 60 Sekunden gesetzt.
Oder kann es sein, daß die Steuerverbindung nicht alle 60 Sekunden ein "Keep-Alive"-Paket schickt? Wie kann ich das überprüfen?
Gruß Hardy
Hi Hardy
Währenddessen läßt du einen IP-Router-Trace mitlaufen, den du auf die feste IP des PPTP-Servers einschränkst
Nach den zwei Minuten soll er ein Ping durch den PPTP-Tunnel schicken. Dann müßtest du eigentlich alles sehen (mögliche Keep-Alives, GRE-Pakete und die DSL-Verbindung, auf die die Daten geschickt werden).
Das Problem dabei ist natürlich, daß durch den Trace zum einen die Load auf dem Router extrem hoch geht (insbesondere wenn die anderen Beteiligten am Bürgernetz munter Surfen) und es u.U. passieren kann, daß der Trace nicht vollständig ist, weil dem Router der Speicher ausgeht, denn die Filterung des Traces erfogt erst bei der Augabe, d.h. es wird erstmal jedes Paket mitgeschnitten...
Gruß
Backslash
unter IP-Router -> Maskierung -> TCP-Agingwo kann ich denn den TCP-Timeout in der Lancom Firewall einstellen?
Eigentlich schreibt der RFC 2637 in Abschnitt 3.1.4 vor, daß Keep-Alives gesendet werden sollten. Wenn sie gesendet werden, dann müssen sie nach spätestens 60 Sekunden gesendet werden. Mir ist bisher auch keine Implementation bekannt, die keine Keep-Alives sendet...Oder kann es sein, daß die Steuerverbindung nicht alle 60 Sekunden ein "Keep-Alive"-Paket schickt?
nun ja, du könntest den Kunden bitten eine PPTP-Verbindung aufzubauen und zwei Minuten *keine* Nutzdaten zu senden...Wie kann ich das überprüfen?
Währenddessen läßt du einen IP-Router-Trace mitlaufen, den du auf die feste IP des PPTP-Servers einschränkst
Nach den zwei Minuten soll er ein Ping durch den PPTP-Tunnel schicken. Dann müßtest du eigentlich alles sehen (mögliche Keep-Alives, GRE-Pakete und die DSL-Verbindung, auf die die Daten geschickt werden).
Das Problem dabei ist natürlich, daß durch den Trace zum einen die Load auf dem Router extrem hoch geht (insbesondere wenn die anderen Beteiligten am Bürgernetz munter Surfen) und es u.U. passieren kann, daß der Trace nicht vollständig ist, weil dem Router der Speicher ausgeht, denn die Filterung des Traces erfogt erst bei der Augabe, d.h. es wird erstmal jedes Paket mitgeschnitten...
Gruß
Backslash
-
stefanbunzel
- Beiträge: 1405
- Registriert: 03 Feb 2006, 13:30
- Wohnort: endlich VDSL-250
Hallo Hardy,
ich habe hier eine ähnliche Konfig. Eigentlich muss doch dein erster Versuch mit dem Binden der festen IP der Firma an einen der DSL-Anschlüsse auch funktionieren. Ich mache das hier auch so erfolgreich. Bei dieser Variante brauchst du dich dann wenigstens nicht um Protokolle usw. kümmern.
Stefan
ich habe hier eine ähnliche Konfig. Eigentlich muss doch dein erster Versuch mit dem Binden der festen IP der Firma an einen der DSL-Anschlüsse auch funktionieren. Ich mache das hier auch so erfolgreich. Bei dieser Variante brauchst du dich dann wenigstens nicht um Protokolle usw. kümmern.
Stefan
GS-2326, 1783VAW, R883VAW, 1781A, 831A, 1781EF+, L-452agn, L-32x, L-54(ag/dual), 1711(+), 1511, 821(+), 3850, 3050, IL-11/2, VP-100 ..., Optionen: CF, PS, WLC
LCS WLAN
LCS WLAN
Hi stefanbunzel.
das habe ich eigentlich auch gedacht. Trotz meinem Eintrag in der Routing-Tabelle (der jeglichen Verkehr zum Firmennetz mit der festen IP über eine DSL-Leitung führt) wechselt die IP. Das Wechseln der IP hat ein IT-Mitarbeiter dieser Firma am VPN-Server gesehen. Hier mein Eintrag in der Routing-Tabelle:
Wenn ich aber backslashs Aussage richtige verstehe, sollte es ja sogar ohne jegliche Routing/Firewall-Regel funktionieren...
...komisch, komisch, komisch...
Übrigens: MeinTCP-Timeout steht auf 300s
Gruß Hardy
das habe ich eigentlich auch gedacht. Trotz meinem Eintrag in der Routing-Tabelle (der jeglichen Verkehr zum Firmennetz mit der festen IP über eine DSL-Leitung führt) wechselt die IP. Das Wechseln der IP hat ein IT-Mitarbeiter dieser Firma am VPN-Server gesehen. Hier mein Eintrag in der Routing-Tabelle:
Code: Alles auswählen
IP-Address: 194.xxx.xxx.xxx
IP-Netmask: 255.255.255.255
Rtg-tag: 0
Peer-or-IP: DSL1
Distance: 0
Masquerade: No
Active: Yes ...komisch, komisch, komisch...
Übrigens: MeinTCP-Timeout steht auf 300s
Gruß Hardy
-
stefanbunzel
- Beiträge: 1405
- Registriert: 03 Feb 2006, 13:30
- Wohnort: endlich VDSL-250
Hallo Hardy,
da gibt es wohl ein anderes Problem...
In meiner Routing-Tabelle habe ich drei Default-Routen bei 2 DSL-Anschlüssen: 1 x für das Load-Balancing (Routing-Tag 0), 1 x für DSL-1 (Tag 1) und 1 x für DSL-2 (Tag 2).
Dann kommt eine Firewall-Regel für die VPN-Verbindung auf die Verbindungs-Ziel Station "feste IP" (194...) mit dem Routing-Tag 1 oder 2 für DSL-1 oder DSL-2, die ja nur die jeweiligen Pakete mit dem Tag markiert. Das wars.
Stefan
da gibt es wohl ein anderes Problem...
In meiner Routing-Tabelle habe ich drei Default-Routen bei 2 DSL-Anschlüssen: 1 x für das Load-Balancing (Routing-Tag 0), 1 x für DSL-1 (Tag 1) und 1 x für DSL-2 (Tag 2).
Dann kommt eine Firewall-Regel für die VPN-Verbindung auf die Verbindungs-Ziel Station "feste IP" (194...) mit dem Routing-Tag 1 oder 2 für DSL-1 oder DSL-2, die ja nur die jeweiligen Pakete mit dem Tag markiert. Das wars.
Stefan
GS-2326, 1783VAW, R883VAW, 1781A, 831A, 1781EF+, L-452agn, L-32x, L-54(ag/dual), 1711(+), 1511, 821(+), 3850, 3050, IL-11/2, VP-100 ..., Optionen: CF, PS, WLC
LCS WLAN
LCS WLAN
VPN
Schreibe den VPN so, dass der Verbindungsaufbau zur festen IP erfolgt. Am besten Du nimmst das Lanconfig Tool, Setup Assistenten. Dort zwei lokale Netze verbinden. Die Aussenstelle mit der dyn IP baut auf ( 9999 ) die mit der festen IP (0 ). Ab der Firmware 7.56 braucht man in der Regel kein Polling zu setzen, es kann zu Abrüchen führen. So sollte es funktionieren.
Hallo stefanbunzel,
genau so wie du es beschreibst war mein erster Versuch. Dann habe ich allerdings gedacht, daß ein Eintrag direkt in die Routing-Tabelle einfacher und besser wäre. Ich habe ebenfalls den Loadbalancer auf Routing-Tag 0 und die festen Leitungen auf 1, 2 und 3. Hier meine erfolglos getestete Firewall-Regel:
Gruß Hardy
genau so wie du es beschreibst war mein erster Versuch. Dann habe ich allerdings gedacht, daß ein Eintrag direkt in die Routing-Tabelle einfacher und besser wäre. Ich habe ebenfalls den Loadbalancer auf Routing-Tag 0 und die festen Leitungen auf 1, 2 und 3. Hier meine erfolglos getestete Firewall-Regel:
Code: Alles auswählen
Allgemein:
- Haken bei "Diese Regel ist für die Firewal aktiv"
- Haken bei "Diese Regel hält die Verbindungszustände nach"
Aktionen:
- Trigger 0kbit (Pro Verbindung)
QoS:
- nix
Stationen:
- Verbindungs-Quelle: "Alle Stationen in allen lokalen Netzen"
- Verbindungs-Ziel: "IP-Adresse 194.xxx.xxx.xxx"
Dienste:
- "Diese Regel gilt für alle Dienste/Protokolle"Hi Hardy,
in der Regel mußt du natürlich auch noch das Routing-Tag angeben, das verwendet werden soll... Der einfache Eintrag in der Routing-Tabelle sollte auch ausreichen (beachte dabei, daß du bei dem Eintrag die Maskierung einschalten mußt).
Aber wie gesagt: Eigentlich muß du da gar nichts machen - solange die PPTP-Verbindung oder (die DSL-Verbindung über die sie läuft) nicht getrennt wird. Natürlich wechselt nach einer Trennung ggf. die IP, weil ein anderer DSL-Port verwendet wird, aber das ist auch kein Problem - es sei denn die Gegenseiter erwartet die Verbindung von einer festen IP...
Der Loadbalancer als solches ist aber nicht der Grund für die Trennung der PPTP-Verbindung...
Gruß
Backslash
in der Regel mußt du natürlich auch noch das Routing-Tag angeben, das verwendet werden soll... Der einfache Eintrag in der Routing-Tabelle sollte auch ausreichen (beachte dabei, daß du bei dem Eintrag die Maskierung einschalten mußt).
Aber wie gesagt: Eigentlich muß du da gar nichts machen - solange die PPTP-Verbindung oder (die DSL-Verbindung über die sie läuft) nicht getrennt wird. Natürlich wechselt nach einer Trennung ggf. die IP, weil ein anderer DSL-Port verwendet wird, aber das ist auch kein Problem - es sei denn die Gegenseiter erwartet die Verbindung von einer festen IP...
Der Loadbalancer als solches ist aber nicht der Grund für die Trennung der PPTP-Verbindung...
Gruß
Backslash
-
stefanbunzel
- Beiträge: 1405
- Registriert: 03 Feb 2006, 13:30
- Wohnort: endlich VDSL-250
Hallo Hardy,
zur Firewallregel:
unter Allgemein musst du natürlich das gewünschte Routing-Tag eintragen. Aktionenen: (sofort) übertragen!
Rest ist so okay.
Stefan
zur Firewallregel:
unter Allgemein musst du natürlich das gewünschte Routing-Tag eintragen. Aktionenen: (sofort) übertragen!
Rest ist so okay.
Stefan
GS-2326, 1783VAW, R883VAW, 1781A, 831A, 1781EF+, L-452agn, L-32x, L-54(ag/dual), 1711(+), 1511, 821(+), 3850, 3050, IL-11/2, VP-100 ..., Optionen: CF, PS, WLC
LCS WLAN
LCS WLAN