Peplink 8.6.0 y la seguridad: FIPS, RadSec, WireGuard y todo lo que ha cambiado

La seguridad en la infraestructura de red no es un estado, sino un proceso continuo. Peplink Firmware 8.6.0, publicada el 29 de julio de 2026, traza una línea clara: en lugar de mejoras puntuales aisladas, esta versión entrega un paquete de seguridad coherente que abarca desde estándares criptográficos y protocolos de autenticación hasta la corrección concreta de vulnerabilidades. En el centro está la palabra clave Peplink FIPS RadSec: la combinación de la operación FIPS 140-3 permanente y RadSec (RADIUS over TLS), que representa un avance medible especialmente para organizaciones con requisitos de cumplimiento regulatorio.

Para los CISO y los equipos de seguridad TI, la 8.6.0 significa que desaparecen obstáculos operativos de larga data: la operación FIPS ahora se puede activar de forma permanente en la interfaz local de usuario. RadSec protege el tráfico de autenticación RADIUS a su paso por redes públicas. WireGuard complementa las opciones VPN con un protocolo moderno y auditable con una base de código compacta. Y tres vulnerabilidades cerradas, entre ellas un acceso no autenticado al Web Admin, eliminan superficies de ataque que habrían llamado la atención repetidamente en pruebas de penetración.

Este artículo examina cada cambio desde la perspectiva de los responsables de seguridad: ¿qué cambia técnicamente, qué obligaciones de configuración surgen con la actualización y qué riesgos mitiga la actualización? Todas las indicaciones se basan en las release notes oficiales de Peplink y fueron validadas por los ingenieros de Ascend certificados en Peplink.

Lo que cambia

Según la página oficial de la Firmware 8.6.0 de Peplink, con la 8.6.0 FIPS pasa a ser una función permanente, integrada en la interfaz local de usuario, para los dispositivos elegibles: FIPS 140-3 se puede activar de forma permanente en la interfaz local, sin un Care Plan activo. Nota: Peplink University y otras fuentes secundarias todavía hablan de FIPS 140-2; lo determinante es la indicación del fabricante.

Detalles técnicos

• La activación de FIPS se realiza directamente en la interfaz web local, en los ajustes de seguridad. InControl 2 refleja el estado, pero el interruptor está en el propio dispositivo.
• Qué dispositivos son elegibles lo lista Peplink por serie en las release notes oficiales; esta lista debería revisarse en concreto antes de la actualización.
• Con FIPS activado se aplican requisitos reforzados a las configuraciones IPsec: las Preshared Keys (PSK) deben tener al menos 14 caracteres. Según las release notes, los perfiles IPsec existentes con PSK más cortas podrían no establecer conexión tras la actualización hasta que las claves se actualicen.
• Además se ha incorporado SHA2-384 como algoritmo hash para la Fase 2 de IPsec, lo que eleva a un nivel superior la garantía de integridad de las negociaciones de túnel.

Recomendaciones antes de la actualización

1. Realizar una auditoría de PSK: antes de la actualización a la 8.6.0, revisar todas las Preshared Keys IPsec. ¿Más cortas de 14 caracteres? Sustituirlas antes de actualizar; de lo contrario, el túnel se rompe.
2. Revisar el contrato de servicio: la función FIPS en sí no está vinculada a un Care Plan activo; qué derecho a actualizaciones de software tiene su equipo se rige por su contrato de servicio Peplink.
3. Documentar el estado FIPS: tras la actualización, activar el modo FIPS en la interfaz local y documentar el estado con fines de auditoría.

Nota para dispositivos PrimeCare: InControl debe permanecer activado para recibir actualizaciones de funciones de software. FIPS funciona de forma permanente sin Care Plan, pero la entrega de funcionalidades se realiza a través de InControl.

Por qué RadSec es relevante

RADIUS es el protocolo estándar de autenticación en entornos WLAN, desde WPA2/WPA3-802.1X empresarial hasta portales de invitados. En su forma clásica, RADIUS transmite los datos de autenticación sin cifrar. Mientras el servidor RADIUS y los puntos de acceso estén en el mismo segmento de red protegido, esto es defendible. En cuanto el tráfico de autenticación atraviesa redes públicas, por ejemplo en sucursales distribuidas, servicios RADIUS en la nube o conexiones MPLS de varios operadores, surge una superficie de ataque real: credenciales, tokens de desafío-respuesta y claves de sesión pueden ser interceptados.

RadSec resuelve este problema encapsulando todo el tráfico RADIUS en un túnel TLS. Autenticación, autorización y accounting (AAA) transcurren por un canal cifrado que, además, se autentica mutuamente mediante certificados. Peplink 8.6.0 incorpora soporte nativo de RadSec en una amplia gama de modelos.

Modelos compatibles

RadSec está disponible en: Balance 20X, 310 Fiber 5G, 310 5G HW3, todos los modelos Dome y MBX, todos los modelos UBR, la mayor parte de la serie BR, así como todos los modelos Transit, Orbit y B One. La matriz exacta de modelos figura en las release notes.

Pasos de configuración

1. Preparar el servidor RADIUS para RadSec: el servidor RADIUS de destino debe soportar RadSec (RFC 6614) — FreeRADIUS, Microsoft NPS con gateway RadSec u operadores RADIUS en la nube como CloudPath.
2. Depositar los certificados en el Peplink Certificate Manager: tanto el certificado de cliente del router Peplink como el certificado de CA del servidor RADIUS deben importarse.
3. Configurar RadSec como perfil de autenticación: allí se puede elegir RadSec como protocolo de autenticación; como puerto se utiliza típicamente el 2083 (el RADIUS clásico usa el 1812).
4. Cambiar los AP WLAN al nuevo perfil: en el AP Controller, asignar el perfil de autenticación al perfil SSID correspondiente.

Caso práctico: red de sucursales con RADIUS en la nube

Una empresa opera 40 sucursales, cada una con un Peplink Balance y varios puntos de acceso Wi-Fi. La autenticación RADIUS se ejecuta centralizadamente a través de un servicio RADIUS en la nube. Hasta ahora, el tráfico RADIUS entre sucursales y nube estaba desprotegido o exigía un VPN previo. Con RadSec en la 8.6.0 basta un túnel TLS, configurado en el Peplink Certificate Manager, y la autenticación queda cifrada de extremo a extremo. Esto reduce la complejidad y elimina una superficie de ataque que en despliegues distribuidos suele quedar sin resolver.

Qué distingue a WireGuard de OpenVPN e IPsec

WireGuard está disponible con la Firmware 8.6.0 en todos los modelos Peplink como VPN de acceso de usuarios remotos. Se posiciona junto a las opciones existentes (OpenVPN, L2TP, PPTP), no como sustituto, sino como alternativa moderna con ventajas específicas:

• Tamaño de la base de código: WireGuard unas 4000 líneas, los stacks de OpenVPN del orden de 100 000 líneas y más: menos código, menor superficie de ataque.
• Establecimiento de conexión: WireGuard se establece en una fracción del tiempo que necesitan los protocolos clásicos.
• Handover al cambiar de red: WireGuard se mantiene sin interrupciones; con OpenVPN la sesión normalmente se interrumpe.
• Criptografía: WireGuard con ChaCha20 + Poly1305 fijos; IPsec configurable (con FIPS, entre otros, SHA2-384).
• Auditabilidad: alta gracias a la base de código pequeña; los stacks complejos son más costosos de auditar.

Por qué es importante para los CISO

• Superficie de ataque mínima: la base de código de WireGuard es unas 25 veces menor que la de OpenVPN. Esto significa menos vulnerabilidades potenciales, auditorías de seguridad más rápidas y procesos de certificación más sencillos.
• Movilidad: WireGuard mantiene las sesiones al cambiar de interfaz de red (p. ej., WLAN → LTE). Para empleados remotos en campo o en ruta significa que no hay túneles VPN que se corten al cambiar de red: una ventaja operativa que además reduce la tasa de tickets del helpdesk.
• Criptografía estándar robusta: WireGuard utiliza de forma fija ChaCha20 para el cifrado simétrico y Poly1305 para el MAC, sin suites de cifrado configurables y potencialmente débiles.

Escenarios de uso con Peplink

WireGuard en la 8.6.0 está concebido principalmente para Remote User Access, es decir, para el acceso de clientes individuales (portátil, smartphone, app Peplink SFC) al router Peplink. Para conexiones site-to-site entre dispositivos Peplink sigue siendo SpeedFusion la elección recomendada, ya que ofrece además WAN Bonding y failover. SFC Direct Access (también nuevo en la 8.6.0) complementa a WireGuard para los casos en los que se necesita una conexión directa Peplink a Peplink sin un túnel VPN clásico.

Nota de configuración

WireGuard se configura en la interfaz web de Peplink; por cada cliente se genera o importa un par de claves pública/privada. La gestión de peers sigue el modelo WireGuard conocido, sin la sobrecarga de certificados X.509 de OpenVPN, pero con la disciplina de una gestión explícita de claves.

Los cambios de un vistazo

La Firmware 8.6.0 realiza una limpieza consecuente de los formatos de certificado aceptados. Los siguientes tipos dejan de aceptarse:

• Tipo de certificado: DSA (Digital Signature Algorithm) · Estado antes de 8.6.0: aceptado · Estado desde 8.6.0: ya no aceptado
• Tipo de certificado: claves RSA cortas · Estado antes de 8.6.0: aceptado · Estado desde 8.6.0: ya no aceptado
• Tipo de certificado: contenedores PKCS#12 heredados · Estado antes de 8.6.0: aceptado · Estado desde 8.6.0: ya no aceptado
• Tipo de certificado: RSA ≥2048 bits, ECDSA, Ed25519 · Estado antes de 8.6.0: aceptado · Estado desde 8.6.0: aceptado (estándar)

Los certificados que dejan de aceptarse se sustituyen por un certificado predeterminado seguro que sirve automáticamente como fallback. La operación no se interrumpe: el cifrado continúa, pero con el certificado predeterminado en lugar de un certificado heredado caducado o inseguro.

Por qué es importante

• DSA se considera obsoleto. NIST recomienda migrar a ECDSA o RSA ≥2048 (NIST SP 800-131A); el BSI también prefiere métodos modernos en sus directrices. Peplink sigue esta dirección con la modernización de certificados.
• Las claves RSA cortas se consideran inseguras (NIST SP 800-131A exige para firmas digitales al menos 2048 bits). En pruebas de penetración y auditorías de cumplimiento se clasifican como hallazgo. Qué longitudes de clave RSA rechaza Peplink en concreto en la 8.6.0 no está cuantificado en las release notes: revise sus certificados en el Certificate Manager.
• Los contenedores PKCS#12 heredados pueden contener formatos de cifrado desactualizados que ya no cumplen los estándares actuales.

Obligación de revisión: comprobar el Certificate Manager

Antes de la actualización a la 8.6.0:

1. En el Peplink Certificate Manager, listar todos los certificados importados.
2. Revisar cada certificado por DSA o claves RSA inusualmente cortas.
3. Sustituir los certificados afectados por certificados RSA de 2048 bits o más, o ECDSA nuevos.

Tras la actualización a la 8.6.0:

1. Volver a revisar el Certificate Manager: los certificados afectados habrán sido sustituidos por el certificado predeterminado.
2. Si se utilizaba un certificado autofirmado para gestión o VPN, cambiar los certificados de reemplazo predeterminados por certificados propios de 2048 bits o más.
3. En las conexiones TLS afectadas (Synergy Mode, RadSec, Web Admin), informar a los clientes del cambio de certificado para evitar problemas de pinning del trust store.

Synergy Mode: la 8.6.0 incorpora un certificado de fallback dedicado para las conexiones TLS de Synergy. También aquí vale: revisar el inventario de certificados antes de la actualización.

CVE-2026-42945 — componente del servicio web

Esta vulnerabilidad afectaba a un componente del servicio web de Peplink. Peplink entregó el parche directamente en la 8.6.0. Los detalles del vector exacto fueron comunicados con cautela por Peplink, una práctica habitual entre fabricantes de appliances de red para mantener pequeña la ventana de explotación. Lo que deben saber los CISO: el parche solo existe a partir de la 8.6.0; una actualización temprana es urgentemente recomendable.

Inyección de comandos en la CLI — cerrada

Se cerró una vulnerabilidad de inyección de comandos en la CLI. Las vulnerabilidades de inyección de comandos permiten a los atacantes ejecutar comandos arbitrarios con los privilegios del proceso de la CLI, normalmente de nivel de administración. La superficie de ataque presupone un acceso CLI autenticado, pero el riesgo sigue siendo crítico: son posibles la escalada vertical de privilegios y el control total del dispositivo. El parche cierra el procesamiento de entrada inyectable.

Web Admin: acceso no autenticado cerrado

La más grave de las tres vulnerabilidades cerradas: era posible un acceso no autenticado a la interfaz de administración web. Eso significa que un atacante sin credenciales podía alcanzar funciones o información administrativamente relevantes. Los detalles del alcance exacto no se revelaron por completo, pero la categoría por sí sola —acceso de administración no autenticado— justifica la clasificación como crítica y convierte la actualización en una prioridad.

Valores predeterminados de los AP Wi-Fi en WPA2/WPA3 Personal

Un cambio subestimado con gran efecto: los nuevos puntos de acceso Wi-Fi se configuran desde la 8.6.0 de forma predeterminada con WPA2/WPA3 Personal, ya no con el obsoleto WPA ni siquiera en modo abierto. Esto es especialmente relevante porque las configuraciones predeterminadas en la práctica suelen quedar días o indefinidamente intactas. Con WPA3 como opción predeterminada, el riesgo de ataques contra el cifrado WLAN desactualizado disminuye notablemente.

Resumen de las correcciones de seguridad

• Vulnerabilidad: componente del servicio web · Categoría: vulnerabilidad de servicio · CVE: CVE-2026-42945 · Corregido en: 8.6.0
• Vulnerabilidad: inyección de comandos en la CLI · Categoría: inyección de comandos autenticada · CVE: — · Corregido en: 8.6.0
• Vulnerabilidad: acceso no autenticado al Web Admin · Categoría: acceso de administración no autenticado · CVE: — · Corregido en: 8.6.0
• Vulnerabilidad: valores predeterminados de los AP Wi-Fi · Categoría: configuración predeterminada débil · CVE: — · Corregido en: 8.6.0

Desde la perspectiva de la seguridad, Peplink Firmware 8.6.0 es una versión central. La combinación de Peplink FIPS RadSec (FIPS 140-3 permanente sin vinculación al Care Plan y RadSec para RADIUS over TLS), WireGuard como estándar VPN moderno, una modernización consecuente de certificados y el cierre de tres vulnerabilidades críticas produce un paquete de seguridad coherente que no omite ningún aspecto del nivel de appliance de red.

Para los CISO y los equipos de seguridad TI de sectores regulados —administraciones públicas, sanidad, finanzas, infraestructuras críticas— esta actualización no es un «nice to have», sino una obligación de cumplimiento y gestión de riesgos. Las tres vulnerabilidades cerradas justifican por sí solas una actualización temprana; FIPS, RadSec y WireGuard son el valor añadido que va más allá.

Recomendación de actuación: compruebe si sus dispositivos Peplink están listos para la actualización (longitud de PSK, certificados, actualización escalonada para determinados modelos), planifique una ventana de mantenimiento y realice la actualización. Ascend, como Peplink Gold Partner, le apoya en la planificación, en la auditoría de PSK y certificados y en el despliegue.

Siguiente paso: contacte con Ascend para una consulta de actualización: revisamos la preparación de su flota Peplink para la 8.6.0, identificamos los certificados y Preshared Keys afectados y planificamos el despliegue con usted.

Este artículo ha sido investigado y redactado con apoyo de inteligencia artificial y revisado antes de su publicación por los ingenieros de Ascend certificados en Peplink.