Hallo!
Wir haben den Lancom 1821 mit freeswan 1.98 unter Linux zum Laufen bekommen (Netz zu Netz-Kopplung). Dabei besitzen beide Gegenstellen dynamische IP-Adressen die auch korrekt aktualisiert werden.
Leider klappt der Verbindungsaufbau nicht mehr, wenn sich die IP-Adresse des freeswan-Routers mal geändert hat. Nach dem Auslesen und dem erneuten Schreiben der Konfiguration des Lancoms funktioniert es (meist) wieder. Daher meine Fragen:
- fragt der Lancom nur einmal die IP-Adresse der VPN-Gegenstelle ab und puffert diese dann dauerhaft?
- gibt es eine Liste der möglichen Befehle die in der Eventstabelle verwendet werden können?
- gibt es eine Liste der möglichen Befehle die in der Crontabelle verwendet werden können?
- besteht die Möglichkeit gezielt eine IP-Adresse einer VPN-Verbindung zu erneuern? (Bei freeswan besteht die Möglichkeit dazu eine Verbindung inaktiv und anschließend wieder aktiv zu schalten. Dabei wird eine DNS-Anfrage nach der aktuellen IP gemacht.)
Danke und Grüße
Jan
Lancom 1821 und freeswan 1.98
Moderator: Lancom-Systems Moderatoren
Hi Jan,
das LANCOM merkt sich die Zuordnung zwischen Name und IP-Adresse solange, wie der DNS-Server es vorgibt. Meldet der DNS-Server (wie z.B. bei dyndns) eine Gültigkeit (TTL) von 60 Sekunden, dann wird die Anfrage alle 60 Sekunden wiederholt. Meldet er hingegen 15 Minuten, dann erfolgt der Update auch erst nach 15 Minuten. Schau mal im VPN-Status-Trace nach, welche Gültigkeit (TTL) vom DNS-Server gemeldet wird.
Gruß
Backsash
das LANCOM merkt sich die Zuordnung zwischen Name und IP-Adresse solange, wie der DNS-Server es vorgibt. Meldet der DNS-Server (wie z.B. bei dyndns) eine Gültigkeit (TTL) von 60 Sekunden, dann wird die Anfrage alle 60 Sekunden wiederholt. Meldet er hingegen 15 Minuten, dann erfolgt der Update auch erst nach 15 Minuten. Schau mal im VPN-Status-Trace nach, welche Gültigkeit (TTL) vom DNS-Server gemeldet wird.
Gruß
Backsash
Hallo Backslash!
Erstmal danke für Deine Antwort. Doch das trifft nicht ganz den Kern. Dazu hole ich mal weiter aus:
Im Lancom wird es (so wie auch bei freeswan ist) eine Tabelle geben in der wahrscheinlich IP-Adressen gespeichert sind, die mit einer VPN-Verbindung in Zusammenhang stehen. Das heißt, es gibt Routen (bei freeswan werden diese "eroutes" genannt) die bei bestimmten Absender-IP-Adressen dem ankommenden Paket eine besondere Behandlung zukommen lassen. In unserem Fall dem Main-Mode des IKE.
Bei freeswan werden diese eroutes beim Start des Daemons gesetzt. Das bedeutet, dass nur beim Start von freeswan einmalig der FQDN in eine IP-Adresse aufgelöst wird und eben diese als eroute im Netzwerkkernelstack eingerichtet wird. Ändert sich diese IP-Adresse (da ja dynamisch) so muß kurzzeitig die VPN-Connection heruntergenommen und anschließend wieder aktiviert werden. Diese Problem lösen wir auf freeswan-Seite mittels eines kleinen Tools (ipsec_monitor) der in zyklischen Abständen die IP-Adresse auf Änderungen überprüft.
Auf Lancom-Seite haben wir versucht dem Problem durch zyklische DNS-Abfrage Herr zu werden - ohne Erfolg.
Bei einem Aufbau-Versuch meldet der Lancom im VPN-Trace nur:
"VpnIpm: info; Phase-1 negotiation failed: no configuration found for incoming peer 84.x.x.x"
obwohl kurz zuvor eine Tracemeldung von der "external DNS resolution" mit der korrekt aufgelösten IP-Adresse aufgetaucht ist.
Folglich muß der Lancom eine falsche IP-Adresse der freeswan-Gegenstelle gespeichert haben, denn dem Lancom-System ist die richtige ja bekannt... Rufe ich nun "show vpn" auf, so zeigt mir der Lancom auch die alte (falsche) IP-Adresse als Remote Gateway in der VPN-Verbindung an.
Gibt es eine Lösung für dieses Problem?
Also z.B. mit
- zyklischen Befehlen via Cron
- Befehlen aus der Aktionstabelle?
- anderen Ideen
Danke und Grüße
Jan
Erstmal danke für Deine Antwort. Doch das trifft nicht ganz den Kern. Dazu hole ich mal weiter aus:
Im Lancom wird es (so wie auch bei freeswan ist) eine Tabelle geben in der wahrscheinlich IP-Adressen gespeichert sind, die mit einer VPN-Verbindung in Zusammenhang stehen. Das heißt, es gibt Routen (bei freeswan werden diese "eroutes" genannt) die bei bestimmten Absender-IP-Adressen dem ankommenden Paket eine besondere Behandlung zukommen lassen. In unserem Fall dem Main-Mode des IKE.
Bei freeswan werden diese eroutes beim Start des Daemons gesetzt. Das bedeutet, dass nur beim Start von freeswan einmalig der FQDN in eine IP-Adresse aufgelöst wird und eben diese als eroute im Netzwerkkernelstack eingerichtet wird. Ändert sich diese IP-Adresse (da ja dynamisch) so muß kurzzeitig die VPN-Connection heruntergenommen und anschließend wieder aktiviert werden. Diese Problem lösen wir auf freeswan-Seite mittels eines kleinen Tools (ipsec_monitor) der in zyklischen Abständen die IP-Adresse auf Änderungen überprüft.
Auf Lancom-Seite haben wir versucht dem Problem durch zyklische DNS-Abfrage Herr zu werden - ohne Erfolg.
Bei einem Aufbau-Versuch meldet der Lancom im VPN-Trace nur:
"VpnIpm: info; Phase-1 negotiation failed: no configuration found for incoming peer 84.x.x.x"
obwohl kurz zuvor eine Tracemeldung von der "external DNS resolution" mit der korrekt aufgelösten IP-Adresse aufgetaucht ist.
Folglich muß der Lancom eine falsche IP-Adresse der freeswan-Gegenstelle gespeichert haben, denn dem Lancom-System ist die richtige ja bekannt... Rufe ich nun "show vpn" auf, so zeigt mir der Lancom auch die alte (falsche) IP-Adresse als Remote Gateway in der VPN-Verbindung an.
Gibt es eine Lösung für dieses Problem?
Also z.B. mit
- zyklischen Befehlen via Cron
- Befehlen aus der Aktionstabelle?
- anderen Ideen
Danke und Grüße
Jan
Hi Jan
Am besten überwachst du den Tunnel mit Hilfe eines Eintrags in der Polling-Tabelle (im LANconfig unter Kommunikation -> Gegenstellen -> Polling-Tabelle). Dort kannst du 4 Adressen angeben, die angepingt werden sobald der Tunnel steht. Wenn innerhalb des Ping-Intervalls keine Antwort empfangen wurde und auch auf die Wiederholungen, die dann im Sekundentakt abgesetzt werden, keine Antwort kommt, wird der Tunnel abgebaut.
Gruß
Backslash
War das LANCOM zu der ggf. noch der Meinung es hätte einen stehenden Tunnel gehabt? In diesem Fall ignoriert das LANCOM die neue Adresse erstmal und zwar solange bis der Tunnel abgebaut wird. Erst danach wird die neue Adresse in die VPN-Konfiguration übernommen."VpnIpm: info; Phase-1 negotiation failed: no configuration found for incoming peer 84.x.x.x"
obwohl kurz zuvor eine Tracemeldung von der "external DNS resolution" mit der korrekt aufgelösten IP-Adresse aufgetaucht ist.
Am besten überwachst du den Tunnel mit Hilfe eines Eintrags in der Polling-Tabelle (im LANconfig unter Kommunikation -> Gegenstellen -> Polling-Tabelle). Dort kannst du 4 Adressen angeben, die angepingt werden sobald der Tunnel steht. Wenn innerhalb des Ping-Intervalls keine Antwort empfangen wurde und auch auf die Wiederholungen, die dann im Sekundentakt abgesetzt werden, keine Antwort kommt, wird der Tunnel abgebaut.
Gruß
Backslash
Hi Jan
Gruß
Backslash
In der Aktions und der Cron-Tabelle sind alle Befehle möglich, die auch unter telnet möglich sind.Trotzdem würde mich eine Liste mit möglichen Befehle für die Aktions- bzw. die Crontabelle interessieren.
ja, gib im Telnet "help" oder "?" ein und du bekommst die Liste...Gibt es eine solche Aufstellung?
Gruß
Backslash
-
langewiesche
- Beiträge: 1255
- Registriert: 27 Apr 2005, 11:28
- Wohnort: Gevelsberg / Sprockhoevel im Ruhrgebiet
- Kontaktdaten: