aber der Provider hat auf meinen Wunsch NAT-Trasversal
Was soll das sein ? Irgendwann muß der Router/was-auch-immer des Providers ja Deine IP-Pakete mal auf eine "offizielle" IP-Adresse umschreiben, das ist dann NAT (outgoing). NAT (incoming) käme z.B. zum Einsatz, wenn Du eine Portfreigabe auf einer Fritz!Box einrichtest.
und die Ports 500 und 4500 auf meine IP 192.168.1.99 geleitet
Ok, das ist ein Anfang, wenn er es richtig gemacht hat. Du bräuchtest das UDP-Protokoll für beide Ports, TCP-Weiterleitungen sind nutzlos.
UDP(!) 500 ist ISAKMP/IKE, was aber in Deinem Falle auch ziemlich nutzlos ist. Damit das funktioniert, müßte das Provider-Gateway "IPSec-Passthrough" machen, d.h. alle Pakete mit ESP-Protokoll (Nummer 50) und UDP 500 für den Schlüsselaustausch ohne Änderungen (also auch ohne die externe Adresse durch Deine 192.168.99.ZZZ zu ersetzen) an Deine Box weiterleiten und dürfte die von Deiner Box gesendeten Pakete auf ihrem Weg in das Internet nicht modifizieren, was aber wegen des erwähnten NAT nicht möglich ist.
UDP 4500 ist IPSec/NAT-T, das wäre in Deinem Falle das Protokoll, das zum Einsatz kommen muß. Dabei werden die eigentlichen IPSec-Pakete noch einmal zusätzlich in UDP-Paketen gekapselt, mit denen dann ein "Passieren" eines NAT-Gateways - und das ist dann NAT-Traversal - erst möglich wird, da in den äußeren UDP-Paketen sowohl die Adresse als auch der Port durch das NAT-Gateway geändert werden dürfen.
sowie meine DynDns Daten eingetragen. (In meinem Dyn Account sehe ich die aktuelle externe IP, welche ich auch per PC unter "Showip.net" angezeigt bekomme.
Das ist zwar nett, aber wahrscheinlich relativ nutzlos. Ich glaube auch nicht, daß Du hier mit einer AVM-Standardkonfiguration mit DynDNS-Adressen weiterkommen wirst.
Das VPN mit den per AVM Programm erzeugten cfg funktioniert natürlich nicht, da die Box meldet dass ihre IP (192.168.1.99) keine öffentliche IP sei.
Wann und bei welcher Aktion meldet "die Box" das ?
Gibt es einen Weg die Box "auszutricksen"? Evtl. durch Anpassungen in der cfg ?
Vermutlich.
So weit, so kryptisch ... aber frisch ans Werk.
Werkzeug/Material bereitlegen:
1. Editor, der sich mit den unterschiedlichen Zeilenenden von DOS und Unix auskennt, z.B. NotePad++
2. Zwei relativ leere VPN-Konfigurationsdateien.
Code:
vpncfg {
connections {
enabled = yes;
editable = no;
conn_type = conntype_lan;
name = "Alice_to_Bob";
boxuser_id = 0;
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = no;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 0.0.0.0;
remote_virtualip = 0.0.0.0;
remotehostname = "dyndns_name_der_box_von_bob";
keepalive_ip = lan_ip_der_box_von_bob;
localid {
fqdn = "der_name_hier_ist_eigentlich_egal_er_muß_nur_gespiegelt_sein_zwischen_alice_und_bob";
}
remoteid {
fqdn = "bob_dnu_ecila_nehcsiwz_nies_tlegeipseg_run_ßum_re_lage_hciltnegie_tsi_reih_eman_red";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "hier_kommt_der_preshared_key_hin,am_besten_etwas_kompliziertes_wie_1234567890";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.XXX.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.YYY.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 192.168.YYY.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}
Bob ist z.B. die Box im Büro und Alice ist jetzt die Box mit der externen IP-Adresse 192.168.99.irgendwas hinter dem Provider-Router. Für sie paßt die o.a. Datei schon, wenn Du folgende Zeilen noch anpaßt:
1. DynDNS-Name von Bob
2. Keepalive-IP von Bob => kann auch wegbleiben, dann macht Alice die VPN-Verbindung nur auf, wenn Daten zu übertragen sind - das verzögert dann die ersten Pakete etwas, wenn Du die Adresse wegläßt, sollte die komplette Zeile raus ... ansonsten gehört da die lokale IP-Adresse der Fritz!Box bei Bob hinein
3. FQDNs auf eine sinnvolle Länge kürzen => Du kannst auch die DynDNS-Namen der jeweiligen Seite nehmen, aber es kommt nur auf korrekte Übereinstimmung und Kreuzung zwischen local und remote an
4. einen sinnvollen Preshared Key => ich nehme immer 64 Zeichen Zufall, längere Schlüssel habe ich noch nicht getestet
5. In phase2localid->ipnet->ipaddr das XXX durch die korrekte LAN-Adresse im lokalen Netz von Alice ersetzen
6. In phase2remoteid ->ipnet->ipaddr das YYY durch die korrekte LAN-Adresse im entfernten Netz von Bob ersetzen
7. in accesslist noch das YYY auf Bob anpassen
Damit ist die VPN-Konfiguration für Alice eigentlich fertig. Noch ein Hinweis: Nach meinen Erfahrungen sind neuere Versionen von firmwarecfg (das wird von der Box zum Einlesen der VPN-Konfiguration benutzt) etwas zickig, wenn in einer Zeile hinter dem abschließenden Semikolon oder der geschweiften Klammer noch irgendwelche Leerzeichen oder Tabulatorzeichen stehen. Notepad++ hat einen Modus, in dem Du Dir diese "Sonderzeichen" auch anzeigen lassen kannst.
Aus der soeben erstellten Datei für Alice machen wir jetzt die für Bob. Dazu entfernen wir die Zeilen "remotehostname" und "keepalive_ip" komplett, vertauschen die fqdn-Zeilen für phase1 und die ipaddr-Zeilen für phase2 zwischen local und remote und ändern accesslist nun so, daß dort die IP-Adresse des Netzes von Alice steht.
Dann importieren wir zuerst die Konfiguration für Bob in die Fritz!Box von Bob und anschließend die von Alice in die andere Box. Da Bob keine Ahnung hat, wo sich Alice befinden könnte (er hat keine remotehostname-Zeile in seiner Konfiguration), kann er also die VPN-Verbindung nicht starten (das würde wahrscheinlich ohnehin nicht klappen). Bob wartet also ganz geduldig, bis Alice sich meldet.
Sowie jetzt irgendwann bei Alice ein Paket an eine Adresse im Netz von Bob auftaucht, hält Alice dieses Paket erst einmal fest und baut im Hintergrund die benötigte VPN-Verbindung auf. Wenn die Topologie so aussieht, wie ich sie mir nach Deinem Text vorstelle, kommt bei Bob ein Paket mit der Absenderadresse des Provider-Gateways von Alice und dem Zielport UDP 4500 an. Da damit auf der Seite von Alice ein "Tunnel" durch das NAT aktiviert wurde (schließlich muß die Antwort Alice ja irgendwie erreichen können), kann Bob jetzt an die Absenderadresse des bei ihm eingegangenen Pakets antworten und kennt nun die externe Adresse von Alice und den Port, der von der Internetadresse des Provider-Gateways zum Port 4500 von Alice führt. Die beiden sprechen sich jetzt erst einmal gründlich aus, stellen dabei fest, ob die andere Seite auch wirklich die ist, die sie vorgibt zu sein (dafür der PSK als "gemeinsames Geheimnis") und machen für die nahe Zukunft eine Geheimwort aus, das nur sie beide kennen. Anschließend schickt Alice noch das bisher zurückgehaltene Paket an Bob und damit ist es dann erst einmal gut. Um sicher zu gehen, daß die Gegenseite noch da und auch sie selbst ist (die könnte ja auch plötzliche eine andere dynamische Adresse haben und dann ist es auf einmal nicht mehr Alice, sondern ihre Großmutter mit den großen Ohren, mit der Bob redet) und um den Tunnel durch das NAT des Providers offen zu halten, unterhalten die beiden sich in relativ kurzen Abständen. So stellen Sie fest, ob sie noch da sind und halten die VPN-Verbindung am Leben (keepalive). Die Initiative dazu geht wieder von Alice aus.
Blöd ist jetzt nur, daß AVM meines Wissens den keepalive-Parameter erst nachträglich implementiert hat und ich nicht sagen kann, ob er in Deiner (doch ziemlich alten) 7170 schon benutzbar ist. Auch dafür gäbe es eine Lösung, die spare ich mir aber, bis sie gebraucht werden sollte.
Wenn es nicht klappen sollte, brauchen wir folgende Dateien zur Fehlersuche:
1. die beiden Konfigurationsdateien (PSK maskieren nicht vergessen, den Rest möglichst lassen -> manchmal reicht schon ein kleiner Tippfehler, der beim Verschleiern von Daten mit verschwindet)
2. die Dateien /var/tmp/ike.log (und wenn vorhanden /var/tmp/ike.old) von beiden Boxen, über Telnet oder Support-Daten auszulesen
3. die IP-Adressen der Interfaces und die Routing-Table von beiden Boxen, wieder per Telnet oder über die Support-Daten zu ermitteln
4. am besten noch die Ausgabe von "showdsldstat" auf beiden Boxen (ist auch in den Support-Daten enthalten)
5. die Dateien /var/vpnroutes von beiden Boxen
Das dann bitte nicht einzeln ins Forum setzen, sondern die Anhänge am besten in eine einzige ZIP-Datei packen.