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 or want to combine multiple IP/network addresses into a single rule, you may want to use aliases. Aliases allow for multiple values and you can quickly change the values for several 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 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
By default, the LAN network in OPNsense has anti-lockout rules (to prevent you from locking yourself out of the web interface) and an “allow any” rule which allows access to all local and remote networks. When you create a new VLAN or a network on another physical interface, access to all other networks are blocked by default since there are no firewall rules defined for the new network (besides hidden auto-generated ones required for DHCP to function, for instance). Many of these examples assume you have multiple local networks and you want to allow communication between devices in the different networks.
Below are some scenarios for creating firewall rules for your LAN/VLAN interface(s):
Allow a single device on VLAN 10 to access any port of single device on VLAN 20
This rule allows a device with the IP address of 192.168.10.10 on VLAN 10 to access any open service that is running on a device with the IP address of 192.168.20.10 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 a device with the IP address of 192.168.20.10 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.
Block a single device on VLAN 10 from accessing the Internet
If you need to block access to the Internet and to other local networks (such as VLAN 20) for a particular device with the IP address 192.168.10.10 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 |
If you already have your VLANs isolated from one other, access to other local networks is already blocked so this rule essentially adds the block for the Internet.
Note: This rule does not block access for that device for anything inside VLAN 10 because any traffic from one device to another within the same VLAN is considered local traffic and does not go through the router which means none of the firewall rules for VLAN 10 are processed for such traffic.
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 such as 8.8.8.8 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 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 |
Redirect DNS requests on LAN to Unbound DNS using NAT port forwarding
If you wish to redirect all outbound DNS requests on port 53 to your local Unbound DNS resolver, you may create a NAT port forward rule on your LAN network. You will need to go to the “Firewall > NAT > Port Forward” page to add the redirect rule. If you want more information about redirecting DNS requests, please refer to How to Configure WAN and NAT Port Forward Rules in OPNsense.
| Option | Value |
|---|---|
| Interface | LAN |
| Protocol | TCP/UDP |
| Source | any |
| Source Port | any |
| Destination / Invert | Checked |
| Destination | LAN net |
| Destination Port | 53 (DNS) |
| Redirect target IP | 127.0.0.1 |
| Redirect target port | 53 (DNS) |
| Description | Redirect external DNS requests to local DNS resolver |
| Filter rule association | Add associated filter rule (or Pass) |
If you have multiple local networks which you wish to redirect DNS requests, you may create a firewall group by going to the “Firewall > Groups” page and adding all of the appropriate interfaces to the group. This allows you to create a single rule to redirect DNS requests for your entire network. You can reference the group called “MyGroup” like the example below:
| Option | Value |
|---|---|
| Interface | MyGroup |
| Protocol | TCP/UDP |
| Source | any |
| Source Port | any |
| Destination / Invert | Checked |
| Destination | MyGroup net |
| Destination Port | 53 (DNS) |
| Redirect target IP | 127.0.0.1 |
| Redirect target port | 53 (DNS) |
| Description | Redirect external DNS requests to local DNS resolver |
| Filter rule association | Add associated filter rule (or Pass) |
Please note that redirecting unencrypted DNS requests on port 53 does not redirect any DNS requests which are encrypted. If you are not using DNS over TLS, you could block outgoing port 853 in case something is tunneling traffic on that port. Blocking DNS over HTTPS is more difficult because it blends in with other HTTPS traffic so you will have to resort to using less effective techniques such as block lists (unless you use some sort of man-in-the-middle software to decrypt, inspect, and encrypt that traffic but that may introduce potential vulnerabilities).
Redirect NTP requests on LAN to local NTP service using NAT port forwarding
If you wish to redirect all outbound NTP (Network Time Protocol) requests on port 123 to your local Unbound DNS resolver, you may create a NAT port forward rule on your LAN network in the same manner as the DNS redirection. You will need to go to the “Firewall > NAT > Port Forward” page to add the redirect rule:
| Option | Value |
|---|---|
| Interface | LAN |
| Protocol | TCP/UDP |
| Source | any |
| Source Port | any |
| Destination / Invert | Checked |
| Destination | LAN net |
| Destination Port | 123 (NTP) |
| Redirect target IP | 127.0.0.1 |
| Redirect target port | 123 (NTP) |
| Description | Redirect external NTP requests to local NTP service |
| Filter rule association | Add associated filter rule (or Pass) |
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.
Important: When you create a NAT port forward rule, you need to go to the “Filter rule association” at the bottom of the page. By default, it will be set to “None” which means you will not be able to reach your internal server from outside your network. Select “Pass” if you are not using a multi-WAN configuration or “Add associated filter rule” if you are using a multi-WAN configuration or prefer to have a corresponding WAN rule automatically created on the WAN interface. The nice thing about using the “Pass” option is that your WAN rules do not get cluttered with your NAT port forward rules. However, if you prefer to see the rule on the WAN interface, you need to select “Add associated filter rule” so it is visible. You may be used to seeing the rule if you have used other firewalls or perhaps you prefer the convenience of having the rule visible when you are reviewing your WAN rules. I like the idea of having the rule visible because at a glance I can see everything that is open on the WAN interface without also needing to visit the “NAT Port Forward” page.
I have noticed that many users are confused about how to configure port forwarding in OPNsense, but creating the NAT rules are similar to creating other firewall rules for your interfaces. The biggest difference is that you need to enter values for two additional “redirect target” data fields and to select the appropriate “Filter rule association”.
| 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 |
| Filter rule association | Add associated filter rule (or Pass) |
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 as much spam from automated scans or attacks that occur most frequently on the default port.
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.
