In diesem Beitrag geht es um das Herstellen eines VPNs vom heimischen ADSL-Netzwerk zu einem virtuellen Netzwerk in Windows Azure. Die lokalen Computer im Heimnetzwerk werden dadurch mit der/den virtuellen Maschinen in Azure z.B. in einer Arbeitsgruppe bzw. Domäne verbunden.
Die hier verwendeten Host- bzw. Netzwerknamen und IP-Adressen dienen nur als Beispiel. Bitte entsprechend ersetzen!

Vorgehensweise:
Den Standard-IP-Adressbereich der FritzBox (192.168.178.0/24) ändern. AVM sieht nicht vor, dass man in diesem Bereich (versehentlich) VPN-Einstellungen vornimmt.

Wenn für den eigenen DLS-Anschluss keine feste IP gemietet wurde, dann bei bsp. einen Account bei https://freedns.afraid.org/ registrieren. Die sind sehr unkompliziert und fahren schnelle Updates auf ihre Nameserver.
In Freedns im Menüpunkt  „Dynamic DNS“ den Link zum Nameserver-Update (Direct URL) kopieren und zusammen mit den Anmeldedaten in der FritzBox unter „Internet –> Freigaben –> Dynamic DNS“ einfügen.

DNS-Update durch einfachen Aufruf mit kopierter URL / mit der öffentlichen IP der FritzBox vergleichen. Sollte alles stimming sein.

Im Azure-Portal ein neues virtuelles Netzwerk erstellen.

Als DNS kann der default von Microsoft genommen werden. Site-Site-VPN konfigurieren (ggf. auch als Lan to Lan bekannt)

Den lokalen Part des VPN (FritzBox-Netz) eintragen. Die öffentliche IP ändert sich leider alle 24h durch Zwangstrennung. Für unser Beispiel aber ausreichend.

Die Azure-Seite des VPN belegt Microsoft mit einem /8-Netz vor. So groß muss es dann doch nicht sein; 254 Adressen sollten reichen.

Das Erstellen des virtuellen Netzwerks geht relativ schnell, wohingegen der lokale Part im Portal etwas zögerlich nachkommt. 1 Minute warten. Am Schluss muss es im Dashboard so aussehen:

Danach das Gateway mit statischem Routing erstellen. 2-5 Minuten warten.

De VPN-Farbe wechselt während der Arbeit auf gelb.

Danach ist im Dashboard die öffentliche IP zu sehen, unter der das Azure-VPN erreicht werden kann. Diese IP ist – zusammen mit dem Shared Secret (Dashboard –> Schlüssel verwalten) und  den übrigen bekannten Parametern (in rot gehalten: ersetzen!) in eine Datei „fritzbox.cfg“ einzutragen, welche dann in die FritzBox unter „Internet–>Freigaben–>VPN“ importiert wird.

[fritzbox.cfg: Anpassen!]
—————————————– snip ———————————————————

vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = „Azure-Netzwerk“;
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 23.101.75.19;
remote_virtualip = 0.0.0.0;
localid {
fqdn = „krombusch.ignorelist.com„;
}
remoteid {
ipaddr = 23.101.75.19;
}
mode = phase1_mode_aggressive;
phase1ss = „all/all/all“;
keytype = connkeytype_pre_shared;
key = „[der_kopierte_schlüssel]„;
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.78.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 10.0.0.0;
mask = 255.255.255.0;
}
}
phase2ss = „esp-all-all/ah-none/comp-all/no-pfs„;
accesslist = „permit ip any 10.0.0.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“;
}

// EOF

—————————————– snip ———————————————————

ACHTUNG: Beim Import rekonnektiert sich das DSL. Deshalb den Freedns-Namen über die direkte URL updaten und im Anschluss die VPN-ID des lokalen Endpunkts im Azure-Dashboard. (Das Leidwesen der dynamischen IPs).

Danach sollte sich das VPN aufbauen, erkennbar in Azure und in der FritzBox an den grünen Farben. (Welche Einheit „H“ ist, kann ich nicht sagen…)

Das Gateway auf der Azure-Seite sollte somit aus dem lokalen Netz erreichbar sein.

Hinweis zur FritzBox: Selbst die alte 7170 bekommt so ein VPN hin. Ich musste allerdings erst das 1und1-Branding rausnehmen, weil sonst kein Firmware-Update möglich war. Anleitungen für solche Aktionen unter http://www.wehavemorefun.de/fritzbox/AVM_Wiki

Update 18.05.2015
Der Beitrag gibt den Stand der Azure Technologie von Anfang September 2014 wieder. Ich hatte für meinen damaligen Testzeitraum 2VMs hinter o.g. Szenario. Die waren soweit ok, nur der i/o war etwas mau. Nach 30 Tagen wurde alles gelöscht, und ich habe das Projekt nicht weiter verfolgt.
Dass sich aber mittlerweile auch einiges an serverseitiger Scripting-Unterstützung getan hat, zeigt Marco Viets in seinem Posting. Hier fragt Azure den Dyndns-Anbieter ab und aktualisiert mit der erhaltenen IP periodisch den (heimischen) Endpunkt.
Bitte bedenken: Microsoft zählt den Traffic, unabhängig davon, ob der Endpunkt wirklich erreichbar ist. Ob nun durch Keep-Alive bei bestehender Verbindung oder vergebliches Auto-Reconnet bei veralteter IP: Die Bytes werden von eurer Kreditkarte abgezogen 🙂