Sandbox99 Chronicles

Reading Time: 6 minutes

Introduction

Welcome back to our OPNsense blog series! If you’ve been following along, you’ve successfully selected your hardware, prepared your installation media, and completed the basic installation of the OPNsense firewall operating system. If you haven’t, you can catch up on our previous posts here: [Installing OPNsense as a Virtual Firewall]

Now that the core of your homelab’s network security is up and running, it’s time to take the next critical steps. In this installment, we’ll dive deep into post-installation configuration, transforming a fresh OPNsense install into a robust and secure perimeter firewall.

Post-Installation and Web UI Configuration

Accessing the Web UI

Once installation completes and OPNsense boots, connect a Guest OS to the OPNsense LAN port. The default configuration automatically assigns IP addresses via DHCP to LAN-connected devices. If your home router uses the standard 192.168.1.1/24 block, this becomes your bridge network. For clear subnet identification, configure your LAN using Class A or Class B private addressing from RFC1918. Ensure a Guest OS is connected to your OPNsense LAN subnet to access the OPNsense interface through the LAN default gateway. The default username is root and the default password is opnsense.

<network>
  <name>opnsense-lan65</name>
  <forward mode='none'/>
  <bridge name='virbr65' stp='on' delay='0'/>
  <ip address='10.10.65.100' netmask='255.255.255.0'/>
</network>

My network topology uses OPNSense with LAN gateway 10.10.65.1. My Host OS (10.10.65.100) and Guest VMs on the same LAN segment can all access the OPNSense web management interface via browser

Foundational Hardening (Crucial)

These steps should be done immediately to secure your firewall from unauthorized access.

1. Change the Default root Password: This is the most critical first step. The default root password is well-known (opnsense). Log in to the web GUI and navigate to System -> Access -> Users to change the password for the root account to a strong, unique one.
2. Create a New Admin User and Disable root: It’s best practice to not use the root account for day-to-day administration.
   • Create a new user with a strong password.
   • Add this user to the admins group under System -> Access -> Users.
   • Once you can log in with the new user, go back and disable the root account. This forces you to use a non-default username, which is a common security practice.
3. Enable Two-Factor Authentication (2FA): OPNsense has a built-in Time-based One-Time Password (TOTP) feature.
   • Navigate to System -> Access -> Users and edit your new admin user.
   • Enable TOTP and follow the on-screen instructions to link it with an authenticator app on your phone (e.g., Google Authenticator, Authy).
4. Disable Web GUI Access from the WAN: By default, OPNsense blocks this, but it’s good to double-check. The web GUI should only be accessible from your internal LAN. If you need remote access, a secure VPN is the correct solution, not an open port on the WAN.
5. Disable SSH Access from the WAN: The same principle applies here. SSH is a common target for brute-force attacks. If you’re not using SSH, you can simply disable the service under Services -> SSH. If you need it, ensure it’s configured to only listen on your LAN interface and consider using SSH key-based authentication instead of passwords.

The Built-in DNS Power of OPNsense

OPNsense’s primary DNS feature is Unbound DNS. It’s a validating, recursive, and caching DNS resolver that is included and enabled by default in new OPNsense installations.

Here’s how Unbound on OPNsense provides all the benefits we discussed earlier:

• Recursive DNS Resolution: Unbound can be configured to act as a recursive resolver. This means it doesn’t just forward your requests to a third-party DNS provider. Instead, it starts from the internet’s root DNS servers and works its way down to find the correct IP address. This provides true privacy, as no single entity can see all of your browsing history.
• DNSSEC Validation: Unbound can validate DNSSEC (Domain Name System Security Extensions) records. This is a crucial security feature that ensures the integrity of DNS data, protecting you from DNS cache poisoning attacks and other forms of man-in-the-middle attacks.
• Caching: Just like any good self-hosted solution, Unbound caches DNS query results. This means that after the first device on your network visits a website, subsequent requests for that same site from any other device will be answered instantly from the local cache, leading to a noticeable improvement in browsing speed.
• Customization and Control: You have full control over Unbound’s configuration through the OPNsense web interface. You can set up host overrides for your local devices, create custom DNS entries, and configure different behavior for different network interfaces or VLANs.

Adding Ad-Blocking and Filtering

While Unbound is a powerful DNS resolver, it doesn’t natively have a user-friendly way to add huge blocklists for ads and trackers like Pi-hole. This is where OPNsense’s plugins come into play.

• Unbound’s DNS Blocklists: OPNsense includes a feature to add DNS blocklists directly to Unbound. This allows you to block ads, malware, and trackers network-wide without needing an external tool. It’s a simple, elegant solution for many users and is built right into the firewall.
• AdGuard Home Plugin: If you want a more robust, feature-rich ad-blocking solution with a graphical interface, you can install the AdGuard Home plugin on OPNsense. This is a very popular option as it combines the powerful DNS resolver capabilities of OPNsense with the advanced filtering, logging, and reporting of AdGuard Home. You would configure AdGuard Home to use Unbound as its “upstream” DNS server, creating a powerful combination of privacy, security, and content filtering.

Suricata Post-Installation Fine-Tuning

While Zenarmor is a popular choice, OPNsense also includes Suricata, a powerful, open-source IDS/IPS engine. It’s pre-installed and can be configured to add a deep layer of security to your network. Here’s what you need to do to fine-tune it after installation.

1. Initial Setup and Enabling IPS Mode

First, navigate to Services -> Intrusion Detection -> Administration in the OPNsense web UI. In the Settings tab, make sure the following are checked:

• Enabled: This turns the service on.
• IPS mode: This is crucial. IPS (Intrusion Prevention System) mode actively blocks malicious traffic, whereas IDS (Intrusion Detection System) mode only logs it.
• Promiscuous mode: Enable this if you’re running OPNsense in a virtual machine or if you want Suricata to inspect traffic on a physical interface that is also being used for VLANs.

Select the interfaces you want to monitor, typically your LAN and any VLAN interfaces you’ve created. IPS on the WAN interface is generally not necessary, as the OPNsense firewall’s default deny rule already blocks unsolicited inbound traffic. However, monitoring the LAN and VLANs can help detect infected internal devices.

2. Configure Home and External Networks

Suricata uses the concepts of a HOME_NET and EXTERNAL_NET to apply rules correctly. In the Settings tab, you should define your HOME_NET. By default, this is your LAN subnet, but you should explicitly set it to your internal network’s IP range (e.g., 192.168.1.0/24). EXTERNAL_NET is automatically defined as “not the home network.”

3. Manage and Download Rulesets

Suricata’s effectiveness depends on its rules. In the Download tab, you’ll see a list of available rulesets. It’s a best practice to enable only the rules you need to avoid unnecessary overhead and false positives.

• Emerging Threats Open (ET-Open): This is a popular free ruleset that provides a good baseline for threats. It’s highly recommended to enable this one.
• OPNsense Rules: OPNsense also provides its own rulesets.
• Proofpoint ET Pro Telemetry: For a homelab, the free rulesets are usually sufficient, but some advanced users might consider paid rulesets for more up-to-date threat intelligence.

After selecting your desired rulesets, click Download & Update Rules. You can also schedule automatic updates in the Schedule tab to ensure your rules are always current.

4. Create Policies and Fine-Tune Rules

Managing thousands of rules individually is unfeasible. This is where Policies come in.

• Go to Services -> Intrusion Detection -> Policy.
• Create a new policy and assign your downloaded rulesets to it.
• The policy allows you to set a default action for all the rules within it (e.g., alert, drop, or disable).
• For your homelab, start with a policy that sets the action to Alert for most rules. This lets you observe what Suricata is flagging without it actively blocking your traffic. You can then check the Alerts tab and selectively change specific rules to drop if you confirm they are indeed malicious. This prevents accidental service disruptions.

5. Performance Considerations

Running an IPS/IDS can be resource-intensive. If you notice a performance drop, you can make some adjustments:

• Reduce Rulesets: The single biggest impact on performance comes from the number of rules being inspected. Disable any rulesets you don’t need.
• Hardware Offloading: In Interfaces -> Settings, disable hardware checksum offloading, TCP segmentation offloading (TSO), and large receive offloading (LRO) for the interfaces Suricata is monitoring. This can improve Suricata’s performance.

By following these steps, you will transform your basic OPNsense setup into a highly secure and robust perimeter firewall, giving you peace of mind while you explore your home lab.

Final Thoughts

You’ve completed the journey from a basic hardware selection to building a secure and segmented network. You’ve learned how to install and configure OPNsense, implement essential security best practices to protect your homelab.

This is just the beginning! The true power of OPNsense lies in its flexibility and the community’s support. We encourage you to start your own OPNsense journey and tailor it to your specific needs.

Disclaimer: This blog post is created for homelab enthusiasts and learning purposes. These configurations have not been hardened for production environments and should not be deployed in business or mission-critical systems.