VPN – Grundlagen

Was ist ein VPN und wozu brauchst du es?

Ein VPN (Virtual Private Network) ist ein verschlüsselter Tunnel durch das öffentliche Internet, der so wirkt, als wärst du direkt im Firmennetz eingesteckt – obwohl du von zu Hause, aus dem Hotel oder aus dem Café arbeitest. Intern siehst du Dateifreigaben, kannst auf interne Webapplikationen zugreifen und wirst von der Firewall wie ein interner Benutzer behandelt.

Ohne VPN müsstest du entweder alle internen Ressourcen ins Internet exponieren (ein Sicherheitsalptraum) oder auf Remote-Desktop-Lösungen ausweichen, die in manchen Szenarien unpraktisch sind.

Typische Anwendungsfälle im KMU:

• Mitarbeitende arbeiten im Homeoffice und brauchen Zugriff auf Dateiserver oder ERP
• Filiale verbindet sich permanent mit dem Hauptsitz (Site-to-Site)
• IT-Admin wartet Server aus der Ferne sicher via VPN + RDP
• Aussendienstmitarbeitende verbinden sich aus dem Hotel ins Firmennetz

VPN-Typen: Welcher passt wann?

Remote Access VPN

Der Klassiker im KMU: Einzelne Benutzerinnen und Benutzer verbinden sich von aussen ins Firmennetz. Der Client (z. B. ein Laptop) baut eine Verbindung zum VPN-Gateway auf der Firewall auf. Danach ist er logisch Teil des internen Netzes.

• Vorteil: Flexibel, funktioniert für jeden einzelnen User
• Einsatz: Homeoffice, mobile Mitarbeitende

Site-to-Site VPN

Zwei Standorte (z. B. Hauptsitz Zürich und Filiale Bern) verbinden sich permanent miteinander. Die VPN-Verbindung läuft zwischen zwei Firewalls – die Endgeräte an beiden Standorten merken davon nichts, sie sehen einfach das Netz des anderen Standorts.

• Vorteil: Dauerhaft, kein manuelles Verbinden nötig
• Einsatz: Filialanbindungen, Standortvernetzung

Split Tunneling vs. Full Tunnel

In den meisten KMU wird Split Tunneling bevorzugt, da die Bandbreite des VPN-Gateways begrenzt ist. Netflix-Streams und Windows-Updates sollen nicht über das Firmennetz laufen.

VPN-Protokolle im Vergleich

Das Protokoll bestimmt, wie der Tunnel aufgebaut wird, wie er gesichert wird und wie performant er ist. Im Jahr 2025 sind drei Protokolle dominant:

WireGuard im Detail

WireGuard ist die modernste Option. Der Code ist so kompakt (~4 000 Zeilen gegenüber ~100 000 bei OpenVPN), dass er vollständig auditiert werden kann. WireGuard ist im Linux-Kernel integriert und auf allen modernen Plattformen verfügbar. Typische Einsatzszenarien im KMU: OPNsense oder pfSense als Gateway, Mitarbeitende verbinden sich mit dem offiziellen WireGuard-Client.

IKEv2/IPsec im Unternehmenskontext

In grösseren KMU mit Firewalls von Sophos, Fortinet oder Cisco ist IKEv2/IPsec Standard. Windows unterstützt IKEv2 nativ ohne zusätzlichen Client – das macht das Rollout einfach. Mit Always On VPN (Windows Server + NPS) lässt sich ein vollautomatisches VPN einrichten, das sich vor dem Login des Benutzers verbindet und Zertifikate zur Authentifizierung nutzt.

IPsec im Detail: IKE Phase 1 und Phase 2

IPsec ist kein einzelnes Protokoll, sondern ein Framework aus mehreren Bausteinen. Der Tunnelaufbau läuft über IKE (Internet Key Exchange) in zwei klar getrennten Phasen ab – wer Site-to-Site-VPNs zwischen unterschiedlichen Herstellern konfiguriert, sollte diese beiden Phasen verstehen, denn die meisten Tunnelprobleme entstehen genau an der Schnittstelle zwischen ihnen.

Phase 1 (IKE-SA): Die Gateways vertrauen sich

In Phase 1 bauen die beiden VPN-Gateways einen ersten, sicheren Kanal auf, über den sie sich gegenseitig authentifizieren und die Parameter für alles Weitere aushandeln. Bei IKEv1 heisst das der Main Mode, bei IKEv2 die Nachrichten IKE_SA_INIT und IKE_AUTH. Ausgehandelt werden:

• Verschlüsselungsalgorithmus – z. B. AES-256
• Integritäts-/Hash-Algorithmus – z. B. SHA-256 oder SHA-384
• Diffie-Hellman-Gruppe – bestimmt die Schlüssellänge des DH-Schlüsselaustauschs, gängig sind Gruppe 14 (2048 Bit), 19/20 (elliptische Kurven) oder 21
• Authentifizierungsmethode – Pre-Shared Key (PSK) oder Zertifikat
• Lifetime – wie lange die Phase-1-SA gültig bleibt, üblich 8–24 Stunden (28 800–86 400 Sekunden)

Das Ergebnis ist die IKE-SA (bei IKEv1 auch ISAKMP-SA genannt) – ein bidirektionaler, verschlüsselter Kontrollkanal zwischen den beiden Gateways.

Phase 2 (Child-SA): Die Nutzdaten werden geschützt

Über den in Phase 1 aufgebauten Kanal handeln die Gateways in Phase 2 (Quick Mode bei IKEv1, CREATE_CHILD_SA bei IKEv2) die eigentlichen IPsec-SAs aus, die den Nutzdatenverkehr per ESP verschlüsseln. Hier werden festgelegt:

• Verschlüsselung und Hash für ESP (können von Phase 1 abweichen)
• Traffic Selectors (auch Proxy-IDs genannt) – welche lokalen und entfernten Subnetze über diesen Tunnel dürfen
• Lifetime – meist kürzer als Phase 1, üblich 1 Stunde (3600 Sekunden)
• Optional: PFS

IKEv1 vs. IKEv2: Begriffe im Vergleich

Typische Fehlkonfigurationen zwischen zwei Herstellern

In der Praxis stammen die beiden Enden eines Site-to-Site-Tunnels selten vom gleichen Hersteller – Hauptsitz mit FortiGate, Filiale mit Sophos XGS, oder eine Cloud-Gegenstelle wie Azure VPN Gateway. Genau an dieser Schnittstelle entstehen die meisten Probleme:

Praxisbeispiel: Site-to-Site-VPN Schritt für Schritt konfigurieren

Szenario: Hauptsitz Zürich (FortiGate, öffentliche IP 203.0.113.10, internes Netz 10.10.0.0/24) soll dauerhaft mit der Filiale Bern (Gegenstelle, öffentliche IP 198.51.100.20, internes Netz 10.20.0.0/24) verbunden werden.

Schritt 1: Parameter mit der Gegenstelle abstimmen

Schritt 2: Phase 1 und Phase 2 auf der FortiGate konfigurieren (Zürich)

config vpn ipsec phase1-interface
    edit "to-bern"
        set interface "wan1"
        set ike-version 2
        set peertype any
        set proposal aes256-sha256
        set dhgrp 14
        set remote-gw 198.51.100.20
        set psksecret "EinStarkesGemeinsamesGeheimnis!"
        set keylife 86400
        set nattraversal enable
        set dpd on-idle
        set dpd-retrycount 3
    next
end

config vpn ipsec phase2-interface
    edit "to-bern"
        set phase1name "to-bern"
        set proposal aes256-sha256
        set pfs enable
        set dhgrp 14
        set keylifeseconds 3600
        set src-subnet 10.10.0.0/24
        set dst-subnet 10.20.0.0/24
    next
end

Schritt 3: Routing und Firewall-Regeln

Der Tunnel selbst überträgt noch keinen Traffic – dafür braucht es eine statische Route zum entfernten Netz über das VPN-Interface sowie Firewall-Regeln in beide Richtungen:

config router static
    edit 0
        set dst 10.20.0.0 255.255.255.0
        set device "to-bern"
    next
end

config firewall policy
    edit 0
        set name "Zuerich-zu-Bern"
        set srcintf "lan"
        set dstintf "to-bern"
        set srcaddr "Zuerich-LAN"
        set dstaddr "Bern-LAN"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end

Auf der Gegenstelle in Bern müssen dieselben Werte aus Schritt 1 gesetzt werden – nur die Rollen von Quell- und Zielnetz sowie die Gateway-IP-Adressen sind gespiegelt.

Schritt 4: Tunnel verifizieren

# Phase-1-Status (IKE-SA) pruefen
diagnose vpn ike gateway list

# Phase-2-Status (IPsec-SA) pruefen
diagnose vpn tunnel list

# Tunnel manuell trennen und neu aufbauen
diagnose vpn tunnel down to-bern
diagnose vpn tunnel up to-bern

Steht Phase 1, aber Phase 2 kommt nicht zustande: zuerst PFS-Gruppe und Traffic Selectors auf beiden Seiten vergleichen. Steht auch Phase 1 nicht: Proposal-Set und Pre-Shared Key nochmals gegenprüfen – ein einziges falsches Zeichen im PSK reicht für einen stillen Fehlschlag ohne aussagekräftige Fehlermeldung.

Windows VPN einrichten (manuell)

Über die Einstellungen (GUI)

1. Win+I öffnen → Netzwerk und Internet → VPN
2. VPN-Verbindung hinzufügen klicken
3. Anbieter: Windows (integriert)
4. Verbindungsname: z. B. Firmen-VPN
5. Serveradresse: IP oder FQDN des VPN-Gateways
6. VPN-Typ: z. B. IKEv2 oder L2TP/IPsec mit vorinstalliertem Schlüssel
7. Anmeldedaten eingeben und speichern

Über PowerShell

# IKEv2-Verbindung erstellen
Add-VpnConnection `
  -Name "Firmen-VPN" `
  -ServerAddress "vpn.firma.ch" `
  -TunnelType "IKEv2" `
  -AuthenticationMethod "MSChapv2" `
  -EncryptionLevel "Required" `
  -RememberCredential $true `
  -SplitTunneling $true

# Verbindungen auflisten
Get-VpnConnection

# Verbinden
rasdial "Firmen-VPN" benutzername passwort

# Trennen
rasdial "Firmen-VPN" /disconnect

Split-Tunnel-Routen manuell hinzufügen

Wenn Split Tunneling aktiv ist, weiss Windows zunächst nicht, welche internen Netze durch den Tunnel sollen. Du kannst das manuell steuern:

# Route durch VPN hinzufügen (z.B. internes Netz 10.0.0.0/8)
Add-VpnConnectionRoute -ConnectionName "Firmen-VPN" -DestinationPrefix "10.0.0.0/8"

# Alle Routen einer VPN-Verbindung anzeigen
Get-VpnConnectionTrigger -ConnectionName "Firmen-VPN"

Split-DNS bei VPN

Split Tunneling regelt, welcher Traffic durch den VPN-Tunnel läuft. Split-DNS regelt die gleiche Frage für die Namensauflösung: Sollen Anfragen nach fileserver.firma.local an den internen DNS-Server gehen, während google.com weiterhin ganz normal öffentlich aufgelöst wird?

Ohne Split-DNS gibt es zwei unbefriedigende Alternativen:

• Kompletter DNS-Traffic über den internen Server: funktioniert, aber jede öffentliche Namensauflösung macht einen Umweg über das Firmennetz – spürbar langsamer, besonders bei schwacher VPN-Anbindung.
• DNS bleibt komplett extern: interne Hostnamen wie fileserver.firma.local lassen sich gar nicht mehr auflösen, nur noch per IP-Adresse erreichbar.

Die Lösung: NRPT (Name Resolution Policy Table)

Windows löst das über die NRPT: Eine Regel legt fest, dass Anfragen für eine bestimmte Namespace-Endung (z. B. .firma.local) an bestimmte interne DNS-Server geschickt werden, während alles andere normal über den konfigurierten DNS-Server des Clients läuft.

# NRPT-Regel fuer die interne Domaene anlegen
Add-DnsClientNrptRule -Namespace ".firma.local" -NameServers "10.10.0.5","10.10.0.6"

# Aktive Regeln pruefen
Get-DnsClientNrptPolicy

# Regel wieder entfernen
Get-DnsClientNrptRule | Where-Object { $_.Namespace -eq ".firma.local" } | Remove-DnsClientNrptRule

Bei Always On VPN wird die NRPT-Regel direkt als Teil des VPN-Profils (ProfileXML) ausgerollt – der Client erhält sie automatisch beim Verbindungsaufbau, ganz ohne manuellen Eingriff. Bei klassischen, manuell eingerichteten VPN-Verbindungen lohnt es sich, den DNS-Suffix gleich mitzugeben, damit unqualifizierte Namen automatisch ergänzt werden:

Add-VpnConnection -Name "Firmen-VPN" -ServerAddress "vpn.firma.ch" `
  -TunnelType "IKEv2" -DnsSuffix "firma.local" -SplitTunneling $true

Gängige VPN-Lösungen im KMU

Troubleshooting: Häufige VPN-Probleme

VPN verbindet sich, aber interne Ressourcen sind nicht erreichbar

Das ist das häufigste Problem bei neuen VPN-Verbindungen. Mögliche Ursachen:

1. Falsches Split-Tunneling: Die Route für das interne Netz fehlt. Prüfen mit:

   route print
   # Siehst du das interne Subnetz (z.B. 10.0.0.0) in der Routingtabelle?

2. DNS-Problem: Der VPN-Client nutzt noch den öffentlichen DNS-Server, nicht den internen. Internen DNS manuell in der VPN-Verbindung eintragen oder den Gateway prüfen.
3. Firewall-Regel: Interne Firewall lässt VPN-Clients nicht auf den gewünschten Host zu.

# DNS prüfen: Löst der interne Hostname auf?
Resolve-DnsName fileserver.firma.local

# Verbindung zum Ziel testen (z.B. SMB-Port 445)
Test-NetConnection -ComputerName fileserver.firma.local -Port 445

VPN-Verbindung bricht immer wieder ab

Häufige Ursache: MTU-Probleme. VPN-Pakete haben durch den Tunnel-Header mehr Overhead. Wenn die MTU zu gross eingestellt ist, werden Pakete fragmentiert oder verworfen.

# Aktuelle MTU des VPN-Adapters anzeigen
Get-NetAdapter | Where-Object { $_.Name -like "*VPN*" } | Select-Object Name, MtuSize

# MTU manuell reduzieren (1350-1400 ist ein guter Startwert fuer IKEv2)
$adapter = Get-NetAdapter | Where-Object { $_.Name -like "*VPN*" }
Set-NetIPInterface -InterfaceIndex $adapter.ifIndex -NlMtuBytes 1350

Weitere Ursachen für Verbindungsabbrüche:

• UDP-Port geblockt: IKEv2 nutzt UDP 500 und 4500 (NAT-Traversal). Beide Ports müssen auf der Firewall offen sein.
• Keep-Alive zu kurz: Manche Firewalls trennen inaktive Verbindungen. Keep-Alive-Intervall im VPN-Client erhöhen.
• WLAN-Wechsel: IKEv2 unterstützt MOBIKE (Mobility and Multihoming Protocol) für nahtlosen Netzwechsel – sicherstellen, dass das Gateway MOBIKE aktiviert hat.

VPN verbindet sich gar nicht

# VPN-Ereignisse in der Ereignisanzeige prüfen
Get-WinEvent -LogName "Application" | Where-Object { $_.Message -like "*RasClient*" } | Select-Object -First 20

# Netzwerkdiagnose
Test-NetConnection -ComputerName vpn.firma.ch -Port 443
Test-NetConnection -ComputerName vpn.firma.ch -Port 500

Häufige Ursachen:

• Falsche Serveradresse oder Port: DNS-Name des Gateways auflösbar? IP direkt testen.
• Zertifikatsfehler: Bei IKEv2 muss das Serverzertifikat vertrauenswürdig sein. CA ins Windows-Zertifikatsspeicher importieren.
• Pre-Shared Key falsch: Bei PSK-basiertem IPsec den Key nochmal prüfen – ein Tippfehler reicht.

Langsame VPN-Verbindung

VPN und Sicherheit im KMU

Ein VPN ist eine Zugang ins Firmennetz – entsprechend muss der Zugang gesichert sein:

1. Multi-Faktor-Authentifizierung (MFA) ist Pflicht Ein gestohlenes Passwort allein darf nicht reichen, um ins Firmennetz zu kommen. Konfiguriere MFA für den VPN-Zugang, z. B. via RADIUS + Microsoft Entra MFA oder TOTP mit einer Authenticator-App.

2. Zertifikate statt Passwörter Bei Always On VPN und IKEv2 in Unternehmensumgebungen: Computerzertifikate für die Authentifizierung nutzen. Das ist robuster als Passwörter und lässt sich gut mit Intune/MDM rollout.

3. Zugriff beschränken Nicht jeder VPN-User braucht Zugang zu allem. Nutze Firewall-Regeln oder VLAN-Segmentierung, um VPN-Clients nur auf die Ressourcen zuzulassen, die sie wirklich brauchen.

4. RDP nicht direkt aus dem Internet exponieren Der VPN ist genau der richtige Weg, um RDP abzusichern: VPN aufbauen, danach RDP auf die interne IP verbinden. Kein Port-Forwarding auf 3389 am Router. Mehr dazu auf der Seite RDP Grundlagen.

5. Logs auswerten VPN-Gateway-Logs zeigen fehlgeschlagene Logins, ungewöhnliche Zugriffszeiten und Verbindungen aus verdächtigen Ländern. Schau regelmässig rein – oder richte eine Alerting-Regel ein.

Client-Zertifikatsverwaltung mit eigener interner CA

Passwörter für VPN-Zugänge lassen sich stehlen, erraten oder phishen. Zertifikatsbasierte Authentifizierung (EAP-TLS) ist deshalb der Standard für Always On VPN und für IKEv2 in grösseren Unternehmen. Der Aufbau und Betrieb einer eigenen Zertifizierungsstelle (CA) mit Active Directory Certificate Services ist ausführlich unter AD CS / PKI – Grundlagen beschrieben – hier nur der Teil, der speziell für VPN-Clients relevant ist.

Zertifikatsvorlage für VPN-Clients

Für die VPN-Authentifizierung braucht es eine eigene Zertifikatsvorlage mit dem erweiterten Schlüsselverwendungszweck (EKU) Client-Authentifizierung (OID 1.3.6.1.5.5.7.3.2). Wichtige Einstellungen:

• Schlüssellänge mindestens 2048 Bit (besser 3072 Bit oder ECC P-256)
• Antragstellername: bei benutzerbasiertem VPN der Benutzername (User Principal Name), bei Device Tunnel der Computername
• Gültigkeitsdauer: üblich 1–2 Jahre, mit automatischer Erneuerung vor Ablauf

Automatische Verteilung

• Domänengebundene Geräte: Auto-Enrollment über Gruppenrichtlinie – das Zertifikat wird beim Login automatisch angefordert und vor Ablauf erneuert, ohne dass die Benutzerin oder der Benutzer etwas tun muss.
• Nicht domänengebundene oder mobile Geräte: SCEP-Profil über Intune, das Zertifikatsanfragen an die interne CA weiterleitet (über den Netzwerkgerätezulassungsdienst NDES). Details dazu in Intune – Grundlagen.

Lebenszyklus und Sperrung

Der kritische Teil ist nicht die Ausstellung, sondern die Sperrung: Verlässt eine Mitarbeiterin die Firma, muss ihr VPN-Client-Zertifikat sofort gesperrt werden – sonst funktioniert der VPN-Zugang mit einem gestohlenen oder mitgenommenen Gerät munter weiter, selbst wenn das AD-Konto längst deaktiviert ist.

# Auf dem CA-Server: Zertifikat anhand der Seriennummer sperren
certutil -revoke <Seriennummer> 1

# Neue Sperrliste (CRL) veroeffentlichen
certutil -crl

Die Zertifikatssperrung gehört fest in den Offboarding-Prozess, siehe IT-Onboarding und -Offboarding.

VPN-Kapazitätsplanung: Wie viele Tunnel und User pro Firewall-Klasse?

Bevor du eine neue Firewall für VPN-Zugriffe beschaffst, brauchst du eine grobe Vorstellung, wie viele gleichzeitige Tunnel und Benutzer das Gerät stemmen muss. Herstellerangaben zu “maximalen Tunneln” beschreiben dabei nur eine Obergrenze der Kontrollebene – wie viele Tunnel tatsächlich sinnvoll nutzbar sind, hängt stark von der verfügbaren Krypto-Durchsatzleistung ab.

Referenzwerte aus aktuellen Datenblättern

Faustregeln für die Planung

• Nicht nur nach Tunnel-Maximum planen – rechne mit durchschnittlicher Bandbreite pro Benutzer (z. B. 2–5 Mbit/s für Homeoffice-Alltag ohne Videocalls, deutlich mehr mit Teams oder Zoom) und multipliziere mit der erwarteten Anzahl gleichzeitiger Verbindungen.
• SSL-VPN-Lizenzierung separat prüfen: Bei vielen Herstellern ist die Anzahl gleichzeitiger SSL-VPN-User zusätzlich lizenzpflichtig begrenzt, unabhängig vom technischen Maximum des Geräts.
• Planungspuffer von 30–50 % einrechnen für Wachstum und Ausnahmesituationen (z. B. spontan hoher Homeoffice-Anteil bei Extremwetter oder Grossereignissen).
• HA-Failover mitdenken: Bei einem Cluster aus zwei Firewalls muss die verbleibende Einheit im Failover-Fall die volle Last allein tragen können – nicht nur die Hälfte einplanen.
• Site-to-Site-Tunnel zählen mit: Jede Filiale, jeder Cloud-VNet-Tunnel (z. B. Azure) und jeder Partneranschluss belegt ebenfalls einen Tunnel-Slot – bei der Kapazitätsplanung nicht vergessen.

VPN-Logging und SIEM-Integration

Das VPN-Gateway ist einer der am stärksten von aussen angegriffenen Punkte im Netzwerk – entsprechend wichtig ist es, die Ereignisse nicht nur lokal zu speichern, sondern zentral auszuwerten.

Was du protokollieren solltest

• Erfolgreiche und fehlgeschlagene Anmeldeversuche, jeweils mit Quell-IP-Adresse, Zeitstempel und Benutzername
• Verbindungsauf- und -abbauzeiten pro Tunnel bzw. pro Benutzer
• Fehlgeschlagene Phase-1- und Phase-2-Aushandlungen (wichtig für die Fehlersuche, siehe oben)
• Verwendetes Protokoll und Authentifizierungsmethode (PSK, Zertifikat, MFA)
• Übertragenes Datenvolumen pro Tunnel (Anomalien können auf Datenabfluss hindeuten)

Weiterleitung an ein SIEM

Die meisten Unternehmens-Firewalls unterstützen Syslog-Export (RFC 5424) an ein zentrales SIEM. Beispiel für eine FortiGate:

config log syslogd setting
    set status enable
    set server "10.10.0.50"
    set port 514
    set facility local7
end

Wie ein SIEM solche Logs sammelt, normalisiert und korreliert, ist ausführlich unter SIEM/SOC – Grundlagen beschrieben. Für VPN-Events lohnen sich insbesondere folgende Korrelationsregeln:

Aufbewahrungsfristen für VPN-Logs richten sich nach den regulatorischen Vorgaben deines Unternehmens – Details dazu in DSGVO/nDSG in der IT-Praxis und, für Schweizer KMU mit Bezug zu kritischer Infrastruktur, unter NIS2 für Schweizer KMU.

Crosslinks

Thematisch verwandte Seiten in diesem Wiki:

• RDP – Grundlagen – RDP sicher via VPN nutzen statt direkt ins Internet
• IT-Security Grundlagen für KMU – Überblick über Schutzmassnahmen inklusive MFA und Netzwerksegmentierung
• TCP/IP Grundlagen – Routing, Ports und Subnetting verstehen, bevor du VPN-Routen konfigurierst
• Intune – Grundlagen – VPN-Profile automatisch via MDM auf alle Geräte ausrollen
• DNS – Grundlagen – Zonen, Forwarder und Namensauflösung als Basis für Split-DNS
• AD CS / PKI – Grundlagen – eigene interne CA für Zertifikatsauthentifizierung aufbauen
• SIEM/SOC – Grundlagen – VPN-Logs zentral sammeln, korrelieren und auswerten
• Firewall – Grundlagen – Regelwerk und Zonenkonzept rund um das VPN-Gateway

Weiterlernen

• Microsoft Docs: Always On VPN – Übersicht (deutsch) – Microsofts offizielle Dokumentation zu Always On VPN mit Windows Server
• WireGuard – Offizielle Website – Protokollbeschreibung, Installation und Konzepte
• OpenVPN Dokumentation – Umfangreiche Anleitung zur OpenVPN-Konfiguration
• Microsoft Docs: VPN-Authentifizierungsoptionen – Zertifikate, EAP, MSCHAPv2 im Vergleich
• armann-systems: VPN-Protokolle erklärt – Guter deutschsprachiger Vergleich der aktuellen Protokolle
• Richard M. Hicks Consulting: Always On VPN Blog – Tiefe Einblicke in Always On VPN, IKEv2-Fragmentation und Troubleshooting
• Fortinet: Phase 1 Configuration (FortiOS Administration Guide) – Offizielle Referenz zu allen IKE-Phase-1-Parametern
• Fortinet Community: Matching IKEv1 Phase 1 and Phase 2 Proposals – Praxisnahe Troubleshooting-Tipps bei Proposal-Mismatches
• Sophos: XGS Series Firewall Appliances – Aktuelle Datenblattwerte zu IPsec- und SSL-VPN-Tunnelkapazitäten

Videos

YouTube

YouTube