os-upnp plugin not working?

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

Previous topic - Next topic
Quote from: Warbreaker on July 20, 2026, 08:00:36 PMI finally got it working.

I added this "Source NAT" rule:
https://www.pasteboard.co/lTHlqpZ_SWPY.png

Is this rule required now for getting UPnP IGD & PCP back to work? Why? I am facing the same issue. Active mappings with IP address ?.

Quote from: bamf on July 21, 2026, 10:52:31 PM
Quote from: Warbreaker on July 20, 2026, 08:00:36 PMI finally got it working.

I added this "Source NAT" rule:
https://www.pasteboard.co/lTHlqpZ_SWPY.png

Is this rule required now for getting UPnP IGD & PCP back to work? Why? I am facing the same issue. Active mappings with IP address ?.
It's always been my understanding that it's required, I always used an outbound NAT rule, and since the new firewall stuff came in that moved over to source NAT. So I migrated the rule before upgrading to 26.7 and my upnp stuff is working fine. The only issue is the UI glitch in the active maps section showing question marks instead of IP addresses, but I suspect that will be addressed with an update for the plugin.

Quote from: bamf on July 21, 2026, 10:52:31 PM
Quote from: Warbreaker on July 20, 2026, 08:00:36 PMI finally got it working.

I added this "Source NAT" rule:
https://www.pasteboard.co/lTHlqpZ_SWPY.png

Is this rule required now for getting UPnP IGD & PCP back to work? Why? I am facing the same issue. Active mappings with IP address ?.

It seems that way now, I didn't need it on 26.1 but the reason of why it was working is unknown to me, but now you do need it with 26.7

Anyone else with this issue on 26.7?
2026-07-22T12:25:02
Error
miniupnpd
could not open lease file: /var/run/miniupnpd.leases-ipv6
2026-07-22T12:25:02
Error
miniupnpd
could not open lease file: /var/run/miniupnpd.leases

Quote from: Warbreaker on July 22, 2026, 10:12:52 AMIt seems that way now, I didn't need it on 26.1 but the reason of why it was working is unknown to me, but now you do need it with 26.7
IMHO you found a bug, because why would you need both of them when uPnP does more than a Source NAT Rule with Strict-port Enabled does : It completely opens the port like a Port Forward a.k.a. Destination NAT Rule would :)
Weird guy who likes everything Linux and *BSD on PC/Laptop/Tablet/Mobile and funny little ARM based boards :)

Quote from: nero355 on July 22, 2026, 06:44:07 PMIMHO you found a bug, because why would you need both of them when uPnP does more than a Source NAT Rule with Strict-port Enabled does : It completely opens the port like a Port Forward a.k.a. Destination NAT Rule would :)

I'm sort of new to OPNSense, I started using OPNSense somewhere around 26.1.x, in my new installation back then I migrated to the new rules set because of a message I read that legacy would go away, so maybe the bug I found was with the new rules set? either way I can't recall having to do anything other than the Source NAT change from Automatic to Hybrid.

Quote from: nero355 on July 22, 2026, 06:44:07 PM
Quote from: Warbreaker on July 22, 2026, 10:12:52 AMIt seems that way now, I didn't need it on 26.1 but the reason of why it was working is unknown to me, but now you do need it with 26.7
IMHO you found a bug, because why would you need both of them when uPnP does more than a Source NAT Rule with Strict-port Enabled does : It completely opens the port like a Port Forward a.k.a. Destination NAT Rule would :)
I mean, even on previous releases, if I didn't have the rule things would complain about strict NAT. With the rule all is fine. I've never gotten the UPNP plugin to give "open NAT" on OPNSense, pretty sure it's not possible in the current releases, but moderate is sufficient to get games to stop complaining so meh.

Quote from: Warbreaker on July 22, 2026, 07:43:52 PM
Quote from: nero355 on July 22, 2026, 06:44:07 PMIMHO you found a bug, because why would you need both of them when uPnP does more than a Source NAT Rule with Strict-port Enabled does : It completely opens the port like a Port Forward a.k.a. Destination NAT Rule would :)

I'm sort of new to OPNSense, I started using OPNSense somewhere around 26.1.x, in my new installation back then I migrated to the new rules set because of a message I read that legacy would go away, so maybe the bug I found was with the new rules set?
Are you talking about Firewall Rules or NAT Rules ?!

IMHO the migration from Firewall Rules (Legacy) to Firewall Rules [New] that was more or less the thing to do before upgrading from 26.1.x to 26.7.x to avoid issues and should not have any affect to this whole story.

However the migration from Outbound NAT Rules to Source NAT Rules that's now a thing during the 26.7.x Release and should IMHO be done before the upgrade to 27.1.x in January 2027 could indeed have some kind of bug related to Strict-port since it was added a bit later after the whole new Source NAT section was added to 26.1.x :)

Quoteeither way I can't recall having to do anything other than the Source NAT change from Automatic to Hybrid.
Hybrid NAT Rules Mode is mandatory when adding your own Source NAT Rules so that's good!

Quote from: Chris123NT on July 23, 2026, 01:54:01 AMbut moderate is sufficient to get games to stop complaining so meh.
Exactly! :)
Weird guy who likes everything Linux and *BSD on PC/Laptop/Tablet/Mobile and funny little ARM based boards :)

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.

Today at 02:48:34 PM #24 Last Edit: Today at 03:01:43 PM by Warbreaker
Quote from: nero355 on July 23, 2026, 04:02:12 PM
Quote from: Warbreaker on July 22, 2026, 07:43:52 PMIMHO you found a bug, because why would you need both of them when uPnP does more than a Source NAT Rule with Strict-port Enabled does : It completely opens the port like a Port Forward a.k.a. Destination NAT Rule would :)

I'm sort of new to OPNSense, I started using OPNSense somewhere around 26.1.x, in my new installation back then I migrated to the new rules set because of a message I read that legacy would go away, so maybe the bug I found was with the new rules set?
Are you talking about Firewall Rules or NAT Rules ?!

IMHO the migration from Firewall Rules (Legacy) to Firewall Rules [New] that was more or less the thing to do before upgrading from 26.1.x to 26.7.x to avoid issues and should not have any affect to this whole story.

However the migration from Outbound NAT Rules to Source NAT Rules that's now a thing during the 26.7.x Release and should IMHO be done before the upgrade to 27.1.x in January 2027 could indeed have some kind of bug related to Strict-port since it was added a bit later after the whole new Source NAT section was added to 26.1.x :)

Sorry I missed your question, let me list in order the things I did in 26.1:
  • I migrated from legacy to the new firewall rules set when I installed 26.1
  • When I installed uPnP I converted the NAT mode from automatic to hybrid
  • I did not do anything related to firewall or NAT when I migrated to 26.7, no conversion (it was already converted), but my destination NAT firewall rules seem to work, I have a DNS and time server redirect that are still working from 26.1, but they were created after I migrated to the new firewall rules set
  • Once I moved to 26.7 a bit later I added the source NAT rule so uPnP would work again so now everything is working, only the "?" source IP bug on the uPnP when listing the current mappings