Lösungen

Aufgabe 1

Ein VPN (Virtual Private Network) ist eine sichere, verschlüsselte Verbindung („Tunnel“) über ein unsicheres Netzwerk – meist das Internet.
Daten werden dabei verpackt, verschlüsselt und durch diesen Tunnel transportiert, sodass Dritte sie nicht mitlesen können.

VPNs arbeiten typischerweise auf OSI-Schicht 3 (Netzwerk) oder Schicht 5–7 (Session/Application) – je nach Protokoll:

IPsec: Layer 3
SSL/TLS (OpenVPN): Layer 5–7

Aufgabe 2

Typ	Beschreibung	Beispielprotokoll
Site-to-Site	Verbindung zwischen zwei Netzwerken (z. B. Firmenstandorten). Geräte beider Netze sehen sich direkt.	IPsec
Client-to-Site	Einzelner Benutzer (z. B. Homeoffice-PC) verbindet sich ins Unternehmensnetz.	SSL VPN, OpenVPN
End-to-End	Nur Kommunikation zwischen zwei Endpunkten wird verschlüsselt – unabhängig vom restlichen Netz.	TLS, SSH, WireGuard

Aufgabe 3

Protokoll	OSI-Schicht
IPsec	Layer 3 (Netzwerkebene)
SSL/TLS	Layer 5–7 (Session/Application)
OpenVPN	Layer 4–7 (Transport bis Anwendung)
WireGuard	Layer 3 (Netzwerkebene)

Aufgabe 4

a) Ablauf:

Phase 1 (IKE SA):
Authentifizierung der Gateways, Aushandlung von Schlüsselmaterial (DH-Gruppe 14, AES256, SHA256).
Ergebnis: gesicherter Kanal für Phase 2.
Phase 2 (IPsec SA):
Festlegung, welche Subnetze getunnelt werden (192.168.10.0 ↔ 192.168.20.0).
Schlüssel werden abgeleitet, Tunnel aktiv.

b) IKEv1 vs. IKEv2:

Merkmal	IKEv1	IKEv2
Geschwindigkeit	Mehrere Nachrichten nötig	Weniger Schritte
Stabilität	Komplex	Stabiler, effizienter
Fehlerbehandlung	Keine Wiederaufnahme	Automatische Wiederverbindung
Empfehlung	Veraltet	Standard heute

c) CLI-Befehle (FortiGate-Beispiel):

diagnose vpn ike gateway list
diagnose vpn tunnel list
get router info routing-table all

Aufgabe 5

Mögliche Ursachen:

Fehlende oder falsche Route zum Zielnetz → get router info routing-table
Firewallregel blockiert ICMP oder LAN-Zugriff → Policy prüfen
Split-Tunnel aktiviert → nur bestimmter Traffic geht durchs VPN
MTU zu groß → ping -s 1400 testen
DNS-Auflösung fehlerhaft → interner Name nicht auflösbar

Behebung: Routing und Policies prüfen, MTU anpassen, DNS auf VPN-Server verweisen.

Aufgabe 6

a) Unsicher, weil:

AES-128-CBC und SHA1 sind veraltet
tls-version-min 1.0 erlaubt unsichere Handshakes
keine Perfect Forward Secrecy (PFS)

b) Sichere Version:

cipher AES-256-GCM
auth SHA256
tls-version-min 1.3
dh none
ncp-ciphers AES-256-GCM:AES-128-GCM

Damit ist nur TLS 1.3 erlaubt und AES-GCM sorgt für moderne Authentifizierung und Integrität.

Aufgabe 7

Tunneltyp	Beschreibung	Vorteil	Nachteil
Split-Tunnel	Nur bestimmter Traffic läuft über VPN (z. B. Firmennetze).	Schnellere Internetverbindung, weniger Last	Sicherheitsrisiko durch parallelen Internetzugriff
Full-Tunnel	Sämtlicher Traffic läuft durch das VPN.	Höchste Sicherheit, zentrale Filterung	Höhere Bandbreitenlast, ggf. langsamer

Aufgabe 8

Logmeldung	Bedeutung	Ursache
`no proposal chosen`	Verschlüsselungsparameter stimmen nicht überein	Falsche Cipher, Hash oder DH-Gruppe
`peer not responding`	Gegenseite antwortet nicht	Firewall/NAT blockiert, IP falsch
`AUTH_FAILED`	Authentifizierung gescheitert	PSK falsch, Zertifikat ungültig, Benutzer fehlerhaft

Aufgabe 9

a) Vorteile OpenVPN gegenüber IPsec:

Einfache Einrichtung
Läuft über TCP/UDP-Port 443 → funktioniert hinter Firewalls
Zertifikatsbasierte Authentifizierung
Open-Source, gut auditierbar

b) Port: UDP 1194 (standardmäßig)
→ Vorteil: Kann auch auf 443 gelegt werden, um in gesperrten Netzwerken zu funktionieren.

c) Authentifizierung:
Per Zertifikaten (CA, Client, Server) und optional zusätzlichem Passwort / MFA.

Aufgabe 10

Richtige Reihenfolge:

(5) OpenVPN installieren
(4) PKI initialisieren
(1) Serverzertifikat erstellen
(2) Clientkonfiguration schreiben
(3) openvpn-Dienst starten
(6) Test der Verbindung

Aufgabe 11

Parameter	Bedeutung
`tls-version-min 1.3`	Erzwingt TLS 1.3 (modernste Verschlüsselung)
`verify-client-cert require`	Nur Clients mit gültigem Zertifikat dürfen sich verbinden
`user nobody`	Prozess läuft mit eingeschränkten Rechten
`persist-tun`	VPN-Tunnel bleibt beim Neustart erhalten
`remote-cert-tls client`	Server prüft, ob Zertifikat vom Typ „Client“ ist

Aufgabe 12

Umsetzungsschritte:

VPN-Clients erhalten IPs z. B. aus 10.8.0.0/24
Dieses Subnetz wird einem eigenen VLAN (VLAN50) zugewiesen
Firewallregel:
- Quelle: VLAN50
- Ziel: bestimmte Servergruppen (z. B. 192.168.10.50–60)
- Action: allow
- Default: deny
Optionale DNS- und DHCP-Anpassung für das VPN-VLAN
Überwachung per diag sniffer oder policy hits

Ergebnis: VPN-User sehen nur freigegebene Ressourcen.

Aufgabe 13

End-to-End-Verschlüsselung (E2EE):

Schlüsselerzeugung: Jeder Teilnehmer erstellt ein eigenes Schlüsselpaar (privat/öffentlich).
Schlüsselaustausch: Nur öffentliche Schlüssel werden getauscht.
Nachrichtenverschlüsselung: Jede Nachricht wird mit dem öffentlichen Schlüssel des Empfängers verschlüsselt.

→ Nur der Empfänger kann mit seinem privaten Schlüssel entschlüsseln.
Selbst wenn ein VPN-Gateway kompromittiert ist, bleiben Inhalte unlesbar,
da die Daten innerhalb des VPN-Tunnels zusätzlich verschlüsselt sind.

Aufgabe 14

Zertifikatserneuerung:

Ablaufdatum prüfen mit:

openssl x509 -in cert.crt -noout -enddate

Abgelaufene Zertifikate verhindern Tunnelaufbau → TLS handshake failure
Frühzeitige Erneuerung (30 Tage vorher) und Verteilen an alle Systeme nötig
Automatisierung möglich (z. B. über CRON, ACME, FortiManager)

Aufgabe 15

Best Practices:

Nur moderne Protokolle (IKEv2, TLS 1.3, AES-256) verwenden
MFA aktivieren (z. B. Token + Passwort)
VPN-Benutzer in eigenes VLAN mit restriktiven Policies
Zertifikate regelmäßig erneuern und CRLs prüfen
Logs und Monitoring aktiv nutzen (z. B. Alarm bei Auth_FAIL)
Split-Tunnel vermeiden, wenn nicht zwingend nötig
Software und Firmware aktuell halten
Zugangsdaten niemals teilen