OPNsense Firewall Rule "Cheat Sheet"

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.

---