Has configurado ACLs y NAT decenas de veces en Packet Tracer. Has visto converger OSPF. Has roto un Spanning Tree y lo has arreglado hasta que el diagrama dejó de parpadear. Y todo eso pasaba dentro de un simulador, con tráfico que nunca existió.
El salto siguiente es obvio aunque ninguna certificación te lo exija: llevar esas configuraciones a hardware real, con tráfico real y con las consecuencias reales de meter la pata. Lo que ha cambiado es el precio de entrada. Ya no hace falta un rack ni una factura de la luz de tres cifras: un mini PC con dos puertos 2.5G, un hipervisor por debajo y el consumo de una bombilla te da router, firewall y laboratorio en la misma caja, funcionando todo el año.
Te explico por qué la vía virtualizada es la sensata, qué hardware necesitas de verdad y dónde están las trampas.
- Por qué un mini PC y no el router del operador
- Por qué Proxmox por debajo y no bare-metal
- pfSense u OPNsense
- Requisitos reales de hardware
- Modelos que encajan: GEEKOM A7 Max, A8 Max y A9 Max
- Instalación: los pasos que importan
- Consumo, ruido y el factor 24/7
- Cuando no está enrutando
- ¿Y si prefieres bare-metal?
- Conclusión
Por qué un mini PC y no el router del operador
El equipo que te instaló el operador está diseñado para no dar problemas. Lo cual, traducido, significa que no te deja hacer nada interesante. Reglas de firewall propias, ninguna. IDS/IPS, tampoco. El soporte de VLAN suele ser testimonial cuando no directamente inexistente, y toda la visibilidad del tráfico que te ofrece es una lista de dispositivos conectados.
Un x86 cambia eso por completo. Sistema completo, throughput real, Suricata o pfBlockerNG si te apetece, y las métricas que quieras exportar a donde quieras. Es un x86 de verdad, no un electrodoméstico con el firmware cerrado a cal y canto.
Ahora bien: ocho núcleos enrutando un gigabit es un desperdicio absurdo. Un firewall doméstico, aun con IDS activo, apenas roza esa CPU. Y de ahí sale la idea entera de este montaje. Si la máquina va a estar encendida 24/7, que haga algo más que mover paquetes.
Por qué Proxmox por debajo y no bare-metal
Aquí está la decisión que lo condiciona todo, así que voy despacio. Mi recomendación: Proxmox VE sobre el hierro, OPNsense como máquina virtual. Tres razones, por orden de peso.
El driver de red. OPNsense y pfSense corren sobre FreeBSD. Y casi todos los mini PC del mercado (los modelos que menciono luego incluidos) montan controladoras Realtek RTL8125 en sus puertos 2.5G. La relación entre FreeBSD y ese chip lleva años siendo complicada. El re(4) del kernel reconoce la tarjeta, sí, pero en cuanto empujas a 2.5 Gbps empiezan el throughput inconsistente, los watchdog timeouts y la pérdida de paquetes bajo carga. Proxmox va sobre kernel Linux, donde el soporte de r8125 es maduro y aburrido, que es como debe ser un driver. Y lo importante viene ahora: OPNsense, dentro de la VM, no ve ningún Realtek. Ve una tarjeta VirtIO. El problema no se parchea, se evapora.
Snapshots. Un snapshot antes de tocar una regla. Si dejas la casa sin Internet a las once de la noche, treinta segundos y estás de vuelta. En un entorno de aprendizaje eso no es una comodidad, es medio camino andado.
Una máquina, varios roles. Al lado de OPNsense caben GNS3 o EVE-NG, un Pi-hole, un Zabbix, contenedores, el servidor que necesites para el laboratorio de esta semana.
¿Y el precio a pagar? Existe, y no voy a ocultarlo. El hipervisor está en el camino de los datos: si Proxmox cae, la red cae con él, y cada actualización del host es un corte de Internet en casa. VirtIO añade una sobrecarga de CPU pequeña, pero real. Y sumas una capa de complejidad que hay que saber administrar. A cambio: estabilidad de driver, snapshots y una máquina que rinde por tres. A mí me sale a cuenta. Tú verás.
Aviso, y este es importante: no hagas passthrough PCIe de las NIC a la VM de OPNsense. Media docena de tutoriales te lo van a recomendar por defecto, y aquí es justo lo contrario de lo que quieres. Al pasar la tarjeta directa, FreeBSD vuelve a ver el Realtek y te comes otra vez el problema que habías esquivado. VirtIO no es una limitación del montaje. Es el montaje.
pfSense u OPNsense
Los dos descienden de m0n0wall, los dos corren sobre FreeBSD y los dos funcionan bien en este esquema. Dicho lo cual, no son idénticos.
pfSense CE tiene el ecosistema más maduro y muchísima más documentación, y su nomenclatura se parece más a lo que te vas a encontrar en un entorno corporativo. Si quieres que lo aprendido te suene familiar en una entrevista de trabajo, es una apuesta razonable.
OPNsense saca versiones con mucha más frecuencia, la interfaz está a años luz de la de pfSense y el sistema de plugins está bastante vivo (ahí vive os-realtek-re, del que hablo al final). Aquí uso OPNsense. Pero por debajo de VirtIO la diferencia práctica es mínima, así que elige el que prefieras administrar y no le des más vueltas.
Requisitos reales de hardware
| Escenario | CPU | RAM | Almacenamiento |
|---|---|---|---|
| Solo OPNsense en VM (<1 Gbps) | 4 núcleos | 8 GB | 128 GB |
| + Suricata IDS/IPS + pfBlockerNG | 6 núcleos | 16 GB | 256 GB NVMe |
| + GNS3/EVE-NG, Docker, más VMs | 8+ núcleos | 32–64 GB | 512 GB+ NVMe |
La CPU no es el cuello de botella del enrutado, por mucho que la tabla dé esa impresión. Cualquier procesador moderno mueve un gigabit sin enterarse. Lo que se come los núcleos de verdad es la inspección profunda de paquetes, o sea Suricata con un ruleset amplio, y el cifrado de las VPN. Sobre esto último: los Ryzen actuales llevan AES-NI, así que WireGuard e IPsec van acelerados por hardware y no dependen de la fuerza bruta del chip.
La barrera real es la RAM. Proxmox con ZFS quiere lo suyo, la VM de OPNsense pide 4 GB para estar cómoda, y a partir de ahí cada laboratorio suma. Con 16 GB vas justito en cuanto levantes un EVE-NG con cuatro routers virtuales. Los 32 GB son el punto donde el montaje deja de dar guerra.
Y dos puertos bastan. Uno a la WAN, otro a la LAN en trunk, y las VLANs las manejas con router-on-a-stick contra tu switch gestionable, igual que en los laboratorios que ya has hecho. Nadie necesita seis puertos para aprender.
Modelos que encajan: GEEKOM A7 Max, A8 Max y A9 Max
Al terreno concreto. Los tres modelos de la serie Max de GEEKOM cubren los tres escenarios de la tabla y comparten lo que aquí importa: doble puerto 2.5G, plataforma Ryzen con AES-NI y sitio para 32 GB o más de RAM. Son los candidatos naturales para este montaje.
El A7 Max es el punto de entrada sensato: rendimiento de sobremesa en un chasis de aluminio del tamaño de la palma de la mano, pensado para disipar bajo carga sostenida. En una máquina que no se apaga nunca, eso no es una frase de folleto: es la diferencia entre un equipo que aguanta agosto y uno que hace throttling a las tres de la tarde.
El A8 Max entra en juego si vas a activar Suricata con un ruleset serio y pfBlockerNG con varias listas: el margen de CPU frente al escenario básico se nota en cuanto enciendes la inspección profunda.
El A9 Max tiene sentido cuando la máquina va a ser tu homelab entero y no solo tu router: le sobra CPU para IA local, edición de vídeo y multitarea pesada. En este caso concreto la traducción es sencilla: OPNsense se va a comer el 10 % de esa máquina. El 90 % restante queda libre para EVE-NG, contenedores y lo que se te ocurra.
Dos detalles más, de esos que pesan cuando el equipo va a funcionar de forma permanente. Uno: tres años de garantía, frente a los dos años estándar del mercado. Dos: el ruido. Son equipos silenciosos en tareas de productividad, con los ventiladores activándose solo cuando hace falta, cosa que agradeces cuando tu “armario de comunicaciones” es en realidad una balda del salón.
Instalación: los pasos que importan
No voy a reproducir un tutorial completo, que para eso está la documentación oficial y es buena. Solo los puntos donde se decide si esto funciona o no.
En la BIOS: fuera Secure Boot, dentro SVM/AMD-V. Y no, no necesitas IOMMU. Precisamente porque no voy a hacer passthrough.
Proxmox, instalación estándar. Si te vas a ZFS, reserva RAM para el ARC; con 16 GB o menos, ext4 te va a dar menos disgustos.
Red: dos bridges. vmbr0 sobre el puerto físico que va a la WAN, vmbr1 sobre el de la LAN. Sin IP en vmbr0.
La VM de OPNsense: 2–4 vCPU, 4 GB de RAM, disco de 32 GB. Y aquí el paso crítico de todo el artículo, así que léelo dos veces: el modelo de las dos tarjetas de red tiene que ser VirtIO. Si dejas el E1000 que viene por defecto, pierdes rendimiento a cambio de nada; la documentación oficial de Proxmox VE mide hasta el triple de throughput con VirtIO frente a un E1000 emulado.
Primer arranque, asignas interfaces en el wizard, revisas las reglas por defecto, configuras DHCP y DNS. Un consejo que no es técnico pero vale su peso: monta y prueba todo esto en paralelo a tu red actual antes de ponerlo en producción. Dejar sin Internet a toda la casa un domingo por la tarde es una lección que solo se aprende una vez.
Consumo, ruido y el factor 24/7
Una máquina encendida todo el año no se juzga por su pico de rendimiento, sino por lo que hace cuando no hace nada. Un mini PC de esta gama enrutando tráfico doméstico anda por los 15–25 W. Una torre reciclada como router por software, entre 80 y 150 W. Con la luz en torno a los 0,17 €/kWh eso son unos 25–35 € al año contra 120–220 €. El ahorro frente a la torre ronda los 100-185 € al año, y en julio no te convierte el despacho en un radiador.
Cuando no está enrutando
Mucha gente llega aquí buscando un router y acaba dándose cuenta de que ha comprado otra cosa.
Si eres estudiante el argumento es directo: la misma caja que enruta tu red compila tu código y levanta tus prácticas, y cabe en la mochila si te toca llevártela a un examen presencial. Es una estación de trabajo completa, no un dispositivo para solo navegar.
En uso profesional cumple para el día a día —teletrabajo, videollamadas, multitarea y doble pantalla vía USB4/Thunderbolt 4— sin quejarse.
¿Y si el router acaba yendo a otro sitio y esta máquina se te queda en el escritorio? Tampoco pasa nada. La Radeon 780M del A7 Max mueve 1080p e incluso 1440p sin drama, y admite eGPU por si un día quieres mover juegos más exigentes.
¿Y si prefieres bare-metal?
Se puede. Sería tramposo no contarlo.
Instalando OPNsense directo sobre el hierro vas a tener que pelearte con el Realtek. El plugin os-realtek-re mete el driver del fabricante en lugar del re(4) del kernel (en pfSense el equivalente es realtek-re-kmod), y normalmente hay que desactivar también las descargas por hardware, LRO y TSO, para que el enlace se comporte. Con eso, la mayoría de la gente consigue un enlace estable.
Lo que pierdes: snapshots, la posibilidad de compartir la máquina con el resto del laboratorio, y quedas atado a que el driver del fabricante siga al día con cada actualización del sistema. Opción válida. No es la que recomiendo.
El soporte de FreeBSD para Realtek ha ido mejorando versión a versión, así que antes de decidir nada consulta el estado actual en las release notes de la versión que vayas a instalar. Esto se mueve rápido.
Conclusión
De Packet Tracer al hardware real hay un salto que ninguna certificación te obliga a dar y que probablemente sea el que más enseña. Poner OPNsense delante de tu propia conexión, con tu tráfico y tus reglas, convierte conceptos que sabías recitar en cosas que sabes hacer. No es lo mismo. Ni de lejos.
Y cuando acabes el CCNA la máquina va a seguir ahí, virtualizando, enrutando y esperando el siguiente laboratorio. Que ya es más de lo que puede decirse del router del operador.
