OPNsense VLAN Routing: 6 Best Practices for SMB Networks

A flat /24 network was acceptable ten years ago — today it is an audit finding. Cyber insurers, NIS-2 and basic risk management demand cleanly segmented networks where a compromised printer cannot become a stepping stone to the domain controller. OPNsense 25.7, a FreeBSD-based firewall, ships every tool you need to centrally and transparently manage VLANs, DHCP, DNS and firewall rules — provided the design is right from the start.

In this article we share six best practices we routinely deploy in OPNsense projects for SMBs across Bavaria and Southern Germany. This is not theory — these are concrete configurations that pass audits and work in daily operations.

1. Strictly isolate the management VLAN

The most common mistake in legacy networks: switches, access points, UPS units and iLO cards live in the same VLAN as office clients. A single infected employee laptop can then see the entire infrastructure. Set up a dedicated VLAN — typically VLAN 10 — exclusively for management interfaces.

Concretely this means:

• Dedicated IP range, e.g. 10.10.10.0/24
• Access only via jump host or explicit admin workstation
• No DHCP, only static reservations
• Logging of all connections via OPNsense Suricata

In OPNsense, create the VLAN under Interfaces > Other Types > VLAN, assign it to a physical port and label the firewall interface with a meaningful alias such as MGMT. A floating rule block log quick from any to MGMT_net as the first rule prevents accidental access from other VLANs — exceptions are explicitly allowed above it.

2. DHCP per VLAN — with Option 43 for VoIP

Each VLAN gets its own DHCP scope. Since version 24.7, OPNsense uses Kea as a modern DHCP server that can be configured granularly per interface. For VoIP VLANs (typically VLAN 20), DHCP Option 43 is critical so that phones from Snom, Yealink or Gigaset Pro can automatically locate their provisioning URL.

VLAN	Purpose	Subnet	DHCP Range	Notes
10	Management	10.10.10.0/24	none	Static
20	VoIP	10.10.20.0/24	.50-.200	Option 43, dedicated DNS
30	Clients	10.10.30.0/24	.50-.250	Standard
40	Servers	10.10.40.0/24	none	Static
50	IoT	10.10.50.0/24	.50-.250	Internet-only
60	Guests	10.10.60.0/24	.50-.250	Captive portal

Option 43 can be set in Kea via a custom option, for example for Snom phones pointing to the provisioning URL of an Auerswald or 3CX PBX:

option-data:
  - name: vendor-encapsulated-options
    code: 43
    data: "https://pbx.company.local/provisioning/{mac}.xml"

3. Inter-VLAN firewall: default deny, explicit allow

The biggest security gain comes from consistent default-deny rules between all VLANs. By default OPNsense allows all outbound traffic on an interface — that is the first thing you change.

Recommended approach per VLAN interface:

1. Rule 1: Allow DNS to OPNsense (port 53 TCP/UDP)
2. Rule 2: Allow DHCP to OPNsense (port 67/68)
3. Rule 3: Allow explicit target networks, e.g. VoIP -> PBX server
4. Last rule: block log from VLAN_net to any

Aliases keep rule sets readable. Define RFC1918, PBX_HOSTS, BACKUP_TARGETS and reference these instead of individual IPs. For larger environments, zone-based rule templates via Floating Rules are worthwhile so you do not have to maintain the same rules on every interface.

4. MAC tracking against shadow devices

In legacy networks, new devices appear constantly — private laptops, smart TVs in meeting rooms, unplanned printers. With the OPNsense plugin os-net-mgmt and Kea DHCP logs, you automatically identify unknown MAC addresses.

In practice:

• Kea DHCP logs every lease to /var/log/dhcpd/
• A cron job compares MACs against a whitelist (CSV or LDAP export)
• Unknown devices automatically land in a quarantine VLAN (e.g. VLAN 99)
• Notification to IT via email or webhook

For environments with higher compliance requirements, we additionally recommend 802.1X with FreeRADIUS on the switches. This enables port-based authentication — an unknown device never gets a link in the first place.

5. DNS per VLAN with Unbound views

Unbound, the DNS resolver integrated in OPNsense, has supported views for a long time — different answers depending on the source network. This is invaluable: server-VLAN clients receive internal IPs for the domain controllers, while guest-VLAN clients only get public answers.

Example configuration in /usr/local/etc/unbound.opnsense.d/views.conf:

access-control-view: 10.10.40.0/24 internal
access-control-view: 10.10.60.0/24 guest

view:
  name: "internal"
  local-zone: "company.local" transparent
  local-data: "dc01.company.local. IN A 10.10.40.10"

view:
  name: "guest"
  local-zone: "company.local" refuse

This ensures that internal hostnames are never resolved from the guest Wi-Fi — a classic reconnaissance roadblock. Combined with DNS-over-TLS forwarding to Quad9 or Cloudflare, you also close DNS leaks.

6. IoT VLAN: internet only, nothing else

Smart heating, printers with cloud connectivity, conference room projectors, access control systems — the IoT world is a security nightmare because firmware often goes unpatched for years. The protection concept is simple: IoT devices may only reach the internet, never the LAN.

Rule set for VLAN 50 (IoT):

pass in on IOT proto udp from IOT_net to OPNsense port 53
pass in on IOT proto udp from IOT_net to OPNsense port 67
pass in on IOT proto { tcp udp } from IOT_net to !RFC1918 any
block in log on IOT from IOT_net to any

The magic is !RFC1918 — any traffic into private networks is blocked. IoT devices reach their cloud, but neither servers nor clients. For multicast discovery (such as AirPlay, Chromecast) between office and IoT VLAN, use the os-mdns-repeater plugin instead of opening firewall rules.

Field experience: small steps, big impact

In most SMB projects we roll out these six practices in stages — not all at once. Typical roadmap:

1. Separate management VLAN (quick win, week 1)
2. Move server VLAN out of the client network (week 2)
3. Set up VoIP VLAN including QoS (week 3)
4. Activate IoT and guest VLAN (week 4)
5. Unbound views and DHCP optimisation (week 5-6)

Important: take a backup of the OPNsense configuration before each step and roll out during the maintenance window. OPNsense provides versioned history under System > Configuration > Backups, which can be rolled back at any time.

How DATAZONE supports you

We plan and operate OPNsense clusters for SMBs across Bavaria and Southern Germany — from single-site setups to multi-location solutions with a WireGuard mesh. We analyse your current network, design a fitting VLAN scheme and handle the migration during live operation. Find more information on our pages for OPNsense consulting and Linux infrastructure. Get in touch via datazone.de/en/contact — we look forward to your project.