Qué es y para qué sirve: En VirtualBox el networking conecta máquinas virtuales (VM) entre sí, con el host y con la red física; elegir el modo adecuado afecta visibilidad, seguridad y facilidad de acceso. En este guía verás, de forma práctica y comparativa, los modos de red VirtualBox principales (NAT, NAT Network, Bridged/puente, Host‑only e Internal) y cuándo usar cada uno, con comandos verificados y soluciones a errores comunes. Nota: he verificado el comportamiento y comandos contra el manual de VirtualBox (serie 7.x) el 1 de octubre de 2026.
Resumen rápido (one‑liner)
- NAT (clásico): VM tiene salida a Internet a través del host pero no es accesible desde la LAN; dirección por defecto en NAT clásico: 10.0.2.15 (guest), gateway 10.0.2.2.
- NAT Network: NAT compartido entre varias VMs (DHCP común, comunicación interna entre VMs, port‑forward centralizado).
- Bridged / Puente: la VM actúa como otro equipo en la LAN física (IP del mismo rango que el host; accesible por otros equipos).
- Host‑only: red privada entre host y VMs (host tiene interfaz vboxnetX); sin acceso a Internet salvo que se configure enrutamiento/NAT adicional.
- Internal (red interna): red aislada entre VMs; no se crea interfaz en el host, útil para laboratorios cerrados.
NAT (modo por defecto)
Qué hace y comportamiento por defecto
Es el modo por defecto al crear una VM: VirtualBox crea un router virtual que da a la VM una IP en 10.0.x.0/24 (cuando solo hay una instancia, el guest suele recibir 10.0.2.15) y proporciona salida a Internet a través de la pila TCP/IP del host. La VM puede iniciar conexiones salientes (HTTP, etc.) pero no es directamente accesible desde la LAN ni desde el host por defecto.
Ventajas y limitaciones
- Ventajas: configuración cero, seguridad por aislamiento, ideal para navegar o pruebas que requieren Internet sin exponer servicios.
- Limitaciones: servicios del guest (SSH, HTTP) no son accesibles desde la LAN ni el host salvo que uses port‑forwarding; no sirve para que otros equipos de la red local hablen directamente con la VM.
Port forwarding (ejemplo práctico)
Usa VBoxManage para exponer puertos concretos del guest en el host. Sintaxis típica (real y verificada):
VBoxManage modifyvm "Mi_VM" --natpf1 "guestssh,tcp,,2222,,22"
Significado: crea una regla llamada guestssh que reenvía TCP desde el puerto 2222 del host al puerto 22 del guest en la interfaz NAT (adapter 1). Para borrar la regla:
VBoxManage modifyvm "Mi_VM" --natpf1 delete guestssh
Comprobación: desde el host o cualquier equipo que alcance al host, prueba ssh -p 2222 usuario@IP_host. Si no funciona, revisa el firewall del host y la IP/puerto del guest.
Cuándo usar NAT
- VMs que sólo necesitan acceso a Internet sin ser visibles externamente.
- Desarrollo o testing donde sólo interesa exponer puertos concretos.
NAT Network
Diferencias vs NAT clásico
NAT Network crea un servicio NAT compartido (como un router virtual) que puede conectar varias VMs entre sí con DHCP común y permitir port‑forwarding gestionado centralmente. A diferencia del NAT por interfaz, NAT Network permite que las VMs se vean entre ellas sin exponerlas a la LAN externa.
Comandos útiles y ejemplo de creación
Ejemplo mínimo para crear y arrancar una NAT Network llamada natlab con DHCP activado:
VBoxManage natnetwork add --netname natlab --network "192.168.15.0/24" --enable --dhcp on
VBoxManage natnetwork start --netname natlab
Adjuntar la VM al NAT Network se puede hacer desde la GUI (Settings → Network → Attached to: «NAT Network» → elegir natlab) o con VBoxManage (ej.:
VBoxManage modifyvm "Mi_VM" --nic1 natnetwork --nat-network1 natlab
Regla de port‑forward a nivel de NAT Network:
VBoxManage natnetwork modify --netname natlab --port-forward-4 "ssh:tcp:[]:2201:[192.168.15.10]:22"
# Para borrar:
VBoxManage natnetwork modify --netname natlab --port-forward-4 delete ssh
Cuándo usar NAT Network
- Laboratorios con varias VMs que deben comunicarse entre sí y salir a Internet sin ser visibles en la LAN del host.
- Escenarios donde quieres port‑forward centralizado y DHCP para un conjunto de VMs.
Bridged (puente)
Qué hace
La interfaz virtual de la VM se ‘puentea’ con la interfaz física del host: la VM obtiene una IP del mismo rango que la LAN física (por DHCP del router o IP estática) y es visible para otros equipos de la red física como si fuera una máquina física adicional.
Ventajas y riesgos
- Ventajas: servicios en la VM (RDP, servidores web, SMB) son accesibles directamente desde la red local; útil para pruebas de red realistas.
- Riesgos: la VM queda expuesta a la red local (y a Internet si la red lo permite). No recomendar para VMs no confiables. Además, algunos adaptadores físicos o VPNs en el host pueden impedir o limitar el bridging (controladores, políticas corporativas o adaptadores virtuales creados por clientes VPN pueden bloquear el paso de tramas).
Casos de uso recomendados
- Servicios que deben ser publicados a la LAN (servidores de pruebas, máquinas accesibles por RDP desde otros equipos).
- Simulación de entornos de producción cuando necesitas IPs reales en el mismo segmento.
Host‑only
Qué hace
Crea una red privada entre host y VMs. El host recibe una interfaz virtual (vboxnetX) y las VMs se conectan a esa red; por defecto no hay acceso a Internet salvo que el host haga NAT/encaminamiento adicional.
Ventajas
- Comunicación directa y segura host ↔ VM y VM ↔ VM sin que la LAN vea el tráfico.
- Útil para debugging, testing de servicios que sólo deben estar disponibles desde el host, o para crear entornos donde el tráfico no salga a la red externa.
Comandos básicos
# Crear interfaz host-only
VBoxManage hostonlyif create
# Listar interfaces host-only
VBoxManage list hostonlyifs
# Asignar IP a la interfaz vboxnet0 (ejemplo)
VBoxManage hostonlyif ipconfig vboxnet0 --ip 192.168.56.1 --netmask 255.255.255.0
# Añadir servidor DHCP sobre la interface
VBoxManage dhcpserver add --ifname vboxnet0 --server-ip 192.168.56.100 --netmask 255.255.255.0 --lower-ip 192.168.56.101 --upper-ip 192.168.56.254 --enable
Comprobación: desde el host haz ping a la IP del guest (o desde el guest a la IP del host) y asegúrate de que el firewall del host permite el tráfico en la interfaz vboxnetX.
Limitación típica
Si la interfaz host‑only no aparece en la GUI, puede ser que no exista o que el instalador de VirtualBox no haya creado los controladores; en Windows revisa «Host Network Manager» (File → Host Network Manager) y en Linux inspecciona con VBoxManage list hostonlyifs. Errores E_FAIL suelen indicar permisos o conflictos con software de red (VPN, firewall, controladores).
Red interna (Internal)
Es la opción más aislada: sólo permite comunicación entre VMs conectadas a la misma red interna. No se crea interfaz en el host, por tanto el host no participa a menos que uses una VM gateway o configures un puente manual. Ideal para laboratorios, pruebas de red y entornos que deben permanecer totalmente aislados.
Recomendaciones de seguridad y casos prácticos
- Para laboratorio aislado: usa Internal o Host‑only y habilita servicios solo dentro del segmento.
- Si solo necesitas salida a Internet y exponer unos pocos servicios: NAT + port‑forwarding.
- Si la VM debe ofrecer servicios a la LAN (RDP, servidor web): Bridged, con cuidado de parches y firewall.
- Para múltiples VMs que hablan entre sí y necesitan DHCP: NAT Network.
Errores comunes y soluciones
- Port‑forward no responde: comprueba que la regla existe (VBoxManage showvminfo), que el servicio escucha en el guest, y que el firewall del host permite el puerto.
- Bridged no obtiene IP: revisa que el adaptador físico soporta bridge y no esté bloqueado por una VPN; prueba a seleccionar otro adaptador en la lista de puente.
- Host‑only no aparece: crea interfaz con
VBoxManage hostonlyif createy configura IP; revisa permisos del instalador y reinicia el servicio de VirtualBox si es necesario.
Precaución: eliminar o modificar redes (natnetwork remove, natnetwork modify –disable) puede afectar VMs en producción. Antes de borrar redes, apaga las VMs o verifica dependencias.
Enlaces prácticos internos
Guía paso a paso para red interna: Cómo configurar una red interna en VirtualBox paso a paso. Si necesitas conectar por Escritorio Remoto dentro de la misma red, consulta: Conectarse por Escritorio Remoto a un Equipo de la misma Red.
Verificación rápida paso a paso (práctica)
- Comprueba la versión y disponibilidad de VBoxManage:
VBoxManage --version. - Si usas NAT clásico: arranca la VM y dentro comprueba IP:
ip addr/ipconfig— deberías ver 10.0.2.15 (salvo configuración distinta). - Si usas NAT Network: crea/start con
VBoxManage natnetwork add/start, adjunta la VM y verificaVBoxManage list natnetworksy la IP del guest. - Para host‑only: crea interfaz y DHCP, arranca guest y comprueba ping entre host y guest.
Preguntas frecuentes (breve)
- ¿Puedo tener varias tarjetas de red con modos distintos? Sí; una VM puede tener múltiples adaptadores (ej.: uno bridged para LAN y otro host‑only para administración).
- ¿Cómo evito que una VM bridged acceda a Internet? Usa reglas de firewall en la VM o en el router, o conecta la VM a una red interna/host‑only y levanta un gateway controlado si necesitas acceso selectivo.
Si quieres, puedo generar ejemplos concretos ajustados a tu caso (número de VMs, si necesitas RDP/SSH, o si tu host corre Windows/Linux/macOS) y entregarte los comandos exactos paso a paso para configurar y verificar la red.
