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). If you run OpenVPN or WireGuard in OPNsense, you will want a WAN rule. If you have a Plex Media Server or Nextcloud on a server in your network and want to open access to the outside world, you will want a NAT Port Forward rule.
One example of a WAN rule would be to access your WireGuard VPN running on OPNsense. Go to the “Firewall > Rules > [WAN]” page. The “Action” should be “Pass” to allow the connection. “WAN” should be already set in the “Interface” dropdown since you are on the WAN interface firewall rule page. The “Protocol” is “UDP” for WireGuard. WAN rules typically use “WAN address” as the “Destination” since “WAN address” refers to your public IP address (if it is your main router plugged into your modem). When accessing the service on your router remotely, the public facing address is the destination address. The WireGuard default port is 51820.
That is pretty much it for the WAN rule! (Note that WireGuard requires more configuration than the WAN rule such adding the outbound NAT rule, but this example is just for illustration purposes).
NAT Port Forward Rule
A NAT port forward rule allows you to host a service inside your network such as a web server. Go to the “Firewall > Rules > NAT > Port Forward” page to create a NAT port forward rule. In the example below, assume there is a web server in the DMZ network. Like with the WAN rule, the WAN interface will be the default selection for the “Interface” dropdown. The first several options are identical to the WAN rule except the port is HTTPS for the web server. You will notice a couple of options for the “Redirect target IP” and the “Redirect target port”. That is the IP/port of your internal server. In this case, it is 192.168.1.10 on port HTTPS (443).
Important: The only remaining option you need to make sure you set is the “Filter rule association”. Set it to “Add associated rule” if you wish to see the automatically generated WAN rule or to “Pass” if you prefer to see only the NAT port forward rule (you cannot use “Pass” in multi-WAN situations according to the OPNsense documentation). It is very important that you do not have this option set to “None” because the port forward rule will not work properly. If you use “None”, you would have to create a WAN rule manually for the NAT port forward rule to be fully functional.
As you can see, creating a NAT port forward rule is not much more difficult than a WAN rule. There are a few extra options that need to be set, but the rest is the same as a WAN rule.
If you go to the “Firewall > Rules > [WAN]” page, you should see a rule that is generated and not editable (if you chose “Add associated rule” rather than “Pass” when you created the port forward rule).
When you first create the NAT port forward rule, you will notice 4 options in the “Filter rule association” dropdown: “None”, “Add associated filter rule”, “Add unassociated filter rule”, and “Pass”. However, if you select “None” or “Pass” when you created the rule, you will only see “None” and “Pass” as possible options. If you want the corresponding WAN rule to be visible on the WAN firewall rule page, you would need to recreate the NAT port forward rule. Also, if you select one of the “Add filter rule” options when you created the rule, you will see “None”, “Pass”, and “Rule [plus the description of your rule]” as the possible filter rule association options.