Messages

[not]

Still same problem, when second PC tries to connect it gets network error in Call of Duty, as soon as the first PC closes Call of Duty the second PC can connect and vice versa.

Yes, that's exactly what Static Port does. Read the documentation about Endpoint-Independent NAT that I linked a few posts earlier:

In particular, this behavior helps avoid issues with multiple local clients using the same source port to reach the same remote host.

Static port is not the correct setting for gaming clients.

It is if you want to use UPnP reliably. The problem is that EIM can assign a dynamically selected external UDP port while UPnP requests a particular external port. But in this case, I agree. Use EIM and skip UPnP.

[Games]

Here's my current working UPnP setup for comparison. In my case, Games is the VLAN/interface where my PS5 lives, and 10.251.4.20 is the PS5's static/reserved IP, so obviously substitute your own interface, subnet, and device IP as needed.

UPnP settings

UPnP IGD and PCP/NAT-PMP are both enabled. WAN is the external interface and Games is the only internal interface.

I'm using:

Code Select Expand

UPnP IGD compatibility: IGDv1 (IPv4 only)
Allow third-party mapping: Disabled
Disable IPv6 mapping: Enabled

The other advanced options are left at their defaults.

Access Control List

I have Default deny enabled with a single ACL entry allowing only the PS5:

Code Select Expand

allow 1024-65535 10.251.4.20/32 1024-65535

Firewall rule

On the Games interface, I have a TCP/UDP rule allowing:

Code Select Expand

Source:      Games net
Destination: Games address
Port:        upnp_ports

The upnp_ports alias is a Port(s) alias containing:

Code Select Expand

1900
2189
5351

That firewall rule is above my RFC1918 block rule so clients on the Games network can actually reach the UPnP daemon.

Outbound NAT

I'm using Hybrid outbound NAT with a manual WAN rule for the Games network:

Code Select Expand

Interface:   WAN
Source:      Games net
Destination: any
NAT address: Interface address
Static Port: YES

The Proton VPN rule shown in the screenshot is unrelated to UPnP, as are the automatically generated rules below it.

With this setup, UPnP mappings are working correctly for me. Yes, I'm seeing "NAT type: Open" in MW3.

UPnP is working and displaying the internal IP again following the 26.7.3_x update. 🎉

You cannot view this attachment.

Opened the feature request here: https://github.com/opnsense/plugins/issues/5674. Thanks again!

Yes, I'd like to review and help shape the effort. But I have to say that I don't have a lot of time these days so this could be a longer effort.

The person who did the recent updates on the plugin and port was also open to this direction.

Eventually it has to be done either way as we aim to remove the static PHP pages within the next five years.


Cheers,
Franco

I'd be happy to help if an extra set of hands would be useful. 👍

Well to answer the other question first: the plugin is in community support mode and the code is still based on the static PHP pages. It's not going to get a lot of maintenance, but if patches exist like here we can do something about it.

About the NAT rule I'm not sure.  The built-in automatic rule no longer works?  Why?  This wasn't changed so it may be a FreeBSD change.  But it's also possible for people who still have a 26.1.x to test to compare the /tmp/rules.debug file to see if anything shifted between versions, which I doubt a bit, but not impossible.


Cheers,
Franco

Out of curiosity, would you be open to a community-driven migration of os-upnp to the newer MVC framework? I'd be interested in taking a look at it, but I'd want to make sure that's a direction you'd actually want before going too far down that road.

I dug into the `?` showing up for the redirect target a bit more, and it looks like the actual problem is upstream in miniupnpd rather than the OPNsense plugin itself.

Basically, miniupnpd isn't setting the address family on the PF pool address when it creates the rule. Older PF behavior hid that, but the newer PF/pfctl changes in 26.7 expose it as `?` even though the mapping itself still works.

I submitted a small upstream fix here:

https://github.com/miniupnp/miniupnp/pull/906

It's only a two-line change at the two affected `DIOCADDADDR` call sites. If it gets accepted and eventually makes its way into OPNsense, the existing UPnP plugin should start showing the correct IPs again without needing any changes to the plugin itself.

Figured I'd post it here in case anyone else was following the same issue.

I did some additional testing after reading the discussion above about the -> ? output from pfctl, particularly the suggestion that this indicates the redirect has no valid translation target.

In my case, I don't think that interpretation is correct.

I'm running OPNsense 26.7.2_2 with os-upnp, and a PS5 on my Games VLAN is creating the following UDP 3074 mapping via UPnP:

Code Select Expand

nat quick on ixl2 inet proto udp from 10.251.4.20 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> ? port 3074

rdr pass quick on ixl2 inet proto udp from any to any port = 3074 keep state label "DemonwarePortMapping" rtable 0 -> ? port 3074

Call of Duty reports the mapping as:

Code Select Expand

External: WAN_IP:3074
Internal: 10.251.4.20:3074
NAT Type: Open

However, since an "Open" NAT result alone doesn't necessarily prove that unsolicited inbound traffic is actually traversing the UPnP-created redirect, I tested it directly.

I started simultaneous packet captures on the WAN interface and the Games VLAN. I then connected a Mac to a cellular hotspot, completely outside my home network, and sent UDP packets to WAN_IP:3074.

One of the test packets arrived on WAN as:

Code Select Expand

CELLULAR_IP:3880 > WAN_IP:3074
IP ID 21475
UDP length 10
TTL 47

The corresponding packet appeared on the Games VLAN as:

Code Select Expand

CELLULAR_IP:3880 > 10.251.4.20:3074
IP ID 21475
UDP length 10
TTL 46

The same result occurred repeatedly with subsequent test packets.

The matching source address/port, IP ID, and UDP length make it clear that these are the same packets. The destination changes from WAN_IP:3074 on the WAN side to 10.251.4.20:3074 on the Games VLAN, and the TTL decreases by one as expected when the packet is routed.

So in this configuration, PF is demonstrably performing the UPnP-created RDR successfully even though:

Code Select Expand

pfctl -P -a miniupnpd -s nat

displays the translation target as:

Code Select Expand

-> ?

There may certainly be other UPnP issues affecting other configurations, but -> ? by itself does not appear to mean that the redirect is invalid or nonfunctional. At least here, it appears to be an output/introspection issue rather than a failure of the PF data path.

I've also added the packet-capture findings to the corresponding OPNsense plugins issue:

https://github.com/opnsense/plugins/issues/5635

I upgraded from 26.1.11_10 to 26.7.1_1 today and wanted to share a positive data point.

My PS5 is working normally with UPnP. After starting Modern Warfare 3, OPNsense created the expected UPnP mappings (including UDP 3074), and MW3 reports NAT Type: Open.

I do still see the "?" in the IP address column under Services -> UPnP IGD & PCP -> Active Maps, but it appears to be cosmetic. The mappings are functional and the game reports Open NAT.

For reference, my setup uses:
- os-upnp plugin
- Hybrid Source NAT
- Manual Static Port rule for my gaming network
- Firewall rule allowing my Games VLAN to reach the UPnP daemon on the firewall

Hopefully that helps distinguish the UI issue from any actual UPnP functionality issues.

I saw the same logs during or immediately after the 26.1.3 update, but nothing since. UPnP continues to work fine with my PS5. Not sure if this helps, but figured additional data wouldn't hurt. Thanks!

Code Select Expand

2026-03-05T13:16:00-06:00 Error miniupnpd could not open lease file: /var/run/miniupnpd.leases-ipv6
2026-03-05T13:16:00-06:00 Error miniupnpd could not open lease file: /var/run/miniupnpd.leases
2026-03-05T13:15:57-06:00 Error miniupnpd could not open lease file: /var/run/miniupnpd.leases-ipv6
2026-03-05T13:15:57-06:00 Error miniupnpd could not open lease file: /var/run/miniupnpd.leases


That is not likely to happen

Proton does allow opening a randomized port but it is very difficult to set up and the port can change any time. 

I have a tool that will manage the port from Proton and sync it to OPNsense. It will optionally manage the forwarded port in qBittorrent, too. I've been running various iterations of it for two years without issue. https://github.com/clajiness/qbop

Hey, all. I'm not sure if this meets your needs, but I wrote a little script that grabs the forwarded port from protonvpn and syncs it with OPNsense and qBittorrent. It's been keeping everything running perfectly for me for over a year. Hope it helps! https://github.com/clajiness/qbop

What are you trying to modify, specifically? If you're trying to update the forwarded port (which seems the likely case), set an alias and update that.

Here's some Ruby code I wrote a while back to get the job done. This class can grab the UUID of the alias, find the value, set it to whatever you like, and then apply it.

Good luck!

Code Select Expand


module Service
  class Opnsense
    def get_alias_uuid(config)
      uri = URI("#{config['opnsense_interface_addr']}/api/firewall/alias/getAliasUUID/#{config['opnsense_alias_name']}")

      # Create client
      http = Net::HTTP.new(uri.host, uri.port)
      http.use_ssl = true
      http.verify_mode = OpenSSL::SSL::VERIFY_NONE

      # Create Request
      req =  Net::HTTP::Get.new(uri)
      req.basic_auth config["opnsense_api_key"], config["opnsense_api_secret"]

      # Fetch Request
      res = http.request(req)
      JSON.parse(res.body)["uuid"]
    rescue StandardError => e
      @logger.error("get_alias_uuid - HTTP Request failed - (#{e.message})")
    end

    def get_alias_value(config, uuid)
      uri = URI("#{config['opnsense_interface_addr']}/api/firewall/alias/get")

      # Create client
      http = Net::HTTP.new(uri.host, uri.port)
      http.use_ssl = true
      http.verify_mode = OpenSSL::SSL::VERIFY_NONE

      # Create Request
      req =  Net::HTTP::Get.new(uri)
      req.basic_auth config["opnsense_api_key"], config["opnsense_api_secret"]

      # Fetch Request
      res = http.request(req)

      alias_content = JSON.parse(res.body).dig("alias", "aliases", "alias", uuid, "content")
      alias_content.values[0]["value"].to_i
    rescue StandardError => e
      @logger.error("get_alias_value - HTTP Request failed - (#{e.message})")
    end

    def set_alias_value(config, forwarded_port, uuid)
      uri = URI("#{config['opnsense_interface_addr']}/api/firewall/alias/setItem/#{uuid}")

      # Create client
      http = Net::HTTP.new(uri.host, uri.port)
      http.use_ssl = true
      http.verify_mode = OpenSSL::SSL::VERIFY_NONE
      body = {"alias": {"content": forwarded_port}}.to_json

      # Create Request
      req =  Net::HTTP::Post.new(uri)
      # Add headers
      req.basic_auth config["opnsense_api_key"], config["opnsense_api_secret"]
      # Add headers
      req.add_field "Content-Type", "application/json; charset=utf-8"
      # Set body
      req.body = body

      # Fetch Request
      http.request(req)
    rescue StandardError => e
      @logger.error("set_alias_value - HTTP Request failed - (#{e.message})")
    end

    def apply_changes(config)
      uri = URI("#{config['opnsense_interface_addr']}/api/firewall/alias/reconfigure")

      # Create client
      http = Net::HTTP.new(uri.host, uri.port)
      http.use_ssl = true
      http.verify_mode = OpenSSL::SSL::VERIFY_NONE

      # Create Request
      req =  Net::HTTP::Post.new(uri)
      # Add headers
      req.basic_auth config["opnsense_api_key"], config["opnsense_api_secret"]

      # Fetch Request
      http.request(req)
    rescue StandardError => e
      @logger.error("apply_changes - HTTP Request failed - (#{e.message})")
    end
  end
end


For the sake of having another data point, I figured I'd report back. I ran the opnsense-revert command, restarted the service, and everything works perfectly.

Thanks much for everything! It's much appreciated.

Will the updated code be included in 24.1.9? Also, thank you!