OPNsense is the heart of my home local area network (LAN). It's what handles the primary protection of the entire network and acts as a router, ensuring that traffic reaches its destination, both internal and external. There's a bonus in using OPNsense in that you have access to a catalog of plugins. These can range from simple scripts to in-depth services that enhance the versatility of your OPNsense installation. I run Nginx directly on OPNsense, and while some would argue proxies and routing should be kept separate, I find it incredibly useful to have both on the same box.

Instead of running Traefik or Nginx separately as a virtual machine (VM) through Proxmox or some other hypervisor, I decided to run it within OPNsense, tightening up security, ensuring maximum uptime, and full integration with configured rules. It's great because OPNsense handles Nginx integration internally, so resources are pooled together for both tasks to be completed with little overhead.

If the net is down, Nginx is gone too

It doesn't really matter

OPNsense, by nature, is fully modular. The firmware has countless plugins maintained by the community that can expand the functionality of your firewall with Let's Encrypt certificates, advertisement and tracker blocking, and real-time network logging and monitoring. One such extension is Nginx, yes, the same Nginx that can run web servers. It's also great for handling requests through reverse proxies, allowing you to set up a domain name and point it to your WAN IP and access publicly-facing services with user-friendly URLs.

If I run Nginx on another system, it's still going to be relatively useless if OPNsense goes offline. Without the router being up and running, devices wouldn't know where to go. I find it best to consolidate anything that requires OPNsense to be online to run on the same system, if possible. That way, if the firewall fails or goes offline, I only lose stuff that absolutely requires it to be running. Then there's the fact that if I take a server offline that just so happens to be running Nginx, all my reverse proxies go with it.

I rarely will take OPNsense offline, ensuring the reverse proxies are live for as long as possible. Without the firewall and router up, VLANs stop functioning, DNS will cease to resolve on clients, and DHCP will be long gone. Without all these services, my reverse proxies would have nowhere to go, so it makes no sense to have them running somewhere else. It also makes troubleshooting any issues easier, since if there's a problem with routing or the proxies, it's going to be on some system.

It makes networking easier

VLANs are no trouble

Setting up and managing virtual networks within the LAN can prove troublesome with Nginx or some other reverse proxy manager running outside of OPNsense. Since it's the router and gateway for all VLANs, having Nginx on OPNsense ensures there's no further configuration required for the system to see all inter-VLAN traffic. Running Nginx on another system would require static routes, NAD exceptions, and firewall rules to be added. This isn't difficult, mind you, but it's an extra layer of complexity I can remove by simply running everything on the same box.

All I needed to do was point each service I wished to have available via the domain to the default gateway (in this case, the OPNsense IP for that VLAN), and we're good to go since the Nginx plugin would then handle routing and proxying natively through the firmware. Let's take Jellyfin as an example, which would be loaded up on 192.168.1.51. Nginx would forward jellyfin.mydomain.com to that internal IP via OPNsense. The router already knows how to reach it, so everything just works without having to set rules and routes.

Firewall rules can be complicated for beginners to wrap their heads around when first starting with a custom firewall solution like OPNsense. That's why this method is also great for simplifying the entire process of managing security without messing around with availability. When requests come through, OPNsense doesn't need to pass the packet to another host since Nginx is already listening directly on the interface or IP. This also has the side effect of reducing the number of attack vectors.

Consolidate as much as possible

Networking and Proxmox

I'm of the sound mind to consolidate as much as I can to save energy and better utilize all available resources. My OPNsense system runs on a small mini PC with a passively cooled Intel processor. It's nothing special, but it easily handles the WAN fiber connection and a 10Gb backend. Still, with OPNsense, Unbound, Ntop, ACME, DDNS, and a few other services running alongside Nginx, usage hovers at around 5% idle with 50% or so spikes for logging and traffic. There's ample headroom for running plugins on the box, which makes it even more versatile.

Nginx is entirely event-driven for reverse proxies, so it won't take any resources from OPNsense unless you're hitting it hard with requests. But the best part is that through the power of consolidation, I can more easily integrate Nfinx with other services, such as ACME, to take advantage of any assigned Let's Encrypt certificates. I can easily use all saved certificates without having to copy them across or synchronize them upon change. Though this could be automated with scripts, it helps keep things simple by having everything in one place.

It has made my life easier

But should something go wrong somewhere down the line, which I have had to deal with regarding ACME and certification, it's easier to troubleshoot what's happening thanks to centralized logging. Finally, I can quickly back up my entire Nginx configuration when dumping my OPNsense config file for safekeeping. It's the best of all worlds and massively outweighs any drawbacks this approach may have compared to running Nginx separately, at least for my own network and home lab setup.