Die Möglichkeit, die FRITZ!Box als "Client" einzusetzen (das ist alles etwas schwammig in diesem Zusammenhang, was da nun Client und Server ist, das ist bei einem (Multi-User-)Server für OpenVPN vielleicht eindeutiger), steht doch in #5 ... oder meinst Du, bei einer Verbindung zu einem Firmen-Netzwerk (diese Option gibt es sicherlich auch in Deinem GUI) ist die FRITZ!Box dann der Server und der "Einwahlknoten" einer Firma der "Client"?
Es gibt bei IPSec vielleicht noch Unterschiede, ob so eine Verbindung mit XAuth (erweiterte Authentifizierung, die neben einem gemeinsamen "shared secret" auch noch individuelle Credentials verwendet) arbeitet in der Phase der Initialisierung oder ohne, aber prinzipiell ist das genau der Modus, wo die FRITZ!Box sich ihrerseits mit einem anderen Netzwerk verbindet. Auch jeder FRITZ!Box-Besitzer, der seine FRITZ!Box (als Initiator) mit seinem eigenen Server verbindet (auch dazu gibt es hier mehrere Themen), macht eigentlich nichts anderes ... die Frage ist am Ende eigentlich nur, wie so eine Verbindung auf L3 dann arbeitet.
Vielleicht suchst
Du Dir ja mal einen "seriösen Anbieter" mit IPSec und IKEv1 heraus und dann kann man ja mal sehen, ob und wie man das VPN zum Laufen bringt ... aber der umgekehrte Weg ist sicherlich nicht wirklich gangbar.
Und um das auch noch anzumerken ... Dein Windows-Phone nutzt mit ziemlicher Sicherheit IKEv2 und nicht IKEv1, ich wüßte jedenfalls nicht, daß MS inzwischen IKEv1 implementiert. Zumindest im "richtigen" Windows nicht und dann vermutlich auch nicht im Windows-Phone.
EDIT: Auch das noch einmal zur Klärung: L2TP/IPSec ist nicht IPSec nach RFC 4301 - das ist ein Layer2-Tunnel, der seinerseits PPP (und darin wieder IP) transportiert und nachträglich noch über IPSec verschlüsselt wird ... da sind die Pakete vollkommen anders aufgebaut und beide Protokolle sind nicht zueinander kompatibel.
EDIT2: Ich habe das glatt eben noch einmal probiert und eine 7490 als Client (ich hoffe, da sind wir uns über die Bedeutung des Begriffs einig) an einer anderen FRITZ!Box unter dem Konto eines FRITZ!Box-Benutzers angemeldet, also genauso, wie es ein iPhone oder ein Android-Gerät oder der ShrewSoft-Client oder selbst der AVM-Client für "FRITZ!Fernzugang" machen würde. Die VPN-Verbindung wird ganz normal aufgebaut und das "dsl"-Interface der "Client-FRITZ!Box" erhält als zusätzliche IP-Adresse die von der entfernten Box (die dann natürlich der "Server" ist) - damit sind dann auch alle Routing-Probleme ausgeräumt:
Code:
root@FB7490:~ $ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: tunl0: <NOARP> mtu 1480 qdisc noop
link/ipip 0.0.0.0 brd 0.0.0.0
3: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP200> mtu 1500 qdisc pfifo_fast qlen 1000
[...]
5: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP200> mtu 1500 qdisc pfifo_fast qlen 1000
[...]
6: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen 1000
[...]
7: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP200> mtu 1500 qdisc pfifo_fast qlen 1000
[...]
8: wasp: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
[...]
9: ptm_vr9: <BROADCAST,MULTICAST,UP,LOWER_UP100> mtu 1500 qdisc tbf qlen 1000
[...]
10: adsl: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 2000 qdisc pfifo_fast qlen 32
link/[19]
11: lan: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
link/ether 08:96:d7:ca:fe:de brd ff:ff:ff:ff:ff:ff
inet 192.168.nnn.1/28 brd 192.168.nnn.15 scope global lan
[...]
12: guest: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc noqueue
[...]
13: dsl: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen 100
link/ppp
inet 192.168.nnn.1/32 scope global dsl
[COLOR="#FF0000"] inet 192.168.mmm.201/32 scope global dsl <=== das ist die IP-Adresse des VPN-Clients im entfernten Netz
[/COLOR][...]
14: wifi0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
[...]
15: wifi1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
[...]
16: ath0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
[...]
17: ath1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
[...]
18: wlan: <BROADCAST,MULTICAST,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen 1000
[...]
Alles in allem eher nichts Überraschendes ... ich verstehe nicht so richtig, wo das Problem liegen soll, die FRITZ!Box mit einem VPN-Anbieter zu verbinden. Was ggf. zum Problem wird, wäre das Routing des gesamten Verkehrs über diese VPN-Verbindung ... das liegt aber daran, daß der IPSec-Verkehr ja irgendwie nicht selbst über den Tunnel gehen darf und deshalb Vorkehrungen getroffen werden müssen, daß dieser nicht in die Range in der "accesslist" fällt. Bei einer "normalen" Verbindung zu einer Firma ist eben das dort verwendete Netz bekannt und es geht nur der Verkehr für dieses Netz durch den Tunnel, bei einem "catch all"-Tunnel über so einen VPN-Anbieter muß halt die "accesslist" den bereits als IPSec gekapselten Verkehr ausschließen. Eine Möglichkeit (habe ich auch erst in der vergangenen Woche irgendwo wieder gehabt in einem Thread hier, ich hatte glatt vergessen, daß die DNS-Auflösung für den Namen des Peers eben auch erst einmal ohne Tunnel funktionieren muß) wäre das Sperren von UDP/500 und UDP/4500 inkl. ESP in dieser "accesslist". Das ist dann sicherlich "handgeschöpft" als Konfiguration, aber das ist ja nun nicht wirklich verwunderlich, der GUI-Assistent ist ja nicht als übermäßig flexibel verschrien - das geht schon bei der Trennung in "initiator" und "responder" los, wenn man gar keinen "passiven" Responder mit dem GUI konfigurieren kann.
EDIT3: Hier noch die "Client"-Konfiguration der FRITZ!Box:
Code:
enabled = yes;
editable = yes;
conn_type = conntype_out;
name = "hostname.dynamic.mydomain.de";
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 = "hostname.dynamic.mydomain.de";
keepalive_ip = 0.0.0.0;
localid {
key_id = "remote_fritzbox_username";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "unleserlicher Schrott";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = yes;
xauth {
valid = yes;
username = "remote_fritzbox_username";
passwd = "remote_fritzbox_user_password";
}
use_cfgmode = yes;
phase2remoteid {
ipnet {
ipaddr = 0.0.0.0;
mask = 0.0.0.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
accesslist = "permit ip any 192.168.mmm.0 255.255.255.0";
Die Proposal-Auswahl ist natürlich grauenvoll (alles noch mit dem puren GUI konfiguriert), weil kein PFS unterstützt wird ... auch die "accesslist" ist noch nicht dazu geeignet, da allen Verkehr (oder auch nur ausgewählte Netzwerk-Bereiche) über die VPN-Verbindung zu schicken. Am einfachsten ist es (wenn man so einen Tunnel als Mittel gegen regionale Sperren verwenden will), in der "accesslist" die Netzwerkbereiche anzugeben, die über die VPN-Verbindung gehen sollen. Wenn das nicht möglich ist, müssen eben - wie oben erwähnt - die anderen Pakete aus dem Tunnel ausgeschlossen werden. DNS über den Tunnel zu schicken, ist nicht ganz so einfach, dann muß man mit einer Ausnahmeregel in jedem Falle dafür sorgen, daß der Name des Servers für den Tunnel noch aufgelöst werden kann oder man nimmt gleich den "remoteip"-Parameter anstelle von "remotehostname", wenn der Anbieter eine dedizierte Adresse hat und kein Load-Balancing verwendet, zumindest nicht über DNS-Round-Robin.
