Virtual console and serial — recovering OPNsense on Proxmox, VMware, and KVM

A virtual OPNsense has no physical serial port, no BMC, no IPMI. The console is a virtual console exposed by the virtualisation platform — Proxmox, VMware ESXi, KVM/QEMU, Hyper-V. The virtual console is the equivalent of the physical console for a VM: a direct text terminal to the FreeBSD kernel, independent of the VM’s network interfaces, routing, and firewall rules.

This lesson covers the virtual console path for OPNsense on the major virtualisation platforms, the OPNsense serial console settings for use with virtual serial ports, and the operator actions that recover from a hard lockout in a virtual environment.

The virtual console paths

Each virtualisation platform exposes a virtual console in its own way:

The console gives the operator a text terminal attached to the VM. The terminal shows the same boot loader, kernel boot, OPNsense menu, and root shell as a physical serial console. The operator types into the console as if they were at a physical keyboard.

The console path is independent of the VM’s network. If the VM’s network interfaces are down, the firewall rules are wrong, or the routing is broken, the console still works. The console is the recovery path that always works.

Proxmox VE console

Proxmox VE exposes two console types per VM:

• noVNC (HTML5). A JavaScript-based VNC client in the Proxmox UI. No Java required. Works in any modern browser. The console is accessed via the Proxmox UI: VM → Console. The console window opens in the browser.
• xterm.js. A JavaScript-based serial console. Used when the VM’s display is configured as “serial terminal” rather than “VGA”. Accessed via the same VM → Console menu.

For OPNsense, the default display is VGA. The noVNC console is the standard. The OPNsense menu and shell appear in the noVNC window.

$ qm terminal 100

Starting terminal on VM 100...
Connected.

OPNsense 25.7.3 ...
...

root@opnsense:~ #

The Proxmox console works as long as the Proxmox host is reachable. The Proxmox host’s network and authentication are separate from the VM’s network and authentication. The operator who has Proxmox access can reach the VM console regardless of the VM’s firewall state.

VMware ESXi console

VMware ESXi exposes the VMRC (VMware Remote Console) for each VM. The VMRC is a downloadable application (not a web app) that connects to the ESXi host and provides a console window. The console window shows the VM’s display.

VMRC is installed on the operator’s workstation. The operator connects to the ESXi host (or vCenter) and opens the VMRC for the affected VM. The console window opens, and the operator sees the OPNsense menu and shell.

ESXi also exposes a web-based console for VMs that have the VMware Tools installed and the VM’s display set to “Use browser-based console”. The browser-based console is HTML5 and works in any modern browser.

KVM/QEMU console

KVM/QEMU exposes the console via virt-manager (GUI), virt-viewer (GUI), or qm terminal (CLI). The console is a VNC session to the QEMU emulator.

The operator connects via:

• virt-viewer <vm-name> opens a VNC window to the VM. Requires X11 forwarding or a local desktop.
• virt-manager is a GUI for managing KVM VMs. The console is opened from the VM’s menu.
• virsh console <vm-name> opens a serial console to the VM. Requires the VM’s display to be configured as “serial terminal” rather than “VGA”.

The KVM/QEMU console works as long as the KVM host is reachable. The host’s network is separate from the VM’s network.

OPNsense serial console settings

OPNsense can be configured to use a serial console as the primary console (instead of VGA). The serial console is useful for headless installations, for KVM/QEMU VMs configured with serial display, and for embedding OPNsense in environments where VGA is not available.

The serial console settings are configured during installation:

• The installer prompts for the console type. Select “Serial console” for headless installations.
• The serial settings are 115200 baud, 8N1.
• The kernel boot loader is redirected to the serial port.

After installation, the serial console settings can be changed via the OPNsense menu (option 2: Set up console parameters) or by editing /boot/loader.conf.local to set console="comconsole" and comconsole_speed="115200".

$ grep -E 'console|comconsole' /boot/loader.conf.local

console="comconsole"
comconsole_speed="115200"
comconsole_port="0x3F8"

For KVM/QEMU VMs, the serial port is exposed as a UNIX socket or TCP port on the host. The operator connects with virsh console <vm> or a telnet/socat session.

For VMware VMs, the serial port can be mapped to a host-side file or pipe. The operator connects via the VMware VMRC’s serial console option.

For Proxmox VMs, the serial port is exposed as a UNIX socket in /var/run/qemu-server/<vmid>.serial0. The operator connects with qm terminal <vmid>.

Differences from physical serial

The virtual serial console is functionally equivalent to the physical serial console, with three differences:

1. No cable. The virtual serial port is software, not hardware. There is no cable to check, no baud rate mismatch (the virtual port is software-emulated). The connection “just works” once the VM is configured.
2. No BMC SOL. A virtual serial port does not have an IPMI SOL equivalent. The operator connects via the virtualisation platform’s console mechanism, not via a separate management network.
3. Platform dependency. The virtual serial console depends on the virtualisation platform being reachable. If the platform is down (hardware failure, network partition), the console is unreachable. The physical console is reachable as long as the appliance has power.

The platform dependency is the biggest difference. A physical serial console works even when the management network is down. A virtual serial console works only when the virtualisation platform is reachable. For a multi-host virtualisation cluster, the operator should verify console access from each host in the cluster.

Recovering from a hard lockout in a VM

The recovery procedure is identical to the physical console procedure:

1. Connect to the virtual console (noVNC, VMRC, virt-manager, qm terminal).
2. Reboot the VM and select option 3 (single user).
3. Mount the configuration partition: mount -a.
4. Edit /conf/config.xml or run opnsense-password.
5. Reboot into normal mode.
6. Verify GUI, SSH, rules, configuration.

The only difference is step 1 — the connection mechanism is the virtualisation platform’s console, not a serial cable or BMC.

Verification

After any virtual console recovery, verify:

1. The GUI is reachable from a known-good source IP.
2. SSH works with the new password or key.
3. The VM’s network interfaces are up (ifconfig from the console).
4. The firewall rules are correct (pfctl -s rules from the console).
5. The configuration matches the expected state.
6. The virtual console itself still works (close and reopen the console).

The last verification is often skipped but is essential. The operator who closes the console without re-opening it cannot verify the console still works after the recovery. The disciplined move is to close the console, open it again, and confirm the boot menu or login prompt appears.

Summary

• The virtual console is the recovery path that always works for VMs. It does not depend on the VM’s network or firewall rules.
• Each platform exposes the console differently: Proxmox noVNC/qm terminal, VMware VMRC/browser console, KVM virt-manager/virsh console.
• OPNsense’s serial console can be configured to use a virtual serial port instead of VGA. Useful for headless VMs and KVM/QEMU with serial display.
• The virtual serial console is equivalent to the physical serial console, with three differences: no cable, no BMC SOL, and platform dependency.
• Verify the virtual console during provisioning, not during the incident.