How to Implement Network Segmentation Without Enterprise Gear
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
A flat network: where every device can reach every other device without going through a firewall: is the attacker's ideal environment. Ransomware on a user workstation has direct line-of-sight to file servers, backup systems, domain controllers, and every printer and IoT device.
Network segmentation forces all traffic between zones through firewall-controlled chokepoints. A compromised workstation in the Users VLAN cannot directly reach servers in the Server VLAN: it must traverse the firewall, which is logging the attempt and can be configured to block it.
Designing Your Zone Architecture
Before configuring anything, decide what zones you need. Start with four:
Zone 1: Users (VLAN 10: 192.168.10.0/24) Employee workstations, laptops, and desktops. This is the highest-risk zone: users click phishing links, install unapproved software, and connect external devices. Traffic from Users to Servers should be restricted to specific permitted services.
Zone 2: Servers (VLAN 20: 192.168.20.0/24) File servers, database servers, application servers, domain controllers. This zone should be inaccessible except for specific approved services (SMB file sharing from Users, database port from application servers).
Zone 3: IoT and Printers (VLAN 30: 192.168.30.0/24) Printers, IP cameras, smart TVs, VoIP phones, building management systems. These devices have poor security posture, rarely receive patches, and should have no ability to initiate connections to workstations or servers: only respond to specific queries.
Zone 4: Management (VLAN 99: 192.168.99.0/24) Network equipment management interfaces (switch management, AP management), server out-of-band management (IPMI/iDRAC), and the pfSense admin interface. Only IT administrators should have access to this zone.
Guest Wi-Fi should be a separate SSID mapped to an isolated VLAN with internet-only access: no ability to reach any internal zone.
The inter-zone rule philosophy:
- Users can reach specific services in Servers (file sharing ports, specific application ports)
- Users cannot directly reach IoT or Management
- IoT can reach the internet (for firmware updates) but cannot reach Users or Servers
- Management can reach everything (for administration)
- Nothing can initiate connections to Users from outside (except established sessions from Users outbound)
Hardware Requirements
Managed switch with VLAN support:
The switch must support 802.1Q VLAN tagging. Consumer-grade unmanaged switches do not. Recommended budget options:
- TP-Link TL-SG108E (~$35): 8-port, web-managed, supports 802.1Q VLANs: suitable for very small environments
- Netgear GS308E (~$40): 8-port, web-managed
- Ubiquiti UniFi Flex Mini (~$29): 5-port, cloud-managed, integrates well with UniFi ecosystem
- Cisco SG350-10 (~$150): 10-port, advanced features, CLI and web UI: suitable for growing environments
For an environment with multiple switches, ensure they support VLAN trunking (802.1Q tagged ports) so VLANs can span multiple switches.
Router/firewall for inter-VLAN routing:
pfSense or OPNsense run on commodity hardware:
- Protectli Vault FW2B (~$180): fanless, 2 Intel NIC ports, runs pfSense/OPNsense
- Netgate 2100 (~$189): pfSense official hardware
- Repurposed PC/server with two NICs: Any x86 machine with at least 2 GB RAM and a dual-NIC works
pfSense handles inter-VLAN routing using VLAN subinterfaces on a single physical interface: you do not need one physical port per VLAN.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
VLAN Configuration on Switch and pfSense
Switch configuration (using TP-Link EasySmart/Cisco SG350 as examples):
On the switch:
- Create VLANs: 10, 20, 30, 99
- Configure the uplink port to pfSense as a trunk port (tagged for all VLANs):
switchport mode trunk; switchport trunk allowed vlan 10,20,30,99 - Configure access ports (connecting to endpoints) as access ports in the appropriate VLAN:
- Employee workstation ports: access VLAN 10
- Server ports: access VLAN 20
- Printer/IoT ports: access VLAN 30
pfSense VLAN configuration:
-
In pfSense GUI: Interfaces > Assignments > VLANs > Add
- Parent interface: your LAN interface (e.g.,
igb0) - VLAN tag: 10, Description: Users
- Repeat for VLANs 20, 30, 99
- Parent interface: your LAN interface (e.g.,
-
Assign each VLAN as an interface: Interfaces > Assignments > Add each VLAN
-
Configure IP addresses for each interface:
- Users (VLAN 10): 192.168.10.1/24
- Servers (VLAN 20): 192.168.20.1/24
- IoT (VLAN 30): 192.168.30.1/24
- Management (VLAN 99): 192.168.99.1/24
-
Enable DHCP server on each interface: Services > DHCP Server > select interface > Enable
-
Enable IGMP Proxy if you need multicast (streaming, mDNS services) across VLANs: optional.
Inter-VLAN Firewall Rules
In pfSense, firewall rules on an interface control traffic originating from that interface. Inter-VLAN rules go on the source VLAN's interface.
Users VLAN (VLAN 10) rules: what users are allowed to do:
# Allow DNS (to pfSense only: prevents DNS bypass)
Pass | TCP/UDP | Users_net | any | 192.168.10.1 | port 53
# Allow HTTPS and HTTP internet access
Pass | TCP | Users_net | any | any | port 80,443
# Allow SMB file sharing to specific file server
Pass | TCP | Users_net | any | 192.168.20.10 | port 445
# Allow RDP to jump server only (not to all servers)
Pass | TCP | Users_net | any | 192.168.20.20 | port 3389
# Block all other inter-VLAN traffic
Block | any | Users_net | any | RFC1918 | any
IoT VLAN (VLAN 30) rules: maximum restriction:
# Allow DNS
Pass | TCP/UDP | IoT_net | any | 192.168.30.1 | port 53
# Allow internet access (for firmware updates, cloud services)
Pass | TCP | IoT_net | any | !RFC1918 | port 80,443
# Block ALL access to internal networks
Block | any | IoT_net | any | RFC1918 | any
The !RFC1918 alias matches all non-private IP ranges (internet): this pattern allows IoT devices to reach the internet while blocking access to internal zones.
Testing inter-VLAN rules:
# From a workstation in Users VLAN, verify:
# 1. Can reach internet (should succeed)
curl -I https://www.google.com
# 2. Cannot reach IoT VLAN devices directly (should fail)
ping 192.168.30.50 # A printer's IP
# 3. Can reach the specific file server port (should succeed)
nc -zv 192.168.20.10 445
# 4. Cannot reach other server ports not in the allow list
nc -zv 192.168.20.10 22 # SSH to file server: should be blocked
The bottom line
Network segmentation with VLANs requires three components: a managed switch that supports 802.1Q VLAN tagging ($35-150), pfSense or OPNsense as the inter-VLAN router and firewall ($100-200 for hardware), and access control rules on each VLAN interface. The core architecture separates Users, Servers, IoT/Printers, and Management into four zones with explicit permit rules for required services and a default-deny block for everything else. Total hardware cost under $500; configuration time approximately 4-8 hours.
Frequently asked questions
How do you implement network segmentation on a budget?
Use a managed switch that supports 802.1Q VLANs (TP-Link EasySmart or Netgear GS308E, ~$35-40) and pfSense or OPNsense on commodity hardware (~$100-180 for a Protectli appliance). Create VLANs for Users, Servers, IoT, and Management. Configure pfSense with VLAN subinterfaces, DHCP per zone, and inter-VLAN firewall rules that default-deny all inter-zone traffic except explicitly permitted services.
What is the most important reason to segment a network?
Lateral movement containment. In a flat network, a compromised user workstation can directly reach every server, backup system, and domain controller. With segmentation, that workstation can only reach what the inter-VLAN firewall rules explicitly permit: forcing any lateral movement through monitored chokepoints where it can be detected and blocked.
What is VLAN-based network segmentation and how do I implement it?
VLANs (Virtual LANs) divide a physical network into logical broadcast domains: devices in different VLANs cannot communicate directly without going through a router or firewall. To implement: assign switch ports to VLANs by function (VLAN 10: user workstations, VLAN 20: servers, VLAN 30: IoT/printers, VLAN 40: guest/contractor WiFi); configure inter-VLAN routing on a managed switch or dedicated firewall; write ACL or firewall rules that explicitly permit only required traffic between segments (e.g., workstations to file server on TCP 445, workstations to internet via proxy). Consumer-grade switches do not support VLANs: this requires a managed switch from vendors like Cisco, Ubiquiti, or HP/Aruba.
How do I segment a network without dedicated enterprise gear?
For small environments without enterprise-class switches: use a next-generation firewall with multiple physical ports (pfSense, OPNsense, or a Ubiquiti UniFi Security Gateway) to create separate interface segments; assign each segment its own subnet and apply inter-segment firewall rules at the router. Ubiquiti UniFi equipment provides enterprise-style VLAN segmentation at SMB prices ($100-300 for a capable managed switch). For cloud environments, use VPC security groups and network ACLs to separate workload tiers (web, app, database) without any additional hardware.
What should always be in its own network segment?
Six segments that should always be isolated: (1) Domain controllers and identity infrastructure (Active Directory) — a compromised DC means full domain compromise; (2) Backup systems — ransomware targets backup servers specifically; (3) OT/ICS systems — operational technology should have no path to corporate IT; (4) Guest and contractor WiFi — no access to internal systems; (5) IoT and printer networks — these devices rarely receive security patches; (6) Payment card data environment (PDE) — PCI DSS requires isolation. Most organizations can start with three segments: user workstations, servers, and guest/IoT.
How do you test whether your VLAN segmentation is actually working?
Testing inter-VLAN segmentation requires verifying that traffic that should be blocked is blocked and traffic that should be permitted is permitted. From a workstation in the Users VLAN, run connectivity checks against devices in other zones: ping and nc -zv against devices in the IoT VLAN should fail, while permitted services on designated servers (TCP 445 for a file server) should succeed. Use nmap from each zone against other zones to confirm that blocked ports return filtered or no response rather than open. Check pfSense or OPNsense firewall logs during testing to confirm that blocked attempts are being logged with the correct rule: an absence of log entries when traffic should be blocked means the rule is not matching. For a deeper test, use a laptop connected to different VLAN access ports and re-run the connectivity matrix for each zone. Document baseline connectivity results immediately after configuration, because they serve as the reference for detecting misconfigurations introduced by future changes.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.