Default-deny segmentation — design templates for production estates · OPNsense

A production estate has a small number of well-understood VLAN categories: management, users, servers, guest, IoT, DMZ, storage. Each category has a purpose, an addressing range, a default-deny posture, and a narrow set of permitted east-west flows. This lesson covers the templates for each category, the addressing allocations, and the design mistakes that undermine segmentation in practice.

The VLANs and their rules are not arbitrary. They are the result of repeated operational experience: certain kinds of hosts (IoT, guest) need to be isolated from certain other kinds (servers, management); certain services need to be reachable from certain sources (DNS from anywhere, NTP from anywhere, GUI only from management); and certain flows (user to server) need explicit permits.

The standard VLAN categories

A production estate typically has these VLANs:

VLAN	Purpose	Hosts	Default posture
Management	Firewall GUI, jump hosts, monitoring	Jump hosts, operator workstations	Highly restricted; source-restricted to operator IPs
Users	Employee workstations, laptops	Workstations, BYOD devices	Permit outbound Internet; restrict east-west
Servers	Internal services, application servers	App servers, internal APIs	Permit from users (where needed); restrict east-west
Guest	Guest WiFi, BYOD networks	Guest devices	Permit outbound Internet; deny all east-west including users
IoT	Smart devices, sensors, printers	Printers, sensors, smart TVs	Highly restricted; deny east-west to users, servers, management
DMZ	Public-facing services	Web, mail, DNS, reverse proxies	Permit from Internet; deny to LAN
Storage	Backup, NFS, iSCSI	Storage arrays, backup targets	Permit from servers (specific); deny all else
Voice	VoIP phones, video conferencing	Phones, conference systems	Permit to specific voice controllers

Not every estate has every VLAN. A small office may combine users and servers; a large enterprise may split servers into web, app, and database tiers. The categories are starting points; the operator adapts them to the estate.

Addressing allocation

A common production mistake: the operator allocates addressing ranges ad hoc, and two VLANs end up with overlapping subnets or with ranges that conflict with remote-site VPN ranges. The fix is to allocate ranges up front, document them, and reserve them.

A common production allocation using RFC 1918 space:

10.0.0.0/16       Site A
  10.0.0.0/24     Management
  10.0.1.0/24     Voice
  10.0.2.0/24     Users
  10.0.10.0/24    Servers — web/app tier
  10.0.20.0/24    Servers — database tier
  10.0.30.0/24    Storage
  10.0.40.0/24    IoT
  10.0.50.0/24    Guest
  10.0.100.0/24   DMZ
  10.0.200.0/24   Infrastructure (switches, APs, printers with management)

The allocation is documented in a network registry. Every new VLAN gets a range from this allocation. Ranges never overlap.

For multi-site estates, allocate a /16 or /20 per site:

10.0.0.0/16       Site A (with the above sub-allocation)
10.1.0.0/16       Site B
10.2.0.0/16       Site C

Site-to-site VPN ranges are reserved at the top of the /8 or in a separate /16 that does not overlap with any site.

Read-only / Safevlan routing table— The routing table showing the connected routes for every VLAN. Each VLAN's subnet is unique (no overlaps); each VLAN is reachable via its sub-interface on the firewall. The igb2_vlan10 entry indicates a different parent interface (igb2) for the DMZ VLAN — a common pattern where DMZ traffic is on a separate physical NIC for isolation.

$ netstat -rn | grep -E '^10\.' | sort

10.0.0.0/24       link#5             UC    igb1_vlan10
10.0.2.0/24       link#6             UC    igb1_vlan20
10.0.10.0/24      link#7             UC    igb1_vlan30
10.0.20.0/24      link#8             UC    igb1_vlan40
10.0.30.0/24      link#9             UC    igb1_vlan50
10.0.50.0/24      link#10            UC    igb1_vlan60
10.0.100.0/24     link#11            UC    igb2_vlan10

Illustrative output

The routing table confirms the design is implemented: every allocated subnet appears as a connected route on its VLAN sub-interface, with no overlaps.

The default-deny posture per VLAN

Every VLAN has a default-deny rule at the bottom of its rule set. The default-deny posture is the same for every VLAN: block everything that is not explicitly permitted. The differences between VLANs are in the explicit permits.

Management VLAN

The management VLAN’s ruleset is the most restrictive:

Order | Action | Source          | Destination    | Port     | Description
1     | pass   | mgmt_jumphosts  | firewall IP    | 80, 443  | GUI access from jump hosts
2     | pass   | mgmt_jumphosts  | firewall IP    | 22       | SSH from jump hosts
3     | pass   | mgmt_jumphosts  | firewall IP    | 53       | DNS for jump hosts
4     | pass   | monitor_server  | firewall IP    | 161      | SNMP monitoring (optional)
99    | block  | any             | any            | any      | Default deny

The management VLAN does not permit traffic to any other VLAN except by explicit rule. The jump hosts on the management VLAN initiate outbound traffic to other VLANs (for backups, configuration pulls, monitoring), and the destination VLAN’s rules permit those specific flows.

Users VLAN

The users VLAN’s ruleset permits outbound Internet and specific east-west:

Order | Action | Source          | Destination    | Port       | Description
1     | pass   | users_subnet    | dns_server     | 53         | DNS resolution
2     | pass   | users_subnet    | ntp_server     | 123        | NTP
3     | pass   | users_subnet    | web_app        | 443        | Internal web application
4     | pass   | users_subnet    | any            | any        | Outbound Internet (default LAN rule)
99    | block  | any             | any            | any        | Default deny (catches east-west not permitted above)

The default LAN rule (rule 4) permits users to the Internet. The default-deny at the bottom catches east-west to other VLANs (servers, storage, IoT) that are not explicitly permitted.

Servers VLAN

The servers VLAN’s ruleset is the most varied — different servers need different flows:

Order | Action | Source          | Destination    | Port       | Description
1     | pass   | dns_server      | any            | 53         | Recursive resolution
2     | pass   | ntp_server      | any            | 123        | NTP sync
3     | pass   | web_app         | postgres_db    | 5432       | Web app database
4     | pass   | monitor_agent   | any            | various     | Monitoring scrapes
99    | block  | any             | any            | any        | Default deny

The servers VLAN permits specific service dependencies. The default deny catches everything else, including direct user access to internal services that should go through the web app.

Guest VLAN

The guest VLAN’s ruleset is very restrictive:

Order | Action | Source          | Destination    | Port       | Description
1     | pass   | guest_subnet    | dns_server     | 53         | DNS resolution (optional, can be public DNS)
2     | pass   | guest_subnet    | any            | any        | Outbound Internet (with captive portal)
99    | block  | any             | any            | any        | Default deny (catches all east-west)

The guest VLAN permits outbound Internet only. East-west to any other VLAN is denied by default. The captive portal authenticates guests; rate limits prevent abuse.

IoT VLAN

The IoT VLAN’s ruleset is highly restrictive:

Order | Action | Source          | Destination    | Port       | Description
1     | pass   | iot_subnet      | dns_server     | 53         | DNS for IoT devices
2     | pass   | iot_subnet      | ntp_server     | 123        | NTP for IoT devices
3     | pass   | iot_subnet      | cloud_endpoint | 443        | Cloud control plane (specific IP)
99    | block  | any             | any            | any        | Default deny

The IoT VLAN permits only the specific flows IoT devices need: DNS, NTP, and the cloud control plane endpoint. Many IoT devices are best treated as “Internet-only” — let them reach the cloud, deny them access to internal services.

DMZ VLAN

The DMZ VLAN’s ruleset is covered in Part XV. The pattern:

Order | Action | Source          | Destination    | Port       | Description
1     | pass   | internet        | dmz_web        | 80, 443    | Internet to web servers
2     | pass   | dmz_web         | internet       | any        | Outbound (for updates, OCSP)
3     | block  | dmz_subnet      | lan_subnets    | any        | DMZ cannot reach LAN
4     | pass   | monitor_agent   | dmz_subnet     | various    | Monitoring
99    | block  | any             | any            | any        | Default deny

The DMZ permits inbound from the Internet (specific ports) and denies all east-west to LAN. Outbound from the DMZ to the Internet is permitted for updates and certificate validation.

Storage VLAN

The storage VLAN’s ruleset is narrow:

Order | Action | Source          | Destination    | Port       | Description
1     | pass   | backup_server   | storage_array  | 2049, 111  | NFS from backup server
2     | pass   | db_servers      | storage_array  | 2049       | NFS from database servers
3     | pass   | monitor_agent   | storage_array  | various    | Monitoring
99    | block  | any             | any            | any        | Default deny

The storage VLAN is reachable only from specific sources on specific ports. No user traffic, no guest traffic, no IoT traffic.

Read-only / Saferules per interface— The list of interfaces that have pass rules. Every VLAN has at least one pass rule (the default LAN rule for outbound Internet, the specific inter-VLAN rules, or the management GUI/SSH rule). The presence of a pass rule on each VLAN confirms that each VLAN has an explicit ruleset rather than relying on the default deny alone. A VLAN with no pass rules at all is reachable only from its own subnet and the firewall.

$ pfctl -s rules | awk '/pass in quick/ {for(i=1;i<=NF;i++) if($i~/^on$/) print $(i+1)}' | sort -u

igb1_vlan10
igb1_vlan20
igb1_vlan30
igb1_vlan40
igb1_vlan50
igb1_vlan60
igb2_vlan10

Illustrative output

The design mistakes

Three design mistakes undermine segmentation in practice.

Mistake 1: “Any” rules for convenience

The operator adds “any to any” rules to make things work, intending to come back later. The intent fades; the rule stays.

The fix: never write “any to any” except for the default deny. If a service is needed, write the specific rule for it. If the operator does not know what is needed, log first (with a match-only rule), then write the rule based on the evidence.

Mistake 2: Trusting the switch for segmentation

The operator assumes VLANs are segmented because they are on different VLANs. They are not — they are segmented only if inter-VLAN routing is denied. A “VLAN” without firewall rules is just a Layer 2 segment with a default route through the firewall.

The fix: every VLAN has a rule set. The rule set starts with a default deny. Specific permits are added as needed.

Mistake 3: Trusting DHCP for isolation

The operator assumes DHCP isolation (option 82, vendor classes, etc.) provides security. It does not. DHCP assigns IPs; it does not enforce firewall rules.

The fix: rely on firewall rules for isolation. Use DHCP for addressing only.

A complete template

A complete template for a small office (8 VLANs, single firewall, no HA):

VLAN 10 — Management     10.0.0.0/24    GUI/SSH, jump host
VLAN 20 — Voice          10.0.1.0/24    IP phones, video conferencing
VLAN 30 — Users          10.0.2.0/24    Workstations, BYOD
VLAN 40 — Servers Web    10.0.10.0/24   Internal web apps
VLAN 50 — Servers DB     10.0.20.0/24   Database servers
VLAN 60 — Storage        10.0.30.0/24   Backup, NFS
VLAN 70 — IoT            10.0.40.0/24   Printers, sensors
VLAN 80 — Guest          10.0.50.0/24   Guest WiFi
VLAN 100 — DMZ           10.0.100.0/24  Public services

The rulesets per VLAN follow the templates above. The default-deny at the bottom of each VLAN is the binding that prevents unauthorized east-west.

Summary

A production estate has a small number of well-understood VLAN categories: management, users, servers, guest, IoT, DMZ, storage, voice.
Addressing ranges are allocated up front and documented. Overlapping ranges break routing.
Every VLAN has a default-deny rule at the bottom of its rule set. The default-deny is the segmentation; the VLAN is an enabling mechanism.
The biggest mistakes are “any” rules, trusting the switch for segmentation, and trusting DHCP for isolation. None of those work.