Enterprise VLAN Segmentation with OPNsense on Hyper-V

 

Enterprise VLAN Segmentation with OPNsense on Hyper-V

From Flat Network to Fully Segmented, High-Availability Architecture

Executive Overview

Modern networks cannot afford to operate flat. Lateral movement, ransomware propagation, and credential harvesting thrive in environments where all systems share a broadcast domain.

This guide walks through:

  • Migrating from a flat network to VLAN segmentation

  • Deploying OPNsense on Hyper-V as a Layer 3 gateway

  • Implementing secure inter-VLAN firewall controls

  • Hardening the environment for production

  • Adding High Availability (CARP) for zero-downtime resilience

  • Operational readiness and lifecycle management

This is structured as a real-world deployment blueprint — suitable for SMB through enterprise environments.

Phase 1 – Understanding the Problem: The Flat Network

Most environments begin like this:

  • One subnet (e.g., 192.168.1.0/24)

  • One default gateway

  • All systems share the same broadcast domain

  • Firewall rules exist only at the WAN edge

Why This Is Dangerous

If one workstation becomes compromised:

  • It can scan all servers

  • It can attempt Kerberos/NTLM harvesting

  • It can reach management interfaces

  • It can move laterally without restriction

Flat networks maximize blast radius.

Segmentation reduces it.

Phase 2 – Designing the Segmentation Model

Before touching Hyper-V or OPNsense, design your VLAN structure intentionally.

Example Enterprise VLAN Layout

VLANPurposeSubnet
10Management10.10.10.0/24
20Servers10.10.20.0/24
30Workstations10.10.30.0/24
40Voice10.10.40.0/24
50IoT10.10.50.0/24
60Guest10.10.60.0/24

Design Principles

  • Management isolated from users

  • IoT isolated from servers

  • Guest Internet-only

  • Explicitly allow east-west traffic

  • Default deny between VLANs

Segmentation is not about VLAN creation — it is about policy enforcement.

Phase 3 – Hyper-V Network Foundation

OPNsense will act as:

  • Layer 3 gateway

  • Inter-VLAN router

  • Firewall enforcement point

But Hyper-V must pass VLAN tags correctly.

Step 1 – Create External Virtual Switch

Bind to a trunked physical NIC:

New-VMSwitch -Name "External-Trunk" -NetAdapterName "Ethernet" -AllowManagementOS $false

Requirements

  • Physical switch port must be trunk

  • Required VLAN IDs allowed

  • No native VLAN reliance (preferred)

Step 2 – Trunk OPNsense VM NIC

Hyper-V must pass VLAN tags to OPNsense.

Set-VMNetworkAdapterVlan -VMName "OPNsense" -Trunk -AllowedVlanIdList "10,20,30,40,50,60" -NativeVlanId 1

This allows OPNsense to receive 802.1Q tags.

Step 3 – Assign VLANs to Other VMs

Each workload VM receives an Access VLAN:

Set-VMNetworkAdapterVlan -VMName "SQL01" -Access -VlanId 20

Never trunk non-firewall VMs unless absolutely required.

Hyper-V Design Considerations

Important Limitations

  • Hyper-V VLAN handling is less flexible than VMware

  • Internal vSwitches do not behave like full enterprise switches

  • Trunk must terminate at OPNsense

Security Best Practices

  • Do not enable trunk mode on non-firewall VMs

  • Avoid native VLAN usage

  • Place Hyper-V management NIC in Management VLAN

  • Restrict WinRM and remote access

Phase 4 – OPNsense Base Installation

  1. Install OPNsense normally

  2. Assign:

    • WAN → Internet interface

    • LAN → Trunk interface

  3. Access GUI

  4. Run setup wizard

  5. Change admin password

  6. Configure WAN

At this point you have a single LAN interface.

Now we build segmentation.

Phase 5 – Creating VLAN Interfaces in OPNsense

Step 1 – Create VLANs

Navigate:

Interfaces → Other Types → VLAN

Create VLANs on parent LAN interface:

  • VLAN 10 (MGMT)

  • VLAN 20 (SERVERS)

  • VLAN 30 (USERS)

  • VLAN 40 (VOICE)

  • VLAN 50 (IOT)

  • VLAN 60 (GUEST)

Step 2 – Assign Interfaces

Interfaces → Assignments

Add and rename properly:

  • MGMT

  • SERVERS

  • USERS

  • VOICE

  • IOT

  • GUEST

Naming clarity matters long-term.

Step 3 – Assign Gateway IPs

Example:

VLANGateway
1010.10.10.1
2010.10.20.1
3010.10.30.1
5010.10.50.1
6010.10.60.1

These will later become CARP VIPs in HA.

Step 4 – Configure DHCP (Where Appropriate)

  • No DHCP for MGMT (static only)

  • Yes for Users

  • Yes for IoT

  • Yes for Guest

Phase 6 – Firewall Policy Architecture

Default stance:

Deny everything between VLANs.

Allow only what is required.

Required Aliases

Create:

  • RFC1918

  • MGMT_HOSTS

  • CORE_SERVERS

  • INFRA_SERVICES

Aliases make rules readable and enforceable.

Example Rule Structure

Guest VLAN

  • Allow DNS to firewall

  • Allow 80/443 to WAN

  • Block (log) RFC1918

Internet only.

IoT VLAN

  • Allow DNS/NTP

  • Allow WAN access

  • Block MGMT

  • Block SERVERS

  • Log all internal attempts

Workstation VLAN

  • Allow DNS/NTP

  • Allow specific ports to CORE_SERVERS

  • Allow WAN

  • Block MGMT

  • Block IoT

Management VLAN

  • Allow MGMT_HOSTS to all internal VLANs

  • Allow firewall GUI access

  • Block WAN (unless required)

Restrict GUI under:

System → Settings → Administration

Egress Filtering

Instead of “any to WAN”:

Allow:

  • 80/443

  • Required update ports

Block:

  • SMTP outbound

  • Unnecessary high-risk ports

Phase 7 – Performance Optimization

For enterprise deployments:

  • Use synthetic NICs only

  • 4+ vCPU minimum

  • 8–16 GB RAM recommended

  • Enable VMQ

  • Enable SR-IOV if supported

  • Disable Large Send Offload if using IDS

Monitor:

  • CPU

  • State table size

  • Interface drops

Phase 8 – High Availability (CARP on Hyper-V)

Production environments should not rely on a single firewall VM.

HA Architecture

Two Hyper-V hosts
Two OPNsense VMs
Dedicated SYNC network

Each VLAN has:

RoleIP
FW-A10.10.20.2
FW-B10.10.20.3
CARP VIP10.10.20.1

Clients use VIP as gateway.

Critical Hyper-V Requirement

Enable MAC spoofing:

Set-VMNetworkAdapter -VMName "OPNsense-A" -MacAddressSpoofing On

Without this, CARP will fail.

SYNC Network

Create dedicated internal vSwitch:

New-VMSwitch -Name "OPNsense-Sync" -SwitchType Internal

Used for:

  • pfsync

  • Config sync

Never route this network.

CARP Configuration

  1. Enable state + config sync

  2. Assign SYNC interface

  3. Create CARP VIPs per VLAN

  4. Set advskew:

    • Primary = 0

    • Secondary = 100

Failover Testing

Test:

  • Manual maintenance mode

  • Hard power-off

  • ARP refresh behavior

  • Session persistence

Phase 9 – Zero-Downtime Upgrade Strategy

  1. Upgrade BACKUP node first

  2. Validate sync

  3. Force failover

  4. Upgrade former primary

  5. Restore priority

Never upgrade both nodes simultaneously.

Always backup configs first.

Phase 10 – Troubleshooting Common CARP + Hyper-V Issues

CARP not becoming MASTER

→ Enable MAC spoofing.

Slow failover

→ Enable gratuitous ARP refresh.

States not syncing

→ Verify pfsync interface and firewall rules.

WAN CARP failing

→ ISP may block ARP spoofing.

Split-brain

→ Allow protocol 112 (CARP).

Phase 11 – Production Readiness Checklist

Infrastructure

☐ Two physical hosts
☐ UPS redundancy
☐ Switch redundancy
☐ Trunk parity confirmed

Networking

☐ Dedicated SYNC network
☐ VLAN documentation complete
☐ Outbound NAT uses CARP VIP

Security

☐ No “Allow Any Any” rules
☐ GUI restricted to MGMT
☐ IDS tested
☐ Logging enabled

HA

☐ Failover tested
☐ State sync verified
☐ Upgrade simulation completed

Monitoring

☐ SNMP enabled
☐ Alerts configured
☐ Syslog forwarding enabled

Final Architecture Outcome

You now have:

  • VLAN-segmented network

  • Controlled east-west traffic

  • Hyper-V optimized deployment

  • High-availability firewall layer

  • Zero-downtime upgrade capability

  • Production-grade operational controls

Flat networks are convenient.

Segmented, redundant, policy-driven networks are resilient.

Location: Orangeburg, SC 29115, USA

Comments

Post a Comment

Got something to say? Drop a comment below — let’s chat!

Popular posts from this blog

Building a Secure Virtual OPNsense 26.1 Firewall with VLANs, DMZ, and CARP High Availability

  Building a Secure Virtual OPNsense 26.1 Firewall with VLANs, DMZ, and CARP High Availability In this guide, we’ll walk through setting up OPNsense 26.1 as a primary gateway in a virtualized environment using Hyper-V , with VLAN segmentation, a DMZ, staged VPN, and optional CARP failover for high availability. This architecture ensures strong isolation, centralized traffic control, and enterprise-grade security — all without joining the firewall or hypervisor to Active Directory , reducing the attack surface. 1️⃣ Architecture Overview Logical Design Internet │ [External vSwitch] │ WAN (OPNsense) ┌──────────────────┐ │ OPNsense │ │ VLAN Gateways + HA│ └──────────────────┘ │ [Internal vSwitch - Trunk] │ ┌───────────────┬──────...
Read more

Proxmox VE + full Kubernetes (kubeadm) step-by-step

  Production-ready guide: Proxmox VE + full Kubernetes (kubeadm) step-by-step A practical, end-to-end walkthrough to deploy a hardened Proxmox VE environment and run a production-grade Kubernetes control plane and worker nodes (kubeadm). Includes HA control-plane, etcd considerations, load-balancing, networking (Calico), storage (Longhorn + option for Ceph), security hardening, backups, and monitoring. This blog assumes you have basic Linux + virtualization familiarity and a small cluster of physical servers for Proxmox (3+ nodes recommended for HA). Where choices exist I explain trade-offs and give concrete commands and config snippets you can copy. Outline Goals & prerequisites Logical architecture (ASCII diagram) Prepare Proxmox VE hosts (install & base hardening) Proxmox networking and storage planning Create cloud-init VM template for Kubernetes nodes Deploy VMs for Kubernetes control plane and workers Provision HA load balancer for kube-api (H...
Read more

Monitoring Virtualized Environments with Graylog: A Complete Guide

  Monitoring Virtualized Environments with Graylog: A Complete Guide Virtualization has become the backbone of modern datacenters, but as environments grow, so does the challenge of monitoring them effectively. Whether you’re running VMware vSphere, Hyper-V, Proxmox, KVM, Xen, or Nutanix , log visibility is essential for performance, capacity planning, and security. Graylog , with its flexible pipelines, dashboards, and alerting capabilities, provides a powerful centralized logging solution for virtualized infrastructures of all sizes. This guide walks through everything you need to know to monitor your virtual environment using Graylog—from collecting hypervisor logs to building dashboards and alerts that actually matter. Why Graylog for Virtualization Monitoring? Virtualization platforms all generate significant amounts of structured and unstructured log data: Host health VM lifecycle changes Storage access Virtual network changes Failovers and migrations ...
Read more