DynDNS-VPNs... ich verzweifel langsam
Verfasst: Fr 28.03.2008, 23:15
Hallo zusammen,
ich habe "mal wieder" ein Problem, dass ich in dieser Art schon
einmal geschildert, aber keine echte Loesung bekommen habe.
Damals konnte ich mir an einem Standort mit einer Fest-IP-Option
helfen, aber nun wird es ernst. Hier mal die Aufgabenstellung und Eckdaten:
Standort A:
Appliance - RC100
Anbindung: ADSL ohne feste IP (und ohne Option diese zu bekommen!)
LAN-Segment: 192.168.1.0 / 24
Standort B:
Appliance - Piranja
Anbindung: ADSL ohne feste IP (und ohne Option diese zu bekommen!)
LAN-Segment: 192.168.99.0 / 24
In ganz normaler Art und Weise wurden beide Systeme ans Internet
"geklemmt" und fuer beide ein DynDNS-Eintrag generiert.
Roadwarrior koennen sauber auf das/die Systeme
per PPTP und L2TP zugreifen...alles kein Thema.
Die Standort-Verbindung ist ebenfalls im Standard-Regelwerk erstellt.
Internet -> FW-External -> IPSEC/L2TP -> ACCEPT
LAN-Standort-A -> LAN-Standort-B -> ACCEPT
LAN-Standort-B -> LAN-Standort-A -> ACCEPT
Jeweils an den Standorten ist das Lan der anderen Seite in der richtigen Zone...alles wie es sein sollte.
Da ja von PSKs abgeraten wird (was ich mittlerweile verstehe - Dazu spaeter mehr), habe ich mich
fuer den Weg der Zertifikate entschieden.
1. Eine CA erstellt (in Standort A).
2. Ein "Server-Zertifikat" erstellt (in Standort A).
3. Ein "Client-zertifikat" erstellt (in Standort A).
So nun die CA und das Client-Zertifikat auf die Appliance am Standort B importiert.
VPN-Tunnel eingerichtet mit den jeweiligen Certs/Subjects und den Tunnel angetreten.
Das Ergebnis war wie erhofft, blendend...IPSec-SA established etc.....ein blitzsauberes VPN halt.
Nun der Eselsfuss des ganzen und warum ich mich von der PSK-Variante entfernen moechte.
Alles laeuft genau so lange, bis entweder der Provider, oder die SP durch
eine Zwangstrennung auf einer neuen IP arbeitet.
Bei der PSK-Variante, wie von Achim (danke noch einmal fuer das kleine HowTo)
beschrieben, haengt alles vom richtigen Timing der Zwangstrennung ab.
Es gibt nur einen Tunnel-Initiator und einen Responder.
Als Beispiel:
Um 3 Uhr Nachts macht der Responder seinen Reconnect, somit ist der Tunnel solange "Out Of Order", bis der
IPSec-Dienst auf der Initiator-Seite neu startet (Eben bei seinem Reconnect z.B. um 4 Uhr).
Geht nun einmal was am Tag auf der Responder-Seite "schief", war es das auch mit dem Tunnel, bis auf der
initiator-Seite der Tunnel neu angestossen wird.
Das habe ich nun in allen moeglichen Variationen durchgespielt, und kann nur die Ursache an der VPN-Konfiguration
finden, weil zwar ein DNS-Name akzeptiert, aber sofort auf die IP aufgeloest wird (siehe DropDown) und
entsprechend bis zum Neustart des IPSec-Daemons da "haengen bleibt".
Soviel zu diesem Thema...wenn ich falsch liege, oder jemand andere Erfahrungen hat, bitte ich um Feedback.
Nun also zum Loesungsansatz mit dem Certs:
Naiv wie ich bin, hatte ich die Hoffnung, das die Aushandlung in diesem Fall an
der "IP" vorbeigeht (jaja Main-Mode!!! - IP ist wichtig)...aber man darf ja noch hoffen....
Ausser das der Aufwand etwas groesser ist, muss man sagen, dass der Sicherheitsfaktor natuerlich um
etliches hoeher ist, als bei der PSK-Variante. Leider hinkt aber hier das VPN an der gleichen Stelle.
Beide Seiten stelle ich nun auf einen automatischen Aufbau des Tunnels, aber was passiert nun, wenn eine
der beiden Seiten einen Reconnect durchfuehrt (durchfuehren muss)? - DNS bereits auf IP aufgeloest = Pech gehabt
Auch dieses Szenario habe ich in diversen Varianten durchgespielt. Tunnel steht wie eine 1.
Schnell mal das Modem abschalten und ein "Problem simulieren".
SP kommt wieder, DynDNS-Client macht seine Aktualisierung, alles super.
Beim initialisieren des Tunnels, wird der Aufbau von der Gegenseite solange geblockt bis der IPSec-Dienst
dort die neuen IP-Daten durch einen Neustart gefressen hat (Antwort= INVALID ID INFO).
Tja.....was nun....ich habe keine Ahnung mehr, wo ich noch was drehen soll, oder sehe
den Wald vor lauter Baeumen nicht....bin fuer jedes konstruktive Feedback dankbar...
Gruss
M.Goeres
ich habe "mal wieder" ein Problem, dass ich in dieser Art schon
einmal geschildert, aber keine echte Loesung bekommen habe.
Damals konnte ich mir an einem Standort mit einer Fest-IP-Option
helfen, aber nun wird es ernst. Hier mal die Aufgabenstellung und Eckdaten:
Standort A:
Appliance - RC100
Anbindung: ADSL ohne feste IP (und ohne Option diese zu bekommen!)
LAN-Segment: 192.168.1.0 / 24
Standort B:
Appliance - Piranja
Anbindung: ADSL ohne feste IP (und ohne Option diese zu bekommen!)
LAN-Segment: 192.168.99.0 / 24
In ganz normaler Art und Weise wurden beide Systeme ans Internet
"geklemmt" und fuer beide ein DynDNS-Eintrag generiert.
Roadwarrior koennen sauber auf das/die Systeme
per PPTP und L2TP zugreifen...alles kein Thema.
Die Standort-Verbindung ist ebenfalls im Standard-Regelwerk erstellt.
Internet -> FW-External -> IPSEC/L2TP -> ACCEPT
LAN-Standort-A -> LAN-Standort-B -> ACCEPT
LAN-Standort-B -> LAN-Standort-A -> ACCEPT
Jeweils an den Standorten ist das Lan der anderen Seite in der richtigen Zone...alles wie es sein sollte.
Da ja von PSKs abgeraten wird (was ich mittlerweile verstehe - Dazu spaeter mehr), habe ich mich
fuer den Weg der Zertifikate entschieden.
1. Eine CA erstellt (in Standort A).
2. Ein "Server-Zertifikat" erstellt (in Standort A).
3. Ein "Client-zertifikat" erstellt (in Standort A).
So nun die CA und das Client-Zertifikat auf die Appliance am Standort B importiert.
VPN-Tunnel eingerichtet mit den jeweiligen Certs/Subjects und den Tunnel angetreten.
Das Ergebnis war wie erhofft, blendend...IPSec-SA established etc.....ein blitzsauberes VPN halt.
Nun der Eselsfuss des ganzen und warum ich mich von der PSK-Variante entfernen moechte.
Alles laeuft genau so lange, bis entweder der Provider, oder die SP durch
eine Zwangstrennung auf einer neuen IP arbeitet.
Bei der PSK-Variante, wie von Achim (danke noch einmal fuer das kleine HowTo)
beschrieben, haengt alles vom richtigen Timing der Zwangstrennung ab.
Es gibt nur einen Tunnel-Initiator und einen Responder.
Als Beispiel:
Um 3 Uhr Nachts macht der Responder seinen Reconnect, somit ist der Tunnel solange "Out Of Order", bis der
IPSec-Dienst auf der Initiator-Seite neu startet (Eben bei seinem Reconnect z.B. um 4 Uhr).
Geht nun einmal was am Tag auf der Responder-Seite "schief", war es das auch mit dem Tunnel, bis auf der
initiator-Seite der Tunnel neu angestossen wird.
Das habe ich nun in allen moeglichen Variationen durchgespielt, und kann nur die Ursache an der VPN-Konfiguration
finden, weil zwar ein DNS-Name akzeptiert, aber sofort auf die IP aufgeloest wird (siehe DropDown) und
entsprechend bis zum Neustart des IPSec-Daemons da "haengen bleibt".
Soviel zu diesem Thema...wenn ich falsch liege, oder jemand andere Erfahrungen hat, bitte ich um Feedback.
Nun also zum Loesungsansatz mit dem Certs:
Naiv wie ich bin, hatte ich die Hoffnung, das die Aushandlung in diesem Fall an
der "IP" vorbeigeht (jaja Main-Mode!!! - IP ist wichtig)...aber man darf ja noch hoffen....
Ausser das der Aufwand etwas groesser ist, muss man sagen, dass der Sicherheitsfaktor natuerlich um
etliches hoeher ist, als bei der PSK-Variante. Leider hinkt aber hier das VPN an der gleichen Stelle.
Beide Seiten stelle ich nun auf einen automatischen Aufbau des Tunnels, aber was passiert nun, wenn eine
der beiden Seiten einen Reconnect durchfuehrt (durchfuehren muss)? - DNS bereits auf IP aufgeloest = Pech gehabt
Auch dieses Szenario habe ich in diversen Varianten durchgespielt. Tunnel steht wie eine 1.
Schnell mal das Modem abschalten und ein "Problem simulieren".
SP kommt wieder, DynDNS-Client macht seine Aktualisierung, alles super.
Beim initialisieren des Tunnels, wird der Aufbau von der Gegenseite solange geblockt bis der IPSec-Dienst
dort die neuen IP-Daten durch einen Neustart gefressen hat (Antwort= INVALID ID INFO).
Tja.....was nun....ich habe keine Ahnung mehr, wo ich noch was drehen soll, oder sehe
den Wald vor lauter Baeumen nicht....bin fuer jedes konstruktive Feedback dankbar...
Gruss
M.Goeres