LAN-LAN Tunnel durch 3. Router druchrouten

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
marsbewohner
Beiträge: 532
Registriert: 27 Mär 2007, 13:17

LAN-LAN Tunnel durch 3. Router druchrouten

Beitrag von marsbewohner »

Hallo,
da ich über die Suche nichts vergleichbares zum Thema gefunden habe, frage ich direkt. ;)

Folgendes Szenario:

Standort A:
----------------
IP Netz 192.168.0.*
1x Router LC 1611+ für Internetzugang über SDSL eingerichtet (feste IP)
1x Router LC 8011 VPN, aktuell hinter dem 8011 konfiguriert.

Standort B:
----------------
IP Netz 192.168.1.*
1x Router LC 1722 VoiP (Dyn IP)


Im Moment greifen von Standort B verschiedene Einzelclients (Ad. VPN Client)
auf Standort A zu, um dort auf dem Terminal zu arbeiten.

Zwischen dem LC 8011VPN und dem LC 1722 VoiP habe ich nun einen Tunnel mit dem
Assistenten eingerichtet, mit dem Setting, das der 1722 VoiP ein ICMP Paket an die feste IP vom
1611 schickt, um die Leitung zu eröffnen.

Das Problem ist im Moment, das sich allerdings 8011 und 1722 nicht finden,
weil der 1611 dazwischen die Anfrage des 1722 nicht weiterleitet o.Ä. .

Meine Frage wäre nun , ist es möglich die Anfrage vom 1722 durch den 1611 durchzurouten,
damit die Anfrage am 8011 ankommt und diese beiden einen Tunnel aufbauen können?

Man könnte natürlich auch den 1611 ganz aus der Konfig heraus nehmen,
da darüber allerdings einige VPN Clients laufen kann ich den nicht einfach abschalten
und muss ihn erstmal noch im Betrieb lassen, was mir auch am liebsten wäre für die Zukunft,
um den 8011 VPN ganz für den Tunnel freizuhalten.

Einzige Alternative die ich im Moment noch sehe, wäre eine DynDNS Adresse für den 1722,
und die Session würde dann durch den 8011 eröffnet, allerdings wäre es mir ohne DynDNS lieber.

Ich freue mich auf konstruktive Hilfe! :)

Grüße,
backslash
Moderator
Moderator
Beiträge: 7129
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi marsbewohner
Meine Frage wäre nun , ist es möglich die Anfrage vom 1722 durch den 1611 durchzurouten, damit die Anfrage am 8011 ankommt und diese beiden einen Tunnel aufbauen können?
ja, einfach unter IP-Router -> Maskierung -> Port-Forwarding-Tabelle die Ports 500 und 4500 auf den 8011 weiterleiten...

wenn du dynamic VPN benuzten willst, dann mußt

a) im 1722 dynamic VPN über UDP einschalten und
b) im 1611+ zusätzlich noch den Port 87 an den 8011 weiterleiten


Gruß
Backslash
marsbewohner
Beiträge: 532
Registriert: 27 Mär 2007, 13:17

Beitrag von marsbewohner »

Hi backslash,
backslash hat geschrieben:ja, einfach unter IP-Router -> Maskierung -> Port-Forwarding-Tabelle die Ports 500 und 4500 auf den 8011 weiterleiten...

a) im 1722 dynamic VPN über UDP einschalten und
b) im 1611+ zusätzlich noch den Port 87 an den 8011 weiterleiten
Danke, das klingt ja bestens! :)

Die Adv. VPn Clients welche sich im Moment am 1611+ anmelden sind davon
dann aber nicht betroffen, das die ann auf den 8011 geleitet werden und dann ins leere gehen?

gruß,
marsbewohner
backslash
Moderator
Moderator
Beiträge: 7129
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi marsbewohner
Die Adv. VPn Clients welche sich im Moment am 1611+ anmelden sind davon dann aber nicht betroffen, das die ann auf den 8011 geleitet werden und dann ins leere gehen?
Leider doch, da der 1611+ beim ersten eingehenden IKE-Paket nicht feststellen kann, ob er selbst gemeint ist, oder ob es weitergeleitet werden soll. Wenn beides erhalten beleiben soll, kommst du nicht umhin, den Tunnel immer vom 8011 aus aufzubauen, dann kann der 1611+ die IKE-Pakete auch auseinander halten. Dazu braucht der 1722 zwar eine dyndns-Adresse, dafür du kannst dir die ganze Portforwarderei schenken...


Gruß
Backslash
marsbewohner
Beiträge: 532
Registriert: 27 Mär 2007, 13:17

Beitrag von marsbewohner »

Hi backslash,
danke für die Info, das wird heute Abend gleich in die Tat umgesetzt! :)

Grüße
marsbewohner
marsbewohner
Beiträge: 532
Registriert: 27 Mär 2007, 13:17

Beitrag von marsbewohner »

Hallo nochmal,

das ganze funktioniert schon ganz gut, allerdings noch nicht ganz wie gewünscht. ;)

Ich hatte vergessen zu erwähnen das der 8011 als für Load-Balacing noch 2 normale DSL Anschlüsse
angeschlossen hat (direkt), und im Moment macht er den Aufbau darüber, statt über den SDSL Port welcher vom 1611+ kommt.

Dann werde ich wohl doch nicht umhin kommen, alle VPN Accounts vom 1611+ in den 8011 umzuziehen,
das SDSL dem 8011 direkt zuweisen und dann die ganze Kommunikation auf den zu legen, oder?

Danke & Gruß
marsbewohner
marsbewohner
Beiträge: 532
Registriert: 27 Mär 2007, 13:17

Beitrag von marsbewohner »

Noch ein kleines Edit:
Über die normalen DSL Anschlüsse (6Mbit) hier habe ich ca. alle 1 min
einen Verbindungsverlust, welcher dann zwar wiederhergestellt wird,
aber gibts eventuelle Präventivsettings, um diese Abbrüche zu verhinden?
backslash
Moderator
Moderator
Beiträge: 7129
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi marsbewohner
Dann werde ich wohl doch nicht umhin kommen, alle VPN Accounts vom 1611+ in den 8011 umzuziehen, das SDSL dem 8011 direkt zuweisen und dann die ganze Kommunikation auf den zu legen, oder?
Das hätte zumindest den Vorteil, daß du sowohl den SDSL- als auch die DSL-Anschlüsse im Load-Balancing nutzen kannst und du auch keine Probleme mit Portforwardings etc. bekommst. Notwendig ist das aber nicht...

Über die normalen DSL Anschlüsse (6Mbit) hier habe ich ca. alle 1 min einen Verbindungsverlust, welcher dann zwar wiederhergestellt wird,
aber gibts eventuelle Präventivsettings, um diese Abbrüche zu verhinden?
Hast du im 8011 eine Hateltezeit von 60 Sekunden gesetzt? Oder hast du ein ICMP-Polling eingetragen und versuchst einen Rechner anzupingen, der nicht antwortet?

Wenn nein, dann baut offenbar das (externe) Modem die Verbindung ab - Sitchwort: Synchronisationsverlust. Hier hilft dann nur noch der Telekom-Techniker...

Gruß
Backslash
marsbewohner
Beiträge: 532
Registriert: 27 Mär 2007, 13:17

Beitrag von marsbewohner »

Hi backslash,

also, ich habe jetzt mal alles auf den 8011 geschaltet, und das geht auch gut.
Tunnel klappt, nur ca. alle 60 Sec. wird die Protokollverhandlung neu gestartet.
(also Internet bleibt erhalten, nur der Tunnel wird erneuert.)

Line Polling hatte ich erst auf beiden Seiten auf "SA-Aufbau Gemeinsam: Ja" ,
dann mal ganz ohne (geht gar nicht) und jetzt nur beim 8011 auf "SA-Aufbau gemeinsam: nur bei Keep-Alive".

In beiden Routern (1722/8011) ist die Verbindungszeit auf 999.9 gestellt
und "Kein Dynamischs VPN" aktiviert, da der eine ja eine feste IP under der andere DynDNS hat.

IKE-Exchange ist "Main-Mode" und "IKE-CFG" ist aus.

:?: :?:

Danke & gruß,
marsbewohner
backslash
Moderator
Moderator
Beiträge: 7129
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi marsbewohner
also, ich habe jetzt mal alles auf den 8011 geschaltet, und das geht auch gut.
Tunnel klappt, nur ca. alle 60 Sec. wird die Protokollverhandlung neu gestartet.
(also Internet bleibt erhalten, nur der Tunnel wird erneuert.)
mach mal einen vpn-status Trace (per Telnat auf das 8011 und dann trace # vpn-status eingeben).
Line Polling hatte ich erst auf beiden Seiten auf "SA-Aufbau Gemeinsam: Ja" ,
dann mal ganz ohne (geht gar nicht) und jetzt nur beim 8011 auf "SA-Aufbau gemeinsam: nur bei Keep-Alive".
Das hat zwar nicht mit Line-Polling zu tun, ist aber korrekt.

Bei der Einstellung geht es darum, ob die SAs automatisch oder bei nur Bedarf aufgebaut werden. Für eine Keep-Alive Verbindung mußt du entweder den gemeinsamen SA-Aufbau aktivieren oder ein ICMP-Polling einrichten (das Polling liecfert dann das Paket um die SAs aufbauen zu können...)

Gruß
Backslash
marsbewohner
Beiträge: 532
Registriert: 27 Mär 2007, 13:17

Beitrag von marsbewohner »

Hi Backslash,

trace kommt heute Nachmittag, ist immer ein bisschen kritisch mit dem Umstecken hier,
weil dann alles offline geht ;)

Was ich aber heute mal ausgetestet habe, richte ich den Tunnel direkt zwischen dem 1611+ und dem 1722 VoiP ein,
steht er wie eine 1, keine Abbrüche etc, einzig Pakete bekomme ich noch keine durch, aber
da habe ich wahrscheinlich nur ein kleines Setting übersehen.
Insofern habe ich die Vermutung, dass das Load Balancing auf dem 8011 VPN der Auslöser ist.

EDIT:

Also, das scheint der Vorführeffekt zu sein, auf einmal gehts. :shock:
Habe jetzt mal 20 Minuten eine stabile verbindung gehabt, konnte
Daten hin und her senden
und habe nebenher noch 3 Pakete mit fast 1Gb aus dem netz gezogen, um die Leitung mal zu kitzeln.
Allerdings war auch jetzt hier nix mehr los, mal sehen wie es am Montag sich macht.

Kurzer Trace Auszug, da gibts noch ein paar unverständliche Sachen für mich drin:
[VPN-Status] 1900/01/01 21:27:33,540
IKE info: Phase-1 failed for peer XXXXXXXXXXXXXX: remote side has AGGRESSIVE mod e, local side has MAIN mode
IKE log: 212733 Default exchange_setup_p1: expected exchange type MAIN got AGGRESSIVE


[VPN-Status] 1900/01/01 21:27:37,990
VPN: poll timeout for XXXXXXXXXXXXXX (XXXXXXXXXXXXXX)
remote site answered during intervall send poll frame to XXXXXXXXXXXXXX

[VPN-Status] 1900/01/01 21:27:38,000
VPN: Poll reply from XXXXXXXXXXXXXX (XXXXXXXXXXXXXX)

[VPN-Status] 1900/01/01 21:27:40,530
IKE log: 212740 Default message_recv: invalid message id


[VPN-Status] 1900/01/01 21:27:40,530
IKE log: 212740 Default dropped message from XXXXXXXXXXXXXX port 500 due to noti fication type INVALID_MESSAGE_ID


[VPN-Status] 1900/01/01 21:27:40,530
IKE info: dropped message from peer unknown XXXXXXXXXXXXXX port 500 due to notification type INVALID_MESSAGE_ID


[VPN-Status] 1900/01/01 21:27:46,290
IKE info: Phase-1 failed for peer XXXXXXXXXXXXXX: remote side has AGGRESSIVE mode, local side has MAIN mode
IKE log: 212746 Default exchange_setup_p1: expected exchange type MAIN got AGGRESSIVE


[VPN-Status] 1900/01/01 21:27:49,330
IKE info: The remote server XXXXXXXXXXXXXX:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server XXXXXXXXXXXXXX:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server XXXXXXXXXXXXXX:500 peer def-aggr-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server XXXXXXXXXXXXXX:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server XXXXXXXXXXXXXX:500 peer def-aggr-peer id <no_id> negotiated rfc-3706-dead-peer-detection
IKE info: The remote server XXXXXXXXXXXXXX:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc
IKE info: The remote server XXXXXXXXXXXXXX:500 peer def-aggr-peer id <no_id> supports NAT-T in mode rfc


[VPN-Status] 1900/01/01 21:27:49,340
IKE info: phase-1 proposal failed: remote No 1 hash algorithm = SHA <-> local No 1 hash algorithm = MD5
IKE info: Phase-1 remote proposal 1 for peer def-aggr-peer matched with local proposal 2


[VPN-Status] 1900/01/01 21:27:49,340
IKE log: 212749 Default dropped message from XXXXXXXXXXXXXX port -3862 due to notification type INVALID_ID_INFORMATION


[VPN-Status] 1900/01/01 21:27:49,340
IKE info: dropped message from peer unknown XXXXXXXXXXXXXX port -3862 due to notification type INVALID_ID_INFORMATION
(Das mit den IPs/Hostnamen nicht persönlich nehmen, aber man weiß ja nie wer mitliest. ;) )

Und zwar einmal mit dem IKE-Mode, beide sind auf Mainmode geschaltet, aber das Tracert meldet unterschiedliche Modi?


Gruß,
marsbewohner
marsbewohner
Beiträge: 532
Registriert: 27 Mär 2007, 13:17

Beitrag von marsbewohner »

So, kurzes Finish noch,
das ganze läuft nun, fragt mich nicht wieso, aber es steht und
geht auch recht Stabil, mal sehen was die nächsten 4 Wochen bringen. ;)

Aber schonmal vielen Dank für die kompetente Hilfe!! :)

Grüße,
marsbewohner
Antworten