OPNsense Firewall Rule "Cheat Sheet"
A quick guide to creating firewall rules in various situations

Introduction
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.
It is worth noting that any IP addresses used in the examples could be substituted with aliases. If you plan to create several rules for a particular device, you may want to make sure of aliases since it allows you to quickly change the values for a bunch of rules at the same time. It also helps make the rules more readable since you do not have to remember that 192.168.10.10 is your laptop, PC, Raspberry Pi, etc. To add a new alias, go to the “Firewall > Aliases” page.
To add new firewall rules for your various network interfaces, go to the “Firewall > Rules” page. You will see a list of interfaces in which you may add firewall rules.
LAN/VLAN Rules
Below are some scenarios for creating firewall rules for your LAN/VLAN interface(s):
Block a single device on VLAN 10 from accessing the Internet
If you need to block Internet (and also local network) access for a particular device on VLAN 10:
Option | Value |
---|---|
Action | Block |
Interface | VLAN10 |
Protocol | any |
Source | 192.168.10.10 |
Source Port | any |
Destination | any |
Destination Port | any |
Description | Block access to Internet |
Block all devices on VLAN 10 from accessing the Internet
To block all devices on the entire VLAN 10 network, simply do not add any firewall rules for the VLAN 10 interface. By default, all outgoing traffic is blocked to both the Internet and other VLANs so this rule would be redundant. However for the purposes of illustration and learning, the following rule would block all outgoing traffic:
Option | Value |
---|---|
Action | Block |
Interface | VLAN10 |
Protocol | any |
Source | VLAN10 net |
Source Port | any |
Destination | any |
Destination Port | any |
Description | Block access to Internet |
Block all devices on VLAN 10 from accessing a single host/server on the Internet
If you want to block access for all devices on VLAN 10 from accessing one particular IP address on the Internet:
Option | Value |
---|---|
Action | Block |
Interface | VLAN10 |
Protocol | any |
Source | VLAN10 net |
Source Port | any |
Destination | 8.8.8.8 |
Destination Port | any |
Description | Block access to the host/server 8.8.8.8 |
Allow a single device on VLAN 10 to access any port of single device on VLAN 20
This rule allows a device on VLAN 10 to access any open service that is running on the device that resides on VLAN 20:
Option | Value |
---|---|
Action | Pass |
Interface | VLAN10 |
Protocol | any |
Source | 192.168.10.10 |
Source Port | any |
Destination | 192.168.20.10 |
Destination Port | any |
Description | Allow device to device access |
Allow any device on VLAN 10 to access any port of single device on VLAN 20
This rule allows every device on VLAN 10 to access any open service that is running on the device that resides on VLAN 20:
Option | Value |
---|---|
Action | Pass |
Interface | VLAN10 |
Protocol | any |
Source | VLAN10 |
Source Port | any |
Destination | 192.168.20.10 |
Destination Port | any |
Description | Allow VLAN 10 access to device |
Allow any device to access any network or device (local networks and Internet)
This is the default “allow all” rule created by OPNsense on the LAN interface when you install OPNsense.
Option | Value |
---|---|
Action | Pass |
Interface | LAN |
Protocol | any |
Source | any |
Source Port | any |
Destination | any |
Destination Port | any |
Description | Allow access to any network/device |
If you use this rule, I would recommend restricting as much network traffic as possible above this rule to minimize unwanted traffic. When you have more restrictive rules above this rule, it essentially becomes a “allow all other” rule to allow any traffic you have not explicitly blocked to pass through. This is probably more useful in a home network environment so you do not have to constantly tweak your firewall rules to allow every different type of traffic through the firewall (unless you enjoy that sort of thing). Companies and the government may want to default to “deny all other” to be more restrictive in which case you would simply not include this “allow all” rule at the bottom of the rule list.
Allow DNS requests to only be resolved by OPNsense and not by external DNS servers
You need two rules to accomplish this. I am going to assume there will be other rules below the “block all other DNS” rule. If you do not have any other rules below the first rule, by default everything else will be blocked since no rules will be triggered. You can repeat the below rules in each VLAN or alternatively, you can create these as floating rules or create a firewall rule group as described after the two rules below. For a single interface, enter the following values:
Option | Value |
---|---|
Action | Pass |
Interface | LAN |
Protocol | TCP/UDP |
Source | LAN net |
Source Port | any |
Destination | 192.168.1.1 |
Destination Port | 53 (DNS) |
Description | Allow DNS requests to be resolved on OPNsense |
Option | Value |
---|---|
Action | Block |
Interface | LAN |
Protocol | TCP/UDP |
Source | LAN net |
Source Port | any |
Destination | any |
Destination Port | 53 (DNS) |
Description | Block all other DNS requests (internal and external) |
If you choose to use floating rules (located on the “Firewall > Rules > Floating” page), the main difference between rules defined for a particular interface and floating rules is that you can select multiple interfaces that the rules should be applied. It allows you to create a single rule that can be set on multiple interfaces. Floating rules are processed before the rule groups and interface rules. The rules above would look like the following:
Option | Value |
---|---|
Action | Pass |
Interface | LAN, DMZ, IOT |
… | … |
Option | Value |
---|---|
Action | Block |
Interface | LAN, DMZ, IOT |
… | … |
Alternatively, if you want to organize sets of rules, you could create a firewall rule group by going to the “Firewall > Groups” page. As mentioned prior, group rules are processed after floating rules but before the interface rules. So you could create a group such as “DNSRules” and create the DNS rules in that group. Like with floating rules, you can select all of the interfaces in which the group of rules are applied when you create the new group. The nice thing about rule groups is that you do not have to select all of the interfaces for every new rule you create within the group because you have already defined the interfaces when you created the group. With the floating rules, you have to select all of the appropriate interfaces every time you create a new rule. The above rules would look as follows in a rule group (notice the group name as the interface):
Option | Value |
---|---|
Action | Pass |
Interface | DNSRules |
… | … |
Option | Value |
---|---|
Action | Block |
Interface | DNSRules |
… | … |
Allow ICMP messages on all internal networks to aid in troubleshooting
Many administrators disable all ICMP messages on the network both internal and external since they can be abused. However, allowing pings and destination unreachable messages on your internal network can be helpful with troubleshooting connectivity issues on your network.
If you have multiple VLANs, I recommend that you create a firewall rule group or use floating rules. For the firewall group or the float rules, you would select only the LAN/VLAN interfaces in which you wish to use ICMP. Then you can create the rules below. The example below is using the group name ICMPGroup as the interface (since the group already knows what interfaces to apply the rules). If you using floating rules instead, you can select the appropriate list of LAN/VLAN interfaces instead of using the group name as the interface. These are the most common and useful ICMP messages:
Option | Value |
---|---|
Action | Pass |
Interface | ICMPGroup |
Protocol | ICMP |
ICMP type | Echo Request |
Source | any |
Destination | any |
Description | Allow ICMP echo request messages |
Option | Value |
---|---|
Action | Pass |
Interface | ICMPGroup |
Protocol | ICMP |
ICMP type | Echo Reply |
Source | any |
Destination | any |
Description | Allow ICMP echo reply messages |
Option | Value |
---|---|
Action | Pass |
Interface | ICMPGroup |
Protocol | ICMP |
ICMP type | Destination Unreachable |
Source | any |
Destination | any |
Description | Allow ICMP destination unreachable messages |
Option | Value |
---|---|
Action | Pass |
Interface | ICMPGroup |
Protocol | ICMP |
ICMP type | Time Exceeded |
Source | any |
Destination | any |
Description | Allow ICMP time exceeded messages |
If you want to use ICMP but block using it for certain networks such as your management VLAN or other sensitive networks, you could add “block” rules above the “allow” rules. I do not want to repeat all of them but you would simply add rules such as this:
Option | Value |
---|---|
Action | Block |
Interface | ICMPGroup |
Protocol | ICMP |
ICMP type | Echo Request |
Source | any |
Destination | MGMT net |
Description | Block ICMP echo request messages to the management VLAN |
WAN Rules
Below are some scenarios for creating firewall rules for your WAN interface:
Allow remote access on WAN to VPN server on OPNsense
Since the OpenVPN service is hosted on the OPNsense router, you can add the following rule to the WAN interface. This holds true for any service running on your router since you do not need to forward any ports to a device inside your network:
Option | Value |
---|---|
Action | Pass |
Interface | WAN |
Protocol | UDP |
Source | any |
Source Port | any |
Destination | WAN address |
Destination Port | 1194 |
Description | Allow remote access to OpenVPN |
Allow remote access to web server on VLAN 10 using NAT port forwarding
To forward ports in OPNsense, you need to go to the “Firewall > NAT > Port Forward” page. Creating the rule follows a similar process to other LAN/WAN rules except that you need to also specify the IP/alias and port number of the internal device on your network. This means you need to enter values for the “Redirect target IP/port” data fields.
Note: When you create a NAT port forward rule, a corresponding WAN rule is automatically created on the WAN interface. The description of the rule will be the same as the port forward rule but with “NAT” prepended to the description to indicate that it was derived from a port forward rule. If you delete the NAT port forward rule, it will also delete the WAN rule because they are linked together. However, if you delete the WAN rule that was automatically generated, it will not delete the corresponding port forward rule. It is likely that you have just broken your port forward rule (at least for remote access). Both rules need to exist for port forwarding to function properly.
If you do not see the NAT port forward rule automatically be created on the WAN interface when you apply changes, it is possible you will need to go to the “Firewall > Settings > Advanced” page to ensure that the “Reflection for port forwards” option is enabled.
I have noticed that many users are confused about how to configure port forwarding in OPNsense, but creating the rules are identical except for going to a different page (NAT Port Forwarding) entering values for two additional “redirect target” data fields.
Option | Value |
---|---|
Action | Pass |
Interface | WAN |
Protocol | TCP |
Source | any |
Source Port | any |
Destination | WAN address |
Destination Port | 443 (HTTPS) |
Redirect target IP | 192.168.10.10 |
Redirect target port | 443 (HTTPS) |
Description | Allow remote access to web server |
The external port and the port on the internal device hosting the service do not have to be identical. You could externally map any port to the port on the host device. You may actually want to use a different external port for certain services such as SSH so that your SSH service does not get spammed from scans or attacks that occur most frequently on the default port. For instance, you could have external port 2022 map to the standard port 22 on your server.
Suggestions/Feedback
If you have any suggestions for other basic firewall examples, please let me know in the comments below or on Twitter/Facebook/email so that I may include them. Keep in mind that I prefer not to include example rules where the only difference in the rules is changing a port number because I cannot include an example for every possible service in existence. I am striving to include scenario-based examples that are straightforward to configure since this is meant to be more of a quick guide than a detailed walkthrough of a specific scenario.