OPNsense port forwarding was renamed in 26.1, and the page is now Firewall > NAT > Destination NAT. A working forward takes two pieces: the Destination NAT rule that redirects traffic to your server, and a firewall rule that lets it in (unless the NAT rule’s Firewall rule field is set to Pass or Register rule). The menus below are OPNsense 26.7.8’s, the current release as of October 2026.
On a basic router, a port forward is one form, which is why this can be confusing: the NAT rule and the firewall rule are separate things. Create only the NAT rule, on its default setting, and the service won’t be reachable. Both are covered below, plus what to check when an OPNsense port forward still won’t open.
What is Port Forwarding?
Port forwarding exposes a service on your local network to the outside world, so someone outside can reach it at your external IP address, a DDNS hostname or a domain name, plus the port. As the OPNsense manual explains it, an inbound connection to a shared external IP fails because the firewall doesn’t know where to send it, and a port forwarding rule tells it.
- HTTP: TCP port 80.
- HTTPS: TCP port 443, the one most people open, for a website or a reverse proxy in front of several web services.
- VPN: UDP port 1194 for OpenVPN or UDP port 51820 for WireGuard.
The steps are the same whatever you’re exposing (a game server, Plex or remote desktop), and only the port and the protocol change.
Before you forward anything, ask whether you need to. For most people, a VPN is the safer way in, because you expose one VPN instead of each service, and every connection has to authenticate first. You can run a WireGuard VPN server in OPNsense, set up Tailscale on OPNsense or use OpenVPN and a Raspberry Pi. For web apps that aren’t streaming media, a Cloudflare Tunnel with Docker does not need a port forward at all.
If you do have to forward something, limit that access as much as you possibly can, because as the manual says, “Network Address Translation should not be relied upon as a security measure.” How to make your home lab more secure covers the rest.
OPNsense 26.1 Port Forwarding: Now Destination NAT
If Port Forward isn’t in your menu, it was renamed. OPNsense 26.1, released January 28, 2026, moved what older guides call an OPNsense NAT port forward to Firewall > NAT > Destination NAT. The OPNsense 26.1 release notes put it plainly: “Firewall: NAT: Port Forwarding is now called “Destination NAT”.” (The manual calls the feature “Destination NAT (Port Forward)”.)
The same release removed the Filter rule association option: “Firewall rule associations are no longer supported, but the old associated firewall rules remain in place with their last known configuration and can now be edited to suit future needs.” So forwards from before the upgrade are now OPNsense Destination NAT rules, and their old linked firewall rules stay behind as legacy rules.
OPNsense 26.7 (July 15, 2026) made the newer rules page the default at Firewall > Rules (Rules [new] on 26.1.x) and moved the old static pages to the optional os-firewall-legacy plugin. Legacy rules keep working either way, but on 26.7 you edit them only with the plugin or after you export and re-import them using Firewall > Migration assistant. On 25.7 or earlier you’ll still see Firewall > NAT > Port Forward and the Filter rule association field, so update first if you can.
How to Port Forward in OPNsense
To create an OPNsense port forward, you build the Destination NAT rule first. The form runs in sections (Organization, Interface, Source, Destination, Translation, Options and Audit), and the steps follow that order.
1. Log in to OPNsense, select Firewall, then NAT, and finally, Destination NAT. Select + to create a rule.
2. Under Organization, enter a Description that names the service.
3. Under Interface, set Interface to WAN, Version to IPv4, and Protocol to what the service uses, generally TCP, UDP or TCP/UDP.
4. Under Source (Source (advanced), collapsed, before 26.7.8), leave Source Address empty or at any, or limit it to the addresses that should connect, and Source Port at any.
5. Under Destination, set Destination Address to WAN address. In Destination Port, choose Single port or range and enter the public port.
6. Under Translation, enter the server’s local IP address in Redirect Target IP. In Redirect Target Port, choose Single port and enter its port. For a range, enter the first target port and OPNsense calculates the rest.
7. Under Options, check Log to watch the rule match while you test, and leave Firewall rule at Manual (the next section covers the other options).
8. Select Save, then Apply.
The OPNsense default port for the web GUI is 443, since it ships on HTTPS (https://192.168.1.1/ on a fresh install) with port 80 redirecting to it. If other services should answer on 80 or 443 of the external IP, you can move the GUI with TCP port under System > Settings > Administration. Then check Disable web GUI redirect rule, or port 80 keeps redirecting to the GUI.
Firewall Rules for OPNsense Port Forwarding
A port forward also needs a pass rule on WAN to the internal IP and port. The NAT rule’s Firewall rule field decides whether OPNsense makes it for you, but the vendor’s text disagrees on which option to use. The form’s help calls creating rules manually “the advised option”, while the manual’s note on Pass calls it the “Recommended choice for most setups.”
| Option | What it does | Can you edit the firewall rule? |
|---|---|---|
| Manual (default) | “No linked rule is created.” | Yes, you write it |
| Pass | “A firewall rule will be automatically added and updated.” | No: “This rule cannot be seen or edited in Firewall Rules.” |
| Register rule | “Adds a linked rule in Firewall Rules that is automatically updated when the NAT rule is updated.” | No: “The created firewall rule cannot be manually edited.” |
Manual is the pick here: it’s the default, the form advises it, and only its firewall rule can be edited. A Register rule shows up in the rules view for its interface (or under Floating with more than one interface), but you can’t change it.
Pass has one side effect: NAT rules are processed before filter rules, and the firewall manual warns that with Pass “no other rules will apply.” A later block rule won’t stop that traffic. If you use Pass, limit who can connect with the NAT rule’s own Source Address.
How to Create the Firewall Rule Manually
1. Select Firewall, then Rules (Rules [new] on 26.1.x), and choose WAN in the interface filter, so a new rule gets WAN filled in.
2. Add a rule, enter a Description, leave Interface (rule) (Interface before 26.7.3) at WAN, Action at Pass, Direction at In and Version at IPv4, and set Protocol to match the NAT rule.
3. Set Source to the addresses that should connect, if you can.
4. Set Destination to Single host or Network with the Redirect Target IP, and Destination Port to Single port or range with the Redirect Target Port, not the WAN address, because NAT has already translated the traffic.
5. Check Log, select Save, then Apply.
With both rules in place, test from a device outside your network (a phone on cellular, not Wi-Fi). Connect to your external IP or a hostname from DDNS on OPNsense. With Log on in both, Firewall > Log Files > Live View shows whether the rules match, and NAT rules are labelled “NAT” or “RDR”.
The firewall rules in the OPNsense manual cover every field.
A rule limited to known IP addresses beats one open to everyone.
OPNsense Port Forwarding Not Working
If the forward doesn’t work on 26.7 or any 26.1 release, go down this list.
- The changes weren’t applied. Select Apply on the Destination NAT and Rules pages, since Save alone doesn’t load a rule.
- You’re testing from inside. NAT reflection is off by default (Firewall > Settings > Advanced, Reflection for destination NAT), and each rule has its own NAT Reflection setting in advanced mode. It doesn’t create firewall rules, and the manual calls the automatic methods “not advised”, so test from outside instead.
- You’re testing from the network in front of OPNsense. WAN ships with Block private networks on, which blocks RFC 1918, loopback, link-local and carrier-grade NAT source addresses.
- The WAN address isn’t public. If it’s in 100.64.0.0/10 (carrier-grade NAT, RFC 6598) or a private range, the internet can’t reach it directly, so a forward on OPNsense alone isn’t enough.
- There’s no firewall rule. Manual is the default, so a NAT rule without a matching firewall rule hits the default deny.
- The firewall rule points at the WAN address. Its Destination has to be the internal host and port, because NAT matches first.
- Another rule matches first. Floating rules run first, then interface groups, then interface rules, and with Quick on (the default) the first match wins. With Pass on the NAT rule, no later rule applies at all.
- A port range or name is rejected. Several 26.1.x and 26.7.x updates fixed how ranges and well-known port names are handled, so update to the current release.
- Nothing reaches the server. In a packet capture (Interfaces > Diagnostics > Packet Capture), TCP SYN with no SYN ACK means the connection isn’t being established and the rules are wrong (or the service isn’t listening).
Port forwarding puts a service on the internet, so keep the source narrow, keep OPNsense and the server behind it updated, and use a VPN where it does the job. Security changes all the time, and nothing here guarantees that a service is safe once it’s exposed.
