None Shall Pass: Building and Deploying My Own OPNsense Router

(Figure 1. Pictured left: Arris Surfboard Modem. Top Right: ASUS ExpertWiFi EBP15 Managed Switch. Bottom Right: Dell Optiplex 5060 Mini Desktop repurposed as an OPNsense router)

Executive Summary:
This project details the process of repurposing a modified desktop computer into a router to enhance security, enable network segmentation, and gain hands-on networking experience. New capabilities were unlocked by deploying OPNsense as the firewall operating system, including VLAN configuration, firewall rule management, improved network visibility, and granular control of IP address allocation. These features were not possible with the prior networking solution.

All primary objectives were met, and several future opportunities were identified. The implementation provided invaluable experience in technical troubleshooting, targeted research, and the practical use of network tools. This router now serves as a secure foundation for future projects, including those involving internet-facing devices where safeguarding personal data is paramount.

Rationale:
I recently deployed a server for networked storage and some virtual machines, but I plan to add a honeypot exposed to the internet for attacker log aggregation and TTP (tactics, techniques, and procedures) analysis. Sharing this idea highlighted the need for stronger network segmentation and control. While my current setup was secure for local use, it wasn’t suitable for monitoring attacker behavior. Choosing to build my own router instead of buying one came down to cost, and repurposing powerful existing hardware provided a free, ideal platform. The only component I needed was an operating system compatible with my segmentation goals and capable of enhancing network security.

I temporarily shut down my server and did some research on routing/firewall operating systems. For its wide feature set, enterprise-level security, and medium skill ceiling, I chose to deploy OPNsense, an open-source routing & firewall OS.

Objectives:

• Network segmentation: Isolating my personal network traffic and my server’s network traffic is the biggest objective. VLANs will be utilized, blocking all traffic from the server to my personal network, and having limited traffic from the personal network to the server network. I will also be isolating my game consoles into their own VLAN, as they have no need to communicate with any devices on the network.

• Enhanced security options: Installing a self-deployed router will give me more granular control over how I want my personal assets protected. I will be able to easily deploy VPN solutions for remote access, intrusion detection through Suricata, and VLAN routing rules.
  Laying the foundation for a SIEM: I am making a huge change to my network architecture, and want it to be thoroughly tested and secure before redeploying my server and configuring my SIEM to collect and aggregate logs.

• Hands-on experience: I am always looking for more experience and the opportunity to troubleshoot through experience with testing and research.

Considerations:
Before beginning, there were certain considerations that I needed to ensure were met or addressed before or during the process.

• Back-out plan: After deploying my router, I needed to ensure I would have a way to keep my network operational in the event of the transition failing.
• Continuous operation: The router will be operating 24/7, and with this comes the considerations of environmental factors like heat and dust from its placement location, and factors such as power loss. If there is a power outage, I need the router to immediately turn back on when power returns.
• Appropriate security controls: In accordance with NIST SP 800-53, I want to ensure I implement appropriate security controls to protect each part of the network. This is a consideration that expands as the scope does.

Materials:
The materials used for the deployment needed to work together to execute on the overall goals. Most were repurposed for this project.

• Router Hardware: Dell Optiplex 5060 Micro Desktop Intel Core i5 (8th Gen) 24GB DDR4 SODIMM RAM 256 Kingston M.2 SSD (For OS) Native 1x GbE NIC (WAN) + M.2 to 2.5Gb Ethernet NIC (LAN)
• Managed Switch: ASUS PoE+ ExpertWiFi EBP15
• Access Points (AP): 2 x Eero 6+ units (used in bridge mode)
• Modem: ARRIS SURFboard SB6190 32 x 8 DOCSIS 3.0 Cable Modem

Procedure:

• Utilizing a bootable USB flash drive, the OPNsense OS was installed, referring to OPNsense’s official installation guide when necessary: https://docs.opnsense.org/setup.html
• Plugged the modem into the router's WAN interface, which was automatically assigned. Plugged a laptop into the router’s M.2 LAN interface, changed the default admin password, and ran a firmware update. (initially used a USB to Ethernet interface for LAN, but replaced this solution due to instability)

(Figure 2. Screenshot of OPNsense dashboard displaying memory usage, disk usage, uptime, load average, last configuration change, interface statistics, firewall traffic, traffic graphing, and active services)

• Connected the ASUS switch to the LAN interface, performed initial set up and uploaded a firmware upgrade.
• Connected an Eero mesh access point to the switch and put it in bridge mode. Meshed a second Eero access point in a different room.
• Connected the main PC into an AP with Ethernet and configured VLANs within the switch. (All configuration specifics will be in the next section)
• Created VLAN interfaces to match the tagging scheme created on the switch. Configured DHCP ranges for each VLAN for easy identification purposes.
• Configured firewall rules to enforce segmentation between VLANs, but allow the main PC to access specific IP addresses for management purposes.

(Figure 3. Physical network diagram displaying the layout of the network)

Configuration:

Operational:

• Changed root password & created a secondary user for all management purposes to avoid using the root user
• Created a task for automatic back-ups to local and cloud storage to provide multiple restore options
• Created a weekly scheduled task for automatic firmware updates In the PC BIOS, enabled the behavior to automatically power back on after a power loss

VLANs/DHCP:
In order to create network segmentation, I utilized VLAN tagging to identify traffic coming from different ports of the switch. The tags would help my router identify traffic for segmentation purposes. This would later be reinforced by my firewall. I wanted my IP ranges to be easily identifiable, so I adopted a scheme where all IPs are within 192.168.0.0/16, but separated them based on a different 3rd quadrant. Ex. VLAN10 is 192.168.0.X, while VLAN30 is 192.168.3.X. I also wanted to limit the number of usable addresses to the number of devices that would use the network. This is not the case for the LAN, as certain devices pick their own IP address somewhere in the 192.168.1.0/24 range. Because of this, this network will require more attention than others.

I created the following VLANs and IP address schemes on both my switch and router:

(Figure 4. Diagram displaying the ASUS managed switch VLAN port usages)

LAN (Management) - 256 addresses (253 usable) - 192.168.1.0/24 (192.168.1.0 -

192.168.1.255)
Static reservations:
Switch: 192.168.1.50

VLAN 10 (Personal) - 64 addresses (61 usable) - 192.168.0.0/26 (192.168.0.0 - 192.168.0.63)
Static reservations:
Main PC: 192.168.0.3
Eero AP: 192.168.0.4
Eero AP: 192.168.0.5
Printer: 192.168.0.14

VLAN 20 (Gaming) - 8 addresses (5 usable) - 192.168.2.0/29 (192.168.2.0 - 192.168.2.7)
Static reservations:
PS5: 192.168.2.2
Raspberry Pi: 192.168.2.3

VLAN 30 (Server) - 32 addresses (29 usable) - 192.168.3.0/27 (192.168.3.0 - 192.168.3.31)
Static reservations:
TrueNAS Server: 192.168.3.2
(This device is not deployed, but a static reservation was created in advance with its MAC address for future usage)

Firewall:
My firewall rules would make or break one of the biggest objectives in segmentation. I created the following rules for interfaces:

• Created a rule on VLAN10 to allow the specific IP address of the main PC to reach the address for the OPNsense router & managed switch within the LAN, and the server within VLAN30
• Created a rule on each VLAN to block traffic to other VLANs & LAN
• Created a rule to allow all other traffic to exit the VLAN to the internet

(Figure 5. Screenshot of VLAN 10 firewall rules)

Testing:
After making my configuration changes, it would not be beneficial to move on without testing them to ensure my network is operating as needed.

Basic functionality:

• At every step, I tested if devices could reach the internet and if they still maintained a high speed. I performed a speed test on google.com and pinged 1.1.1.1. If either were unsuccessful, I reversed my changes and troubleshooted the issue.
• After implementing VLANs and DHCP, I soft reset all devices and checked to ensure each device was within the correct IP address range. If not, I tweaked the VLAN settings within the switch and router.

Segmentation:
Before and after implementing firewall rules, I pinged an address within another network to see if it would fail or succeed. The test was only deemed successful if it passed before the rule was implemented and failed after, demonstrating the firewall blocking traffic.

Before firewall rules:

(Figure 6. Screenshot of Windows command prompt successful ping from PC - 192.168.0.3 to PlayStation 5 - 192.168.2.2)

After firewall rules:

(Figure 7. Screenshot of Windows command prompt unsuccessful ping from PC - 192.168.0.3 to PlayStation 5 - 192.168.2.2)

Pings were also successful to the specific IP addresses within the LAN, but only from the management PC. All pings from other devices or to unapproved devices were unsuccessful, resulting in a successful test.

Network Scans:
Utilizing nmap, I wanted to tie up loose ends with some tests that would accomplish many goals: verify segmentation a second time by scanning the range of 192.168.0.0/16, identify insecure ports/services open on devices, and identify any rogue or risky devices.

• Performed an intense scan, including UDP ports on 192.168.0.0/16 from the main PC. No devices from other VLANs were detected during scans, confirming effective segmentation and firewall enforcement.
• Utilized a separate laptop to run a scan only within the DHCP range of each VLAN/network.

(Figure 8. Screenshot of Nmap network scan of 192.168.0.0/24, displaying all hosts on the network. The above shows services/ports open on the host 192.168.0.3.)

• Marked any unknown devices for investigation.
• Marked any insecure ports for risk analysis.

Security:
To create a proactive security measure for future plans of deploying an internet-facing server, appropriate security controls and alerting will be necessary.

• Activated OPNsense Intrusion Prevention System on the WAN interface and enabled rulesets for known malicious activity.
• Enabled syslog alerts. (Will be configuring these logs to be sent to a Security Event & Incident Manager tool)
• Created an automated weekly task for automatically updating and reloading rulesets.

Rollback/Backout Plan:
Before deploying the router, my LAN was facilitated through the eero 6+ mesh system. If the router deployment fails and needs to be rolled back, the eeros can be easily redeployed as a router to regain network connectivity. No configuration is needed beforehand, but the eeros’ DHCP & NAT mode would need to be switched back to automatic, and the main eero would be connected back to the WAN port on the modem.

Lessons Learned:
There were many opportunities from this project, both big and small, that could have helped me save time, or will help me save time in a future endeavor.

• Properly format & handle SSD drive: The boot SSD needed to be reformatted due to the file system being reported as dirty by the OPNsense CLI. This would have saved time during installation & deployment.
• Ensure BIOS settings are optimized: The server had been repurposed and was originally set to accept RAID, and now that it was switching to being a router, it needed to be changed back to AHCI, as the SSD was not being recognized by OPNsense’s installer.
• USB to Ethernet is unreliable: USB to Ethernet adapters proved unreliable in this application, with the link state dropping under heavy load, upon removal of other USB devices, or at random. After replacing the adapter with an M.2 to Ethernet solution, log analysis showed LAN interface drops decreased from an average of 3 per day to zero.
• VLANs: VLAN configurations vary significantly between manufacturers. For example, ASUS’s interpretation of PVID assignment differed from Cisco’s, requiring additional research into ASUS’s documentation to correctly align VLAN tagging between the switch and the OPNsense router.
• Firewall Rules: Rules for OPNsense are only set for the ingress of an interface. Though confusing at first, the concept of inbound was in the context of the interface I’m setting doing into another network, which made it the source, not the destination. I realized while ping testing other VLANs that segmentation had not occurred.

Conclusion:

The OPNsense router implementation was both beneficial and challenging, ultimately achieving every objective and overcoming all obstacles through perseverance and diligence. Hardware and configuration changes have resulted in a resilient network with strong defensive capabilities.

While the router delivers immediate benefits, it remains an ongoing project requiring consistent monitoring and testing to maintain security. Future plans include hosting self-managed public-facing servers, making granular network control and enhanced security essential. Additional hardware solutions, such as uninterruptible power supplies, may be introduced to ensure consistent uptime.