es gibt aber KEINEN kommerziellen VPN-Anbieter, der IKE v1 in seinen originären VPN-Protokollen anbietet
hide.me (eine Firma aus Malaysia, aber welcher dieser VPN-Services sitzt schon in Schweden, GB, F, USA, usw.) bietet sehr wohl einen solchen Service auch mit IKE v1 an, eine FRITZ!Box mit 06.30 kann auch einen Tunnel darüber aufbauen.
Habe ich nach unserer
letzten Diskussion zu diesem Thema extra getestet (es ist ein wenig tricky, die verwendeten Parameter aus den verstreuten cfg-Files für andere Clients zusammenzusuchen) ... von einem Beitrag dazu bin ich nur abgekommen, weil ich bei mir keine "aller Verkehr geht über diesen Tunnel"-Konfiguration ausführlich testen kann, ohne andere VPN-Verbindungen abzuschießen. Aber mit einer "accesslist" nur für den Google-DNS-Server unter 8.8.8.8 habe ich selektiv DNS-Abfragen über einen Tunnel bei denen (Einwahl war in NL) ausführen können. Weitere Tests habe ich nicht mehr geschafft, bevor meine Aufmerksamkeitsspanne "erschöpft" war. Wenn das jemand selbst weiter testen will, muß er die richtigen Daten per "accesslist" über diesen Tunnel schicken.
Es ist also nicht ganz trivial, aber es geht auch mit einer FRITZ!Box, wenn man die richtigen VPN-Einstellungen von Hand vornimmt. In erster Linie ist das mal der "main mode" des IKE anstelle des "aggressive mode" ... der verwendete "key" war - glaube ich mich zu erinnern - einfach "hide.io" (kann man aus der cfg-Datei des ShrewSoft-Clients für hide.me auslesen, ist nur B64-kodiert) und die eigenen Credentials dann als "xauth" übermitteln. Die bestehende Verbindung wird auch im GUI ordentlich angezeigt, das "dsl"-Interface der Box erhält zusätzlich die vom VPN-Service zugewiesene IP-Adresse.
Die VPN-Konfiguration für den Import sollte etwa so aussehen:
Code:
meta { encoding = "utf-8"; }
vpncfg {
connections {
enabled = yes;
conn_type = conntype_out;
name = "hide.me";
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 = 95.211.171.164; [COLOR="#FF0000"]<=== fixed ip address needed or avmike will "flap"[/COLOR]
remote_virtualip = 0.0.0.0;
remotehostname = "";
keepalive_ip = 8.8.8.8; [COLOR="#FF0000"]<=== google DNS as keepalive ip for automatic IKE[/COLOR]
mode = phase1_mode_idp; [COLOR="#FF0000"]<=== main mode[/COLOR]
phase1ss = "dh14/aes/sha"; [COLOR="#FF0000"]<=== alternative DH group required[/COLOR]
keytype = connkeytype_pre_shared;
key = "hide.io"; [COLOR="#FF0000"]<=== static key[/COLOR]
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = yes;
xauth {
valid = yes;
username = "[COLOR="#FF0000"]your_username[/COLOR]";
passwd = "[COLOR="#FF0000"]your_password[/COLOR]";
}
use_cfgmode = yes;
phase2remoteid {
ipnet {
ipaddr = 0.0.0.0;
mask = 0.0.0.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-none/pfs";
accesslist = "permit ip any 8.8.8.8 255.255.255.255", [COLOR="#FF0000"]<=== [B]only [/B]google DNS server to use over this tunnel - for my own (test) purposes only[/COLOR]
"permit ip any 10.0.0.0 255.0.0.0"; [COLOR="#FF0000"]<=== the provider uses these network internally, usually not needed[/COLOR]
}
}
Irgendwo hatte ich sogar einen Screenshot der aufgebauten Verbindung aus dem GUI, finde ich nicht mehr.
Eine zweite Klippe bei hide.me ist es noch, daß die eine Lastverteilung ihrer Kunden per DNS-RoundRobin verwenden und die DNS-Abfrage des Einwahlknotens wechselnde IP-Adressen liefert. Da das AVM-VPN darauf ausgelegt ist, den Wechsel eines Peers auch bei Verwendung dynamischer Adressen zu erkennen, erfolgt in regelmäßigen Abständen eine neue DNS-Abfrage. Liefert die jetzt ein anderes Gateway, baut der avmike die bestehende Verbindung ab und mit dem neuen Gateway wieder auf. Das vermeidet man, indem man anstelle von "remotehostname" einen "remoteip"-Eintrag mit einer "festen" IP-Adresse benutzt.
Wer es sich also zutraut, mit den "accesslist"-Einträgen entsprechend zu testen, der könnte mit diesem Ansatz auch mit einer FRITZ!Box als VPN-Client zum Erfolg kommen ... das ist als "Client" auch nichts wirklich anderes als ShrewSoft. Allerdings sollte man schon mit dem Packetdump der FRITZ!Box zurechtkommen und auch mit WireShark für die Auswertung eines solchen Mitschnitts. Aus der zeitlichen Korrelation von ESP-Paketen auf der "1. Internetverbindung" und dem Verkehr auf der "Routingsschnittstelle" läßt sich auch dann einiges ableiten, wenn man den eigentlichen Paketinhalt in den VPN-Paketen nicht mehr entziffern kann. Auch ein Telnet-Zugriff zur Box ist natürlich nicht zu verachten, wenn man sich nicht ständig die interessanten Daten aus einer kompletten Datei mit den "Support-Daten" herauspuzzlen will.
Das kann man natürlich auch nur dann machen, wenn man bei so einer "catch all"-VPN-Verbindung keine anderen parallel betreiben will. Nach dem, was ich bisher bei Tests gefunden habe, erfolgt da jedenfalls keine "Priorisierung" irgendwelcher Selektoren auf der Basis "most specialized first" (wie beim Routing) - ich würde das also (vorsichtshalber) nur mit einer Box versuchen, die ansonsten keine weiteren VPN-Verbindungen konfiguriert hat (und das meint tatsächlich konfiguriert und nicht nur "activated" oder "enabled") und auf die ich direkt lokalen Zugriff habe. Das kann ich hier bei mir im Moment nicht mehr leisten ... nur über den Umweg eines kaskadierten Routers und das entwertet (NAT-T vs. kein NAT-T) so eine Konfiguration für einen "Border-Router" umgehend, da man die FRITZ!Box m.W. nicht zur Verwendung von NAT-T "zwingen" kann (wie einen ShrewSoft-Client mit "force-rfc" für "NAT-T").
EDIT: Falls das nicht so richtig deutlich wurde ... der p1ss-Selektor "dh14/aes/sha" existiert erst ab 06.20, vorher kennt die FRITZ!Box aber ohnehin nur group 2, wenn ich mich richtig erinnere.
EDIT2: Die o.a. "accesslist" braucht natürlich auch keine "Sonderbehandlung" der UDP-Pakete für die Ports 500 und 4500 ... da es keinen "default"-Selektor "0.0.0.0" oder "any" gibt, landet dieser Verkehr ohnehin nicht im Tunnel. Das wäre bei einer "catch all"-Verbindung sicherlich anders ... obwohl ich da auch keine
definitive Aussage kenne, ob die gekapselten Pakete (ESP oder UDP/4500) überhaupt bei AVM erneut diese "Selektorenliste" durchlaufen oder nicht.
