Netgear FVS336Gv3 und Azure Site-to-Site VPN

Um auf Ressourcen in einer Azure Ressource Group vom lokalen Netzwerk zugreifen zu können, benötigen wir natürlich ein VPN. In meinem Lab habe ich einen Netgear FVS338v3, der hier als Firewall verwendet wird. Zusätzlich können über die NetGear Firewall aber auch verschiedene VPN Tunnel aufgebaut werden, unter anderem natürlich auch ein Site-to-Site VPN mit IPSec. Der Gedanke liegt also nah, diese Gerät als VPN Endpunkt für eine Azure Resource Group zu verwenden.

Nach einigen Versuchen (die leider alle fehlschlugen) sowie ein wenig Google, habe ich leider feststellen müssen, dass der FVS336Gv3 leider nicht unterstützt wird. Mit diesem Ergebnis habe ich mich allerdings nicht zufrieden gegeben, da laut Azure, alle Voraussetzungen und Features auf dem Netgear unterstützt werden.

Das einzige Problem, dass ich hier gefunden habe, ist die Unterstützung von IKEv2, was vom Netgear nicht richtig unterstützt wird bzw. umgesetzt ist. Da nun aber Azure auch noch IKEv1 unterstützt, sollte das eigentlich auch mit dem NetGear funktionieren. Fangen wir mal damit an, wie unsere Konfiguration am Ende des Artikles aussehen sollte:

Wichtig zu Wissen ist hier, dass für das VPN Gateway verschieden SKU‘s in Azure zur Verfügung stehen. Die „alten“ (Basic, Standard, HighPerformance) sowie die „neuen“ (VpnGw1, VpnGw2, VpnGw3). Außer bei Basic versucht Azure immer IKEv2 zu verwenden, sobald es von der anderen Seite unterstützt wird. Leider unterstützt der NetGear aber IKEv2 (wenn auch wohl nicht richtig). Beim FVS336Gv3 kommt dann mit IKEv2 die SA Phase nicht zustande und der Tunnel bleibt bei „IPsec SA Not Established“ stehen. Also liegt es auf der Hand, hier erstmal die SKU „Basic“ zu verwenden. Die beiden anderen „alten“ SKU‘s sollten übrigens nicht mehr verwendet werden.

Arbeiten mit SKUs für virtuelle Netzwerkgateways (Legacy-SKUs)

Hier noch eine kurze Übersicht der Unterschiede:

Basic sollte ausschließlich in Test oder Lab Umgebungen verwendet werden, da die Funktionen und vor allem die Leistung nicht ausreicht um im produktiven Umfeld eingesetzt zu werden. Nebenbei gesagt, werden wir dort dann sicher auch keinen Netgear FVS336Gv3 vorfinden.

Zuerst müssen wir natürlich unsere Azure Subscription vorbereiten. Wir benötigen an dieser Stelle folgendes:

• Eine entsprechende Resource Group in unserer Azure Subscription
• Ein virtuelles Netzwerk
• Ein virtuelles Gateway Subnet innerhalb dieses virtuellen Netzwerks
• Ein virtuelles Gateway das die Verbindung zu unserem lokalen Netzwerk herstellt
• Ein Local Gateway das unser lokales (Lab) Netzwerk representiert
• Und eine VPN Verbindung

Starten wir mit dem virtuellen Netzwerk, mit dem wir auch eine neue Resource Group anlegen (oder eine bestehende verwenden) können. Unter Neu suchen wir im Azure Marketplace nach Virtual Network. Sobald wir das wir hier Virtual Network ausgewählt und angeklickt haben, öffnet sich die Karte zur Konfiguration.

Name: Natürlich benötigt das virtuelle Netzwerk auch einen aussagekräftigen und möglichst „sprechenden“ Namen. Für diese Beispiel verwende ich hier LabVNet01.

Adressbereich: Hier erfassen wir den kompletten Adressbereich des virtuellen Netzwerks. Wir müssen darauf achten, dass es groß genug ist um weitere Subnetze aufzunehmen. Eine /24 Maske reicht hier also nicht aus. Um hier nicht in Konflikte mit meinen Netzwerken im Lab zu kommen, wähle ich hier 10.1.128.0/17 (255.255.128.0). Damit habe ich mehr ausreichend Platz (10.1.128.1 – 10.1.255.254 = 512 Subnetze mit 32766 Hosts).

Abonnement: Hier wählen wir natürlich unsere Suscription aus.

Ressoucengruppe: Haben wir noch keine angelegt, können wir eine neue Erstellen. Ansonsten wählen wir einfach eine vorhandene aus.

Standort: Hier müssen wir ein wenig aufpassen. Für die meisten Leser dieses Artikels wird es wahrscheinlich eine Site in Europa sein. Aber Achtung, nicht jeder Azure Service ist auch in jeder Site vorhanden. Ich wähle hier in der Regel Nord Europa.

Subnetz: An dieser Stelle können wir auch gleich ein Subnetz für unsere Ressourcen erstellen (virtuelle Server, Storage etc.). Wir müssen lediglich beachten, dass es auch im Adressbereich unseres virtuellen Netzwerks liegt. Ich wähle hier das Netzwerk 10.1.128.0/24 (255.255.255.0). Das sollte für ein paar Server ausreichen, als Bezeichnung (Name) vergebe ich hier FrontendSN.

Mit einem Klick auf Erstellen, lassen wir Azure nun das ganze erstellen.

Kommen wir nun zum Gateway Subnetz. Dazu wählen wir das virtuelle Netzwerk aus und klicken im Menü auf der linken Seite auf Subnetze. Hier sehen wir bereits unser FrontendSN. Bei einem Gateway Subnetz handelt es sich um ein spezielles Subnetz, dass wir mit einem Klick auf +Gateway Subnetz erstellen.

Den Namen können wir nicht ändern, denn dieser wird von Azure vorgegeben. Es darf auch nur ein Gateway Subnetz in einem virtuellen Netzwerk erstellt werden (was ja auch Sinn macht).

Adressbereich: Auch dieses Subnetz benötigt einen Adressbereich, der natürlich aus dem Bereich des virtuellen Netzwerks stammen muss. Prinzipiell können wir hier auch eine /28 Maske (255.255.255.240) verwenden. Um aber etwas Platz zu haben (Azure selbst benötigt auch Adressen) wählen wir hier eine /27. In diesem Beispiel also 10.1.255.0/27 (255.255.255.224). Somit haben wir 32 Hosts (26 verfügbar) was für eine Gateway Subnetz ausreichen sollte.

Auch wird mit einem Klick auf Erstellen das Subnet angelegt. Jetzt benötigen wir noch ein Gateway.

Unter Neu – Netzwerk wählen wir das Gateway für virtuelle Netzwerke aus.

Bei der Konfiguration müssen wir hier etwas aufpassen.

Name: Der Name sollte wie immer selbsterklärend und sprechend sein. Ich wähle hier LabGw01.

Gatewaytyp: Das ist natürlich ein VPN.

VPN-Typ: Hier wählen wir Richtlinienbasiert, denn nur dieser Typ verwendet mit der nachfolgenden SKU IKEv1 (was wir für den FVS336Gv3 zwingend benötigen).

SKU: Wie vorher beschrieben benötigen wir hier Basic. Wer keinen FVS336v3 anbinden möchte, kann natürlich auch jede andere „neue“ SKU verwenden.

Virtuelles Netzwerk: Hier wählen wir das zuvor erstellte virtuelle Netzwerk aus.

Adressbereich für Gateway Subnetz: Wird automatisch durch das vitruelle Gateway Subnetz, das wir ebenfalls zuvor angelegt haben, ermittelt.

Öffentliche IP-Adresse: Diese Adresse wird später bei der Konfiguration des FVS336v3 benötigt, denn über diese Adresse erreichen wir unsere Azure Resource Group. Diese Adresse müssen wir hier allerdings erst noch erstellen. Wir benötigen hier allerdings nur den Namen, alles andere macht Azure für uns. Ich habe hier passend zum Gateway den Namen LabGw01PIP gewählt.

Zum Abschluss klicken wir noch auf Erstellen, um das VPN-Gateway zu erzeugen. Die Einstellungen werden überprüft, und auf dem Dashboard wird die Kachel mit dem Hinweis angezeigt, dass das Gateway des virtuellen Netzwerks bereitgestellt wird. Die Erstellung eines Gateways kann bis zu 45 Minuten dauern, also etwas Geduld mitbringen. Unter Umständen müssen wir die Portalseite mehrfach aktualisieren, bis der Status „Abgeschlossen“ angezeigt wird.

Sobald das Gateway bereitgestellt wurde, können wir mit dem Gateway für das lokale Netzwerk weitermachen. Dieses Gateway beschreibt tatsächlich unser lokales Netzwerk, damit die Ressourcen in der Resource Group Wissen, wie sie unser Netzwerk über den VPN Tunnel erreichen.  Unter Neu – Netzwerk wählen wir das Lokales Netzwerkgateway aus.

Auch benötigen wir einen Namen, in meinem Fall LabGW01. Die IP-Adresse ist die öffentliche IP-Adresse des FVS336Gv3. Also wirklich öffentlich, keine NAT Adresse oder dynamischer DNS mit Hostnamen. Der Adressbereich entspricht unserem lokalen LAN (z.B. 192.168.1.0/24). Hier können auch mehrere Adressbereiche erfasst werden. Die Ressourcengruppe sollte auch die bereits verwendete sein, alle restlichen Einstellungen sollten nun selbsterklärend sein.

Sobald wir uns auf der Oberfläche des FVS336Gv3 als Administrator angemeldet haben, gehen wir zu VPN – VPN Wizard. Prinzipiell ist eigentlich alles selbsterklärend.

About VPN Wizard: Hier wählen wir natürlich Gateway.

Connection Name: Hier kommt wieder ein aussagekräftiger Name rein.

Pre-Shared Key: Den PSK müssen wir natürlich später auch noch in unserer Azure Verbindung konfigurieren.

WAN-Interface: An dieser Stelle wählen wir noch das WAN Interface aus, auf das die Verbindung ankommen. Wenn wir noch ein weiteres Interface haben, können wir hier noch das Rollover aktivieren.

Remote WAN IP: Hier kommt die Public IP des Azure Gateway rein.

Local WAN IP: Logischer Weise kommt dann hier die öffentliche IP-Adresse des FVS336Gv3 hinein.

Remote LAN Segment: Gemäß unserem Beispiel wäre das 10.1.128.0 (also das FrontEndSN)

Remote LAN Subnet Mask: Ebenfalls gemäß Beispiel die 255.255.255.0

Haben wir alles mit Apply gesichert, schauen wir uns noch die erzeugte VPN Policy sowie die IPSec Policy an.

Die VPN Policy zeigt uns im Wesentlichen das, was wir gerade über den Wizard angelegt wurde. Interessant ist hier nur der Teil unter Auto Policy Parameters. Netgear wählt hier leider den falschen Encryption Algorithm, diesen stellen wir hier von 3DES auf AES-256.

Alle anderen Parameter stellen wir wie im nachfolgenden Screenshot ein.

Den Encryption Algorithm müssen wir auch noch in der IKE Policy ändern. Allerdings müssen wir zum Bearbeiten der IKE Policy zuerst die VPN Policy deaktivieren.

Sobald die Policy deaktiviert ist, schauen wir uns die IKE Policy an.

Mode Config: Wird in unserem Fall nicht benutzt und sollte auf No bleiben.

General: Die Direction ist natürlich Both und der Exchange Mode bleibt bei Main.

Local und Remote: sollten bereits durch den Wizard die richtigen IP-Adressen enthalten.

IKE SA Parameter: Hier stellen wir den Encryption Parameter wieder auf AES-256 (statt 3DES) und den Authentication Parameter auf SHA1.

Die restlichen Parameter sollten ebenfalls bereits durch den Wizard gefüllt sein. Zu beachten ist hier, dass wir Dead Peer Detection deaktiviert lassen. Den Bereich Exentended Authentication lassen wir ebenfalls deaktiviert, da wir ja ein Site-to-Site VPN aufbauen möchten.

Abschließend speichern wir noch alles mit Apply. An dieser Stelle nicht vergessen, die VPN Policy wieder zu aktivieren.

Das war dann die Konfiguration an unseren FVS336Gv3, jetzt müssen wir in unserer Azure Resource Group nur noch eine Verbindung erstellen. Wir wechseln also wieder zum Azure Resource Manager und melden uns dort an.

Im Azure Resource Manager wählen wir Neu und suchen nach Verbindungen. Da es nur eine Verbindung gibt, wählen wir diese und klicken auf Erstellen.

Im ersten Schritt wählen wir nur den Verbindungstyp, hier Standort-zu-Standort (IPSec), aus und wählen die Resource Group sowie unsere Subscription und Standort aus.

Der zweite Schritt ist auch relativ selbsterklärend. Wir wählen hier lediglich das vorhandene Gateway für virtuelle Netzwerke sowie das lokale Netzwerkgateway aus. Was wir jetzt noch brauchen ist ein Name für die Verbindung sowie den Pre-Shared Key, den wir auch auf dem FVS336Gv3 eingetragen haben (BGP sollte nicht aktiviert werden).

Abschließend bekomen wir noch eine Übersicht angezeigt und der Tunnel sollte nach kurzer Zeit auf unserem Netgear FVS336Gv3 als IPsec SA Established stehen.

Bitte hier noch beachten, dass es sich um ein Site-to-Site VPN handelt, der Tunnel bleibt ständig aufgebaut. Bei Volumentarifen kann das ein Kostenblock sein, der zu berücksichtigen ist. Diese Konfiguration kosten auch bei Azure Geld, wenn auch nur ein paar Cent, also bitte beachten.

Was in diesem Artikel so schön runtergeschrieben ist, hat mich tatsächlich fast zwei volle Tage gekostet. Obwohl ich mir große Mühe gegeben habe, kann sich auch hier ein Fehler eingschlichen haben. Wer etwas findet ist gern dazu aufgefordert, einen entsprechenden Kommentar zu hinterlassen. Ich werde sicher kurzfristig noch meine Troubleshooting Tips  und PowerShell Skripte dazuschreiben. Bis dahin erstmal viel Erfolg mit den weiteren Schritten in Azure.

Wer es sich jetzt ganz einfach machen möchte, der verwendet einfach das verlinkte ARM-Template.

Bildnachweis Titelbild: 123RF Lizenzfreie Bilder