Lab: Install OPNsense and walk the initial wizard

This lab installs OPNsense onto a virtual machine and walks the initial wizard end to end. You will build a fresh install on a virtual disk, assign the WAN and LAN interfaces by deliberate choice (not auto-detection), set the management credentials, and verify that the web UI is reachable from the LAN side. The working state at the end of this lab is the baseline that every later lab in the OPNsense course assumes.

The wizard exists because the only way to recover a firewall that boots without a LAN address is the console. Every operator must be able to walk the wizard confidently, recognise the defaults that are wrong for production, and reach the dashboard on the first attempt.

Objective

By the end of this lab you can:

Install OPNsense from ISO to a virtual disk.
Run the initial wizard and choose the right WAN type for your environment.
Log in to the web UI from the LAN side over HTTPS.
Take a configuration backup that is the baseline for the rest of the course.

Requirements

A hypervisor (Proxmox VE, VMware ESXi, VirtualBox, or KVM) with at least 2 vCPU, 2 GB RAM, and 20 GB of disk provisioned for the OPNsense VM.
Two virtual NICs on the VM: one for WAN (attached to a upstream network with a working DHCP server or a known static prefix), one for LAN (a private internal-only segment).
The latest OPNsense dvd ISO from https://opnsense.org/download/.
A workstation on the LAN side with a browser that can reach https://192.168.1.1.

The WAN side of a lab does not need to be the public Internet. A nested upstream router providing DHCP is fine; the lab only needs to verify that the WAN interface obtains or accepts an address and the default route is present.

Tasks

Task 1: Boot the installer and install to the virtual disk

Boot the VM from the OPNsense ISO. At the loader menu accept the default boot. The installer starts:

1. Install (ZFS)
2. Install (UFS)
3. Install (CDN)

For a single-disk lab VM, choose Install (UFS). ZFS is the right choice for multi-disk production appliances, but a single vdisk on UFS is straightforward and matches what OPNsense expects on most hardware. Confirm the destination disk when prompted. The installer writes a GPT partition table, the FreeBSD bootloader, and the root filesystem.

When the installer reports success, eject the ISO and reboot when prompted.

Task 2: Assign the WAN and LAN interfaces deliberately

The first boot presents the interface assignment menu. OPNsense cannot guess which NIC is which — it lists the detected NICs and the operator must answer. The default assignment (first NIC = WAN, second NIC = LAN) is usually right, but the operator who does not check has wired the wrong ports more than once.

At the console:

Valid interfaces are:
    em0    52:54:00:12:34:56
    em1    52:54:00:12:34:57

Do you want to configure LAGGs/ VLANs now?  y/N

Answer N — VLANs come in a later lab. Then:

Enter the WAN interface name:  em0
Enter the LAN interface name:  em1

Confirm em0 and em1 are the correct listings. In nested virtualisation the MAC addresses are the giveaway: the NIC you attached to the WAN network on the hypervisor is the one with the WAN-side MAC.

Task 3: Walk the initial wizard

The console now prompts for the LAN address. The default 192.168.1.1/24 is acceptable for a lab. The wizard then launches on the LAN side; open https://192.168.1.1 from the LAN workstation and accept the self-signed certificate warning.

The wizard walks eight steps. Answer each one deliberately:

General: hostname (the production hostname, not opnsense), domain (the internal DNS zone).
Time zone: the operational zone, not the timezone of the operator’s laptop.
NTP: enter at least two reachable NTP sources. The default pool is fine for a lab.
WAN interface: type matches the upstream. For a lab this is almost always DHCP. For PPPoE, choose that and enter the credentials.
LAN interface: keep the default 192.168.1.1/24 unless the lab topology uses a different prefix.
Admin password: set a strong one and store it in the password manager. The default opnsense is a known credential.
Reload: the wizard applies the configuration and restarts the web server.

Task 4: Verify the WAN side has an address

From the console or an SSH session to the LAN address:

ifconfig em0 | grep inet
ifconfig em1 | grep inet
netstat -rn | head -10

The WAN interface should hold either the DHCP-assigned address or the static address configured in the wizard. The default route should point at the WAN-side gateway. If em0 shows 0.0.0.0, the upstream DHCP server is not on the segment you think it is — check the hypervisor’s network attachment.

Task 5: Verify the web UI and HTTPS

From the LAN workstation:

curl -skI https://192.168.1.1/ | head -5

A 200 OK (or 303 See Other to the login page) means the web server is reachable. A connection refused means the service is not listening or the LAN address is wrong. A routing loop means the LAN subnet is not what you think it is.

Task 6: Take a baseline configuration backup

The next lab changes rules. Capture the baseline first:

configctl backup download

The artifact is /conf/backup/config-OPNsense-<timestamp>.xml. Download it through the GUI (System → Configuration → Backups → Download) and store it as opnsense-baseline-pre-labs.xml. The file is the rollback target for every later lab.

Validation

The web UI is reachable at https://192.168.1.1 with the admin password you set, not the default.
ifconfig em0 shows a non-zero inet address on the WAN side.
netstat -rn shows a default route via the WAN gateway.
A configuration backup exists and is dated after the wizard completed.
The console reports no errors during the wizard.

Expected Result

You have a working OPNsense 25.x instance with WAN and LAN assigned, the initial wizard applied, and a configuration backup written. The WAN obtains an address from the upstream (or holds the static one); the LAN is reachable on 192.168.1.1/24; the web UI answers HTTPS from the LAN side. No rules have been changed from the OPNsense defaults.

Troubleshooting

em0 gets 0.0.0.0 on the WAN. The hypervisor is not attached to an upstream network with a DHCP server. Either attach the WAN NIC to a network that has a DHCP server (nested router, the host’s management network, or a flat lab network) or configure a static WAN address in the wizard.
Web UI is unreachable after the wizard. The LAN address or netmask is wrong. Reconnect on the console, choose option 2 (Set interface IP address) and re-enter the LAN details. Verify with ifconfig em1.
The wizard skips the reload. Some installations present a red “Apply” button at the end; clicking it reloads the services. Without it, the partial configuration is in place but the web server is still on the old IP.
https://192.168.1.1 is unreachable but the LAN IP is correct. Check the workstation’s default gateway. A host without 192.168.1.1 as its default route will not reach the firewall’s web UI.

Cleanup

The lab ends with the firewall in a known-good state. The baseline backup is the recovery target for the next lab.

# Confirm the backup is present
ls -la /conf/backup/

# Confirm the wizard applied (no half-applied config)
configctl webgui restart
pfctl -sr | head -3

The default ruleset installed by the wizard is permissive on LAN and restrictive on WAN. Treat it as “in service, not hardened” — the next lab replaces it.

What you learned

The initial wizard is the only recovery path for a firewall that loses its LAN address; you must be able to walk it confidently.
WAN and LAN assignment is a deliberate choice, not a default to accept. The MAC addresses and the hypervisor’s network attachments are the evidence.
A baseline configuration backup is the rollback target for every later lab. Take it before any change.
The wizard’s Reload step is the operational checkpoint; a half-applied wizard is a half-configured firewall.

Objectives

Prerequisites