Peplink 8.6.0 Sicherheit: FIPS, RadSec, WireGuard und was sich geändert hat

TL;DR: Peplink Firmware 8.6.0 bringt einen substanziellen Sicherheitssprung: Permanentes FIPS 140-3 direkt in der lokalen UI — ohne aktiven Care Plan —, RadSec für RADIUS over TLS über öffentliche Netze, WireGuard als moderner Remote-Access-VPN-Standard auf allen Modellen, eine konsequente Zertifikats-Modernisierung und das Schließen von drei kritischen Schwachstellen inklusive CVE-2026-42945. Für CISOs und IT-Security-Teams regulierter Branchen ist dieses Release ein Pflichtupgrade.

Einleitung

Sicherheit in der Netzwerkinfrastruktur ist kein Zustand, sondern ein kontinuierlicher Prozess. Peplink Firmware 8.6.0, veröffentlicht am 29. Juli 2026, zieht eine klare Linie: Statt einzelner punktualer Verbesserungen liefert dieses Release ein kohärentes Sicherheitspaket, das von kryptografischen Standards über Authentifizierungsprotokolle bis hin zu konkreten Schwachstellenbehebungen reicht. Im Mittelpunkt steht das Keyword Peplink FIPS RadSec — die Kombination aus permanentem FIPS 140-3-Betrieb und RadSec (RADIUS over TLS), die insbesondere für Organisationen mit regulatorischen Compliance-Anforderungen einen messbaren Fortschritt darstellt.

Für CISOs und IT-Security-Teams bedeutet 8.6.0, dass langjährige operative Hürden entfallen: Der FIPS-Betrieb lässt sich nun dauerhaft in der lokalen Benutzeroberfläche aktivieren. RadSec sichert RADIUS-Authentifizierungsverkehr auf dem Weg über öffentliche Netze ab. WireGuard ergänzt die VPN-Optionen um ein modernes, auditierbares Protokoll mit schlankem Codebase-Footprint. Und drei geschlossene Schwachstellen — darunter ein unauthentifizierter Web-Admin-Zugang — beseitigen Angriffsflächen, die in Penetrationstests wiederholt aufgefallen wären.

Dieser Artikel beleuchtet jede Änderung aus der Perspektive von Sicherheitsverantwortlichen: Was ändert sich technisch, welche Konfigurationspflichten entstehen beim Upgrade, und welche Risiken werden durch das Update gemindert? Alle Angaben basieren auf den offiziellen Peplink-Release-Notes und wurden durch Ascends Peplink-zertifizierte Ingenieure validiert.

1. Permanentes FIPS 140-3 — kein Care Plan nötig

Was sich ändert

Laut Peplinks offizieller Firmware-8.6.0-Seite wird FIPS mit 8.6.0 zu einer permanenten, in die lokale Benutzeroberfläche integrierten Funktion für berechtigte Geräte: FIPS 140-3 lässt sich dauerhaft in der lokalen UI aktivieren — ohne aktiven Care Plan. Hinweis: Peplink University und andere Sekundärquellen sprechen noch von FIPS 140-2; maßgeblich ist die Angabe des Herstellers.

Technische Details

• Die FIPS-Aktivierung erfolgt direkt in der lokalen Web-UI unter den Sicherheitseinstellungen. InControl 2 spiegelt den Status, der Schalter selbst liegt aber auf dem Gerät.
• Welche Geräte berechtigt sind, listet Peplink pro Serie in den offiziellen Release Notes; die Liste sollte vor dem Upgrade konkret geprüft werden.
• Wenn FIPS aktiviert ist, gelten verschärfte Anforderungen an IPsec-Konfigurationen: Preshared Keys (PSK) müssen mindestens 14 Zeichen lang sein. Laut Release-Notes können bestehende IPsec-Profile mit kürzeren PSKs nach dem Upgrade unter Umständen keine Verbindung mehr aufbauen, bis die Keys aktualisiert sind.
• Neu hinzugekommen ist zudem SHA2-384 als Hash-Algorithmus für IPsec Phase 2, was die Integritätssicherung der Tunnelverhandlungen auf ein höheres Niveau hebt.

Handlungsempfehlung vor dem Upgrade

1. PSK-Audit durchführen: Vor dem Upgrade auf 8.6.0 alle IPsec-Preshared-Keys prüfen. Kürzer als 14 Zeichen? Vor dem Upgrade austauschen, sonst bricht der Tunnel.
2. Service-Vertrag prüfen: Die FIPS-Funktion selbst ist an keinen aktiven Care Plan gebunden; welchen Anspruch Ihr Gerät auf Software-Updates hat, richtet sich nach Ihrem Peplink-Service-Vertrag.
3. FIPS-Status dokumentieren: Nach dem Upgrade den FIPS-Modus in der lokalen UI aktivieren und den Status für Audit-Zwecke dokumentieren.

Hinweis für PrimeCare-Geräte: InControl muss aktiviert bleiben, um Software-Feature-Updates zu empfangen. FIPS läuft zwar ohne Care Plan dauerhaft, die Feature-Auslieferung erfolgt aber über InControl.

2. RadSec — RADIUS over TLS für WLAN-Authentifizierung

Warum RadSec relevant ist

RADIUS ist das Standardprotokoll zur Authentifizierung in WLAN-Umgebungen — von Enterprise-WPA2/WPA3-802.1X bis zu Guest-Portalen. In seiner klassischen Form überträgt RADIUS Authentifizierungsdaten unverschlüsselt. Solange RADIUS-Server und Access Points im selben geschützten Netzsegment stehen, ist das vertretbar. Sobald der Authentifizierungsverkehr aber öffentliche Netze passiert — etwa bei verteilten Filialen, Cloud-RADIUS-Diensten oder über MPLS-Verbindungen mehrerer Provider —, entsteht eine reale Angriffsfläche: Credentials, Challenge-Response-Tokens und Session-Keys sind abhörbar.

RadSec löst dieses Problem, indem es den gesamten RADIUS-Verkehr in ein TLS-Tunnel einpackt. Authentifizierung, Autorisierung und Accounting (AAA) laufen über einen verschlüsselten Kanal, der zusätzlich mit Zertifikaten gegenseitig authentifiziert wird. Peplink 8.6.0 bringt native RadSec-Unterstützung auf einer breiten Palette von Modellen.

Unterstützte Modelle

RadSec ist verfügbar auf: Balance 20X, 310 Fiber 5G, 310 5G HW3, allen Dome- und MBX-Modellen, allen UBR-Modellen, dem Großteil der BR-Serie, sowie allen Transit-, Orbit- und B-One-Modellen. Die genaue Modellmatrix steht in den Release-Notes.

Konfigurationsschritte

1. RADIUS-Server für RadSec vorbereiten: Der Ziel-RADIUS-Server muss RadSec (RFC 6614) unterstützen — FreeRADIUS, Microsoft NPS mit RadSec-Gateway oder Cloud-RADIUS-Anbieter wie CloudPath.
2. Zertifikate im Peplink Certificate Manager hinterlegen: Sowohl das Client-Zertifikat des Peplink-Routers als auch das CA-Zertifikat des RADIUS-Servers müssen importiert werden.
3. RadSec als Authentication Profile konfigurieren: Dort lässt sich RadSec als Authentifizierungsprotokoll wählen; als Port ist typischerweise 2083 hinterlegt (klassisches RADIUS nutzt 1812).
4. WLAN-APs auf das neue Profil umstellen: Im AP Controller das Authentifizierungsprofil dem entsprechenden SSID-Profil zuweisen.

Praxisbeispiel: Filialnetz mit Cloud-RADIUS

Ein Unternehmen betreibt 40 Filialen, jede mit einem Peplink Balance und mehreren Wi-Fi APs. Die RADIUS-Authentifizierung läuft zentral über einen Cloud-RADIUS-Dienst. Bisher war der RADIUS-Verkehr zwischen Filialen und Cloud ungeschützt oder erforderte ein vorgelagertes VPN. Mit RadSec in 8.6.0 genügt ein TLS-Tunnel — konfiguriert im Peplink Certificate Manager —, und die Authentifizierung ist End-to-End verschlüsselt. Das reduziert die Komplexität und eliminiert eine Attack Surface, die bei verteilten Deployments sonst oft ungelöst bleibt.

3. WireGuard VPN — moderner Remote Access

Was WireGuard von OpenVPN und IPsec unterscheidet

WireGuard ist mit Firmware 8.6.0 auf allen Peplink-Modellen als Remote-User-Access-VPN verfügbar. Es positioniert sich neben den bestehenden Optionen (OpenVPN, L2TP, PPTP) — nicht als Ersatz, sondern als moderne Alternative mit spezifischen Vorteilen:

• Codebase-Größe: WireGuard rund 4.000 Zeilen, OpenVPN-Stacks im Bereich von 100.000 Zeilen und mehr — weniger Code, kleinere Angriffsfläche.
• Verbindungsaufbau: WireGuard baut in Bruchteilen der Zeit auf, die klassische Protokolle benötigen.
• Handover bei Netzwechsel: WireGuard bleibt nahtlos bestehen; bei OpenVPN bricht die Session in der Regel ab.
• Kryptografie: WireGuard mit fest verdrahtetem ChaCha20 + Poly1305; IPsec konfigurierbar (mit FIPS u. a. SHA2-384).
• Auditierbarkeit: Dank kleiner Codebase hoch; komplexe Stacks sind aufwendiger zu auditieren.

Warum das für CISOs wichtig ist

• Minimalangriffsfläche: Die Codebase von WireGuard ist rund 25× kleiner als die von OpenVPN. Das bedeutet weniger potenzielle Schwachstellen, schnellere Sicherheits-Audits und einfachere Zertifizierungsprozesse.
• Mobilität: WireGuard erhält Sessions bei Wechsel der Netzwerkschnittstelle (z. B. WLAN → LTE). Für Remote-Mitarbeiter im Feld oder im Außendienst bedeutet das keine abbrechenden VPN-Tunnel beim Netzwechsel — ein operatives Plus, das auch die Helpdesk-Ticketrate senkt.
• Starke Standard-Kryptografie: WireGuard verwendet fix ChaCha20 für Symmetrie und Poly1305 für MAC — keine konfigurierbaren, potenziell schwachen Cipher-Suiten.

Einsatzszenarien bei Peplink

WireGuard in 8.6.0 ist primär für Remote User Access konzipiert — also für den Zugriff einzelner Clients (Laptop, Smartphone, Peplink SFC-App) auf den Peplink-Router. Für Site-to-Site-Verbindungen zwischen Peplink-Geräten bleibt SpeedFusion die empfohlene Wahl, da es zusätzlichen WAN-Bonding und Failover bietet. SFC Direct Access (ebenfalls neu in 8.6.0) ergänzt WireGuard für Fälle, in denen eine direkte Peplink-to-Peplink-Verbindung ohne klassischen VPN-Tunnel benötigt wird.

Konfigurationshinweis

WireGuard wird im Peplink-Web-UI konfiguriert; pro Client wird ein Public/Private-Key-Paar generiert oder importiert. Die Peer-Verwaltung folgt dem bekannten WireGuard-Modell — kein X.509-Zertifikat-Overhead wie bei OpenVPN, dafür explizite Key-Verwaltung als Disziplin.

4. Zertifikats-Modernisierung — was nicht mehr unterstützt wird

Die Änderungen im Überblick

Firmware 8.6.0 nimmt eine konsequente Bereinigung der akzeptierten Zertifikatsformate vor. Folgende Typen werden nicht mehr akzeptiert:

• Zertifikatstyp: DSA (Digital Signature Algorithm) · Status vor 8.6.0: Akzeptiert · Status ab 8.6.0: Nicht mehr akzeptiert
• Zertifikatstyp: Kurze RSA-Keys · Status vor 8.6.0: Akzeptiert · Status ab 8.6.0: Nicht mehr akzeptiert
• Zertifikatstyp: Legacy PKCS#12-Container · Status vor 8.6.0: Akzeptiert · Status ab 8.6.0: Nicht mehr akzeptiert
• Zertifikatstyp: RSA ≥2048 Bit, ECDSA, Ed25519 · Status vor 8.6.0: Akzeptiert · Status ab 8.6.0: Akzeptiert (Standard)

Nicht mehr akzeptierte Zertifikate werden durch ein sicheres Default-Zertifikat ersetzt, das automatisch als Fallback dient. Der Betrieb bricht nicht — die Verschlüsselung läuft weiter, aber mit dem Default-Zertifikat statt mit einem abgelaufenen oder unsicheren Legacy-Zertifikat.

Warum das wichtig ist

• DSA gilt als veraltet. NIST empfiehlt die Migration zu ECDSA oder RSA ≥2048 (NIST SP 800-131A); das BSI zieht in seinen Vorgaben ebenfalls moderne Verfahren vor. Peplink folgt dieser Richtung mit der Zertifikats-Modernisierung.
• Kurze RSA-Keys gelten als unsicher (NIST SP 800-131A verlangt für digitale Signaturen mindestens 2048 Bit). In Penetrationstests und Compliance-Audits werden sie als Finding eingestuft. Welche RSA-Schlüssellängen Peplink in 8.6.0 konkret ablehnt, ist in den Release Notes nicht beziffert — prüfen Sie Ihre Zertifikate im Certificate Manager.
• Legacy PKCS#12-Container können veraltete Verschlüsselungs-Formate enthalten, die nicht mehr den aktuellen Standards entsprechen.

Upgrade-Pflicht: Certificate Manager prüfen

Vor dem Upgrade auf 8.6.0:

1. Im Peplink Certificate Manager alle importierten Zertifikate auflisten.
2. Jedes Zertifikat auf DSA oder ungewöhnlich kurze RSA-Schlüssel prüfen.
3. Betroffene Zertifikate durch neue RSA-2048+- oder ECDSA-Zertifikate ersetzen.

Nach dem Upgrade auf 8.6.0:

1. Certificate Manager erneut prüfen — betroffene Zertifikate werden durch das Default-Zertifikat ersetzt sein.
2. Wenn ein selbst signiertes Zertifikat für Management- oder VPN-Zwecke verwendet wurde, die Default-Ersatz-Zertifikate gegen eigene 2048+-Bit-Zertifikate austauschen.
3. Bei betroffenen TLS-Verbindungen (Synergy Mode, RadSec, Web-Admin) die Clients über den Zertifikatswechsel informieren, um Trust-Store-Pin-Probleme zu vermeiden.

Synergy Mode: 8.6.0 bringt ein dediziertes Fallback-Zertifikat für Synergy-TLS-Verbindungen. Auch hier gilt: vor dem Upgrade den Zertifikatsbestand prüfen.

5. CVE-Patches und Sicherheits-Fixes

CVE-2026-42945 — Web-Service-Komponente

Diese Schwachstelle betraf eine Komponente des Peplink-Web-Services. Peplink hat den Patch direkt in 8.6.0 ausgeliefert. Details zum genauen Vektor wurden von Peplink zurückhaltend kommuniziert — typische Praxis bei Network-Appliance-Herstellern, um Exploitation-Fenster klein zu halten. Was CISOs wissen müssen: Der Patch liegt erst ab 8.6.0 vor — ein zeitnahes Upgrade ist dringend angeraten.

CLI Command Injection — geschlossen

Eine Command-Injection-Schwachstelle in der CLI wurde geschlossen. Command-Injection-Schwachstellen erlauben Angreifern die Ausführung beliebiger Befehle mit den Privilegien des CLI-Prozesses — in der Regel Administrations-Level. Die Attack Surface setzt einen authentifizierten CLI-Zugang voraus, aber das Risiko bleibt kritisch: Vertikale Privilege Escalation und vollständige Geräte-Kontrolle sind möglich. Der Patch schließt die injizierbare Eingabeverarbeitung ab.

Web Admin — unauthentifizierter Zugriff geschlossen

Die schwerwiegendste der drei geschlossenen Schwachstellen: Ein unauthentifizierter Zugriff auf die Web-Admin-Oberfläche war möglich. Das bedeutet: ein Angreifer ohne Credentials konnte administrativ relevante Funktionen oder Informationen erreichen. Details zum genauen Umfang wurden nicht vollständig offengelegt, aber die Kategorie allein — unauthentifizierter Admin-Zugang — rechtfertigt die Einstufung als kritisch und macht das Upgrade zur Priorität.

Wi-Fi AP Defaults auf WPA2/WPA3 Personal

Eine unterschätzte Änderung mit großer Wirkung: Neue Wi-Fi Access Points werden ab 8.6.0 per Default mit WPA2/WPA3 Personal konfiguriert — nicht mehr mit dem veralteten WPA oder gar Open-Modus. Das ist besonders relevant, weil Default-Konfigurationen in der Praxis oft tagelang oder dauerhaft unangetastet bleiben. Mit WPA3 als Default-Option sinkt das Risiko von Angriffen auf veraltete WLAN-Verschlüsselung deutlich.

Zusammenfassung der Sicherheits-Fixes

• Schwachstelle: Web-Service-Komponente · Kategorie: Service-Schwachstelle · CVE: CVE-2026-42945 · Behoben in: 8.6.0
• Schwachstelle: CLI Command Injection · Kategorie: Auth. Command Injection · CVE: — · Behoben in: 8.6.0
• Schwachstelle: Web Admin unauth. Zugriff · Kategorie: Unauth. Admin Access · CVE: — · Behoben in: 8.6.0
• Schwachstelle: Wi-Fi AP Defaults · Kategorie: Schwache Default-Konfig · CVE: — · Behoben in: 8.6.0

Fazit

Peplink Firmware 8.6.0 ist aus Security-Sicht ein zentrales Release. Die Kombination aus Peplink FIPS RadSec — permanentem FIPS 140-3 ohne Care Plan-Bindung und RadSec für RADIUS over TLS —, WireGuard als modernem VPN-Standard, konsequenter Zertifikats-Modernisierung und dem Schließen von drei kritischen Schwachstellen ergibt ein kohärentes Sicherheitspaket, das keinen Aspekt der Network-Appliance-Ebene auslässt.

Für CISOs und IT-Security-Teams in regulierten Branchen — Behörden, Gesundheitswesen, Finanzwesen, kritische Infrastruktur — ist dieses Upgrade kein „nice to have", sondern eine Compliance- und Risikomanagement-Pflicht. Die drei geschlossenen Schwachstellen allein rechtfertigen ein zeitnahes Upgrade; FIPS, RadSec und WireGuard sind der darüber hinausgehende Mehrwert.

Handlungsempfehlung: Prüfen Sie Ihre Peplink-Geräte auf Upgrade-Bereitschaft (PSK-Länge, Zertifikate, Staged-Upgrade für bestimmte Modelle), planen Sie ein Wartungsfenster, und führen Sie das Upgrade durch. Ascend als Peplink Gold Partner unterstützt Sie bei der Planung, beim PSK- und Zertifikats-Audit und beim Rollout.

Nächster Schritt: Kontaktieren Sie Ascend für ein Upgrade-Beratungsgespräch — wir prüfen Ihre Peplink-Flotte auf 8.6.0-Bereitschaft, identifizieren betroffene Zertifikate und Preshared Keys, und planen den Rollout mit Ihnen.

FAQ

1. Was bedeutet „permanentes FIPS 140-3 ohne Care Plan"?

Laut Peplinks offizieller Firmware-8.6.0-Seite wird FIPS mit 8.6.0 zu einer permanenten, in die lokale UI integrierten Funktion für berechtigte Geräte — die Sorge, dass FIPS-Betrieb von einer aktiven Care-Plan-Lizenz abhängt, entfällt damit. Ab Firmware 8.6.0 lässt sich FIPS 140-3 dauerhaft in der lokalen Benutzeroberfläche aktivieren (Sekundärquellen nennen zum Teil noch FIPS 140-2; maßgeblich ist der Hersteller).

2. Was ist RadSec und wann brauche ich es?

RadSec (RADIUS over TLS, RFC 6614) verschlüsselt den gesamten RADIUS-Authentifizierungsverkehr in einem TLS-Tunnel. Es ist relevant, sobald RADIUS-Verkehr öffentliche Netze passiert — bei verteilten Filialen mit Cloud-RADIUS, bei Guest-Portalen mit externem Authentifizierungsdienst oder bei MPLS-übergreifenden Setups. Wenn RADIUS-Server und Access Points im selben geschützten LAN-Segment stehen, ist klassisches RADIUS weiterhin vertretbar.

3. Warum sollten Preshared Keys ab 8.6.0 mindestens 14 Zeichen lang sein?

Wenn der FIPS-Modus aktiviert ist, fordert 8.6.0 Preshared Keys (PSK) mit mindestens 14 Zeichen für IPsec und Remote User Access. Kürzere PSKs werden beim Aktivieren von FIPS abgewiesen; bestehende IPsec-Tunnel mit kurzen PSKs können nach dem Upgrade auf 8.6.0 unter Umständen nicht mehr aufgebaut werden, bis die Keys aktualisiert sind.

4. Ist WireGuard in 8.6.0 ein Ersatz für SpeedFusion?

Nein. WireGuard in 8.6.0 ist primär für Remote User Access konzipiert — den Zugriff einzelner Clients auf den Peplink-Router. Für Site-to-Site-Verbindungen zwischen Peplink-Geräten bleibt SpeedFusion die empfohlene Wahl, da es zusätzlich WAN-Bonding und Failover bietet. WireGuard ergänzt die VPN-Optionen, es ersetzt keine bestehende Technologie.

5. Welche Zertifikate werden ab Firmware 8.6.0 nicht mehr akzeptiert?

DSA-basierte Zertifikate, kurze RSA-Keys und Legacy-PKCS#12-Container werden ab 8.6.0 nicht mehr akzeptiert (Peplink nennt keine konkrete Bit-Grenze; als „kurz" gilt allgemein, was unterhalb üblicher 2048-Bit-Standards liegt).

AI-Disclosure: Dieser Artikel wurde mit KI-Unterstützung recherchiert und verfasst und vor der Veröffentlichung von Ascends Peplink-zertifizierten Ingenieuren geprüft.