os-upnp plugin not working?

Started by Warbreaker, July 16, 2026, 03:12:47 PM

Previous topic - Next topic
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.

Wow, nice find!  Took the liberty to fold this into the ports tree for tomorrow's 26.7.3:

https://github.com/opnsense/ports/commit/2616876aaa


Cheers,
Franco

Quote from: franco on August 26, 2026, 03:03:18 PMWow, nice find!  Took the liberty to fold this into the ports tree for tomorrow's 26.7.3:

https://github.com/opnsense/ports/commit/2616876aaa


Cheers,
Franco

Will this solve the original problem with UPnP plugin with 26.7 or do we still need to manually configure the NAT mode from automatic to hybrid and add a source NAT rule as described as a fix earlier in this thread?

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

Quote from: franco on August 26, 2026, 04:06:46 PMWell 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.

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

Quote from: franco on August 26, 2026, 05:10:38 PMYes, 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. 👍

Sure, why not?  If you can open a "feature request" on https://github.com/opnsense/plugins I can tag the user I mentioned and see what happens.



Cheers,
Franco


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

You cannot view this attachment.

I too am having problems with UPnP. Active maps don't show and despite the ACLs and SNAT rules I can't budge moderate NAT in Call of Duty for example.

Quote from: BondiBlueBalls on August 28, 2026, 03:18:08 PMUPnP is working and displaying the internal IP again following the 26.7.3_x update. 🎉

You cannot view this attachment.

Can you please tell us wich NAT-settings and firewall rules you have set up to get it working except installing the UPnP-plugin. Can you verify that you get "Open NAT"?

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:

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:

allow 1024-65535 10.251.4.20/32 1024-65535

Firewall rule

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

Source:      Games net
Destination: Games address
Port:        upnp_ports

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

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:

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.