When looking up information on how to write firewall rules in OPNsense, you may be looking for specific examples on how to block or allow certain types of network traffic rather than how to write firewall rules in general. This is especially true once you become more experienced and comfortable with writing rules. I thought it would be a good idea to consolidate a variety of scenarios into a single how-to that could be used as a quick reference guide.
Understanding how to forward ports and create firewall rules for the WAN interface of your router is important if you wish to access services hosted on your router or a server in your internal network. Knowing when to use a WAN rule versus a NAT Port Forward rule may be confusing to new users.
WAN vs. NAT Port Forward Rule: Which one to use? Generally speaking, WAN rules should be used for any service running directly on your router and NAT port forward rules for any service host on a server in your internal network (either virtualized or physical).
When you first learned to write firewall rules in OPNsense, you may have simply used the pre-defined aliases for the network interfaces/ports and IP addresses such as “LAN net”, “LAN interface”, “HTTP”, “HTTPS”, etc. You may not have even realized you were using aliases since they do not appear in the list on the “Aliases” page. Using the predefined aliases is not only convenient but helps make your rules easier to understand (imagine having a large number of rules and seeing only IP/network addresses).
Have you wanted to take a look at OPNsense without installing it to a dedicated machine and/or deploying it as your primary home router/firewall? The easiest way to evaluate OPNsense without installing it on separate hardware is to virtualize it. I wrote about running OPNsense in VirtualBox. Now that I run Proxmox on my server instead of Ubuntu (I still use Ubuntu for many of my LXCs/VMs on Proxmox), I wanted to run OPNsense on Proxmox so I may use when writing content for this site.
When I first set up my home network using my OPNsense router and was learning firewall rules, I took the approach of allowing only the Unbound DNS service on OPNsense to be accessed and blocking access to all other DNS servers. This simplistic approach works well enough since any rogue access to external DNS servers are simply blocked. Only the DNS resolver on the local network is allowed (unless the DNS requests are encrypted, of course – see note below).
