I moved to 26.7, my old firewall rules in 26.1 was already moved to the new rules set format so I imagine that's good on 26.7
But when I look at UPnP mappings I see this:
IP address Port External port Protocol Remote IP Remote port Added via / description
? 22419 22419 UDP any any UPnP IGD / DemonwarePortMapping
No IP address and it seems to not be working (My son is my tester with Destiny 2 complaining about strict NAT), it was working on 26.1
Quote from: Warbreaker on July 16, 2026, 03:12:47 PM(My son is my tester with Destiny 2 complaining about strict NAT)
Configure the following for him :
- Static DHCP IP Address Mapping based on the MAC Address of his PC/Console.
- Enter that IP Address in a new Alias called GAMING_Clients or something like that.
- Switch to Hybrid NAT Mode
- Create a Manual NAT Rule with Strict-port Enabled and as Source the Alias GAMING_Clients.
He will now always at least have Moderated NAT and could even continue gaming without uPnP Enabled :)
I will probably do that at some point, but thought on reporting it as well, either something is broken or the stronger rules on 26.7 is making the old plugin not work at all, for security reasons of course I have only one ACL on my UPnP plugin to just allow non privileged ports to be bound.
It would be interesting to know why it isn't working anymore.
So i've been battling this today, oddly Destiny 2 was my guinea pig too lol
So as far is i can tell miniupnpd seems to struggle to bind the client IP to the port request, now if i roll back to my deployment of 26.1.x this is a non issue. The unfortunate thing also though is i found the stuggestion nero gave to not work either which is odd.
I have yet to go down the port forward route yet mostly because if that works i'll shelf opnsense in favour of another router as i don't have the time or the will to map all the ports of every game that gets played in this house lol.
I have different network segments for different tasks (IoT, Servers, Gaming, Work etc) because i'm lazy uPnP is excellent for the gaming segment (a cheeky /29 subnet) as there are no access rules to other VLANs from there so it can go mental for all I care (before some karen shouts about security and how uPnP is a infiltration waiting to happen).
But judging on how the intel microcode plugin is causing issues i'm just going to assume it's a bug in the network stack somewhere and wait to see what happens maybe the kids will go outside for once.........
Quote from: Baron_Backdoor on July 18, 2026, 08:58:12 PMThe unfortunate thing also though is i found the stuggestion nero gave to not work either which is odd.
Hmm... that sucks... :'(
Did you check https://docs.opnsense.org/ to make sure you have not missed anything ?
My post was more a quick guide line than an actual HowTo :)
QuoteI have yet to go down the port forward route yet mostly because if that works i'll shelf opnsense in favour of another router as i don't have the time or the will to map all the ports of every game that gets played in this house lol.
That sucks indeed and is something I would never do either!
QuoteI have different network segments for different tasks (IoT, Servers, Gaming, Work etc) because i'm lazy uPnP is excellent for the gaming segment (a cheeky /29 subnet) as there are no access rules to other VLANs from there so it can go mental for all I care (before some karen shouts about security and how uPnP is a infiltration waiting to happen).
This "Karen"
APPROVES!!! ;)
QuoteBut judging on how the intel microcode plugin is causing issues i'm just going to assume it's a bug in the network stack somewhere and wait to see what happens maybe the kids will go outside for once.........
LOL! NICE! ^_^
Confirming issues immediately after an upgrade to 26.7 as well
It seems to be partially working though, as some entries/mappings are being made. And now the "IP address" column is just showing "?" for all entries, instead of the local IP as in previous versions. Not sure if that could help point the finger at the actual issue
Quote from: poeBaer on July 18, 2026, 11:38:46 PMConfirming issues immediately after an upgrade to 26.7 as well
It seems to be partially working though, as some entries/mappings are being made. And now the "IP address" column is just showing "?" for all entries, instead of the local IP as in previous versions. Not sure if that could help point the finger at the actual issue
This is exactly what's happening to me, the IP address column is just ? and while it attempts to add entries to the firewall, uPnP is failing to do so.
I already had migrated my old firewall rules in 26.1 to the new rules set and all of my other rules are working as expected, the firewall seems fine, including my port 53 and 123 interception for the firewall own services.
So for now I just disabled the service until it is confirmed is fixed, but glad it wasn't just a me issue ;-)
Quote from: Warbreaker on July 19, 2026, 12:41:58 PMQuote from: poeBaer on July 18, 2026, 11:38:46 PMConfirming issues immediately after an upgrade to 26.7 as well
It seems to be partially working though, as some entries/mappings are being made. And now the "IP address" column is just showing "?" for all entries, instead of the local IP as in previous versions. Not sure if that could help point the finger at the actual issue
This is exactly what's happening to me, the IP address column is just ? and while it attempts to add entries to the firewall, uPnP is failing to do so.
I already had migrated my old firewall rules in 26.1 to the new rules set and all of my other rules are working as expected, the firewall seems fine, including my port 53 and 123 interception for the firewall own services.
So for now I just disabled the service until it is confirmed is fixed, but glad it wasn't just a me issue ;-)
I'm seeing the ? under IP as well, but my firewall DOES seem to be creating the maps. My plex server and my girlfriend's PC have both managed to create maps and I've verified the ports are indeed open. Do you have Source NAT configured for static port? I migrated that from the old Outbound NAT section on 26.1 before upgrading and things seem to be operating correctly, despite the visual glitch in the UPNP service page.
Quote from: Chris123NT on July 20, 2026, 01:31:11 AMI migrated that from the old Outbound NAT section on 26.1 before upgrading and things seem to be operating correctly, despite the visual glitch in the UPNP service page.
In the past when I installed OPNSense back in 26.1 I migrated to the new firewall rules.
I had my source NAT configured as Hybrid in 26.1 and it was working for 26.1, in 26.7 it is in Hybrid mode too, besides the visual glitch, was there something I needed to do?
My understanding is that I had already made the modifications required, but maybe I missed something?
My test subject is my son's Destiny 2 and that stopped working for 26.7, I mean you can NAT but you cannot map ports properly, they show as mapped but no IP address and Destiny complains about it so it is not working as it was in 26.1
Quote from: Warbreaker on July 20, 2026, 10:26:50 AMQuote from: Chris123NT on July 20, 2026, 01:31:11 AMI migrated that from the old Outbound NAT section on 26.1 before upgrading and things seem to be operating correctly, despite the visual glitch in the UPNP service page.
In the past when I installed OPNSense back in 26.1 I migrated to the new firewall rules.
I had my source NAT configured as Hybrid in 26.1 and it was working for 26.1, in 26.7 it is in Hybrid mode too, besides the visual glitch, was there something I needed to do?
My understanding is that I had already made the modifications required, but maybe I missed something?
My test subject is my son's Destiny 2 and that stopped working for 26.7, I mean you can NAT but you cannot map ports properly, they show as mapped but no IP address and Destiny complains about it so it is not working as it was in 26.1
No, you did everything correctly, source NAT with hybrid rules, and you set Static port right? That last bit is important to get things to stop complaining. Like I said, I am also seeing the ? instead of an IP under maps but I verified multiple times with multiple different games/software that the ports ARE opening and being routed to the correct PCs. If I remember from back when I played Destiny 2 like 10 years ago, I had to go through a whole song and dance to make that game work with PFSense, I have ACL rules set up in the UPNP plugin because I seem to remember that being the trick with PFSense but I'm not sure if that's doing anything here.
As far as I can tell it's working other than the visual bug, at least it's passing the girlfriend test so I don't have to explain why the internet is messed up lol.
Quote from: Chris123NT on July 20, 2026, 04:20:12 PMand you set Static port right?
What is this last bit exactly? Maybe is something silly I haven't done or did before but need to redo for 26.7
facing the same thing. Migrated from 26.1.10 and I get the "?" as well, BUT, it seems PS5 /qbttorent/others are still being mapped and working correctly.
Quote from: Warbreaker on July 20, 2026, 05:39:41 PMQuote from: Chris123NT on July 20, 2026, 04:20:12 PMand you set Static port right?
What is this last bit exactly? Maybe is something silly I haven't done or did before but need to redo for 26.7
I believe I had to tick on the advanced options in the source nat rule while creating it, but it's a check box called static port.
I finally got it working.
I added this "Source NAT" rule:
https://www.pasteboard.co/lTHlqpZ_SWPY.png
And I guess combined with this UPnP rule it should only bind non privileged ports, it should be good:
https://www.pasteboard.co/rmGUkErct6gE.png
Note: I can't make images work on this forum for some reason.
Quote from: Warbreaker on July 20, 2026, 05:39:41 PMQuote from: Chris123NT on July 20, 2026, 04:20:12 PMand you set Static port right?
What is this last bit exactly? Maybe is something silly I haven't done or did before but need to redo for 26.7
Static-port makes sure all used ports are mapped 1:1 instead of the default 1:random while doing NAT for IPv4 traffic.
So let's say your average game needs something like this :
LAN IP Address 192.168.1.123:27001
Processed by NAT to
WAN IP Address 68.54.148.89:27001
Strict-port will make sure that actually happens!
And that's when the game will show Moderate NAT as Status :)
Because the default is something like this :
LAN IP Address 192.168.1.123:27001
Processed by NAT to
WAN IP Address 68.54.148.89:56789
And that's when Strict NAT messages start to appear... :(
If you want Open NAT or whatever it's called these days ("Better than Moderate NAT") then you need to Port Forward all used ports (Which I am strongly against!) or use something like uPnP Dynamic Port Mapping like you are already doing.
(Which I don't like either, but some Console Gamers simply don't want to live without it for whatever reason ?!)
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 PMQuote 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 PMQuote 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 :)
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 PMQuote 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 PMQuote 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! :)
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.
Quote from: nero355 on July 23, 2026, 04:02:12 PMQuote 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
So is the issue with the missing ip address going to be fixed or is this whole feature abandoned?
Hi,
I wanted to share my experience because I regularly use this plugin, and it worked perfectly before.
The plugin currently appears to be broken, at least on my OPNsense 26.7.2_2 installation with os-upnp 1.9 and miniupnpd 2.3.9_2.
A PlayStation, Xbox, or another device reporting NAT Type 2, Moderate NAT, or Open NAT does not prove that UPnP is working correctly. The reported NAT type can result from normal outbound NAT, static-port outbound NAT, STUN, or relay services.
Adding a separate static-port outbound NAT rule may affect the console's reported NAT type, but it does not fix the broken UPnP redirect. MiniUPnPd is supposed to create the necessary dynamic NAT and redirect rules itself.
You can inspect the rules created by MiniUPnPd with:
pfctl -P -a miniupnpd -s nat
pfctl -P -a miniupnpd -s rules
In my case, the relevant NAT entries are:
nat log quick on igc0 inet proto udp from 192.168.60.100 port = 9308 to any keep state label "192.168.60.100:9308 to 9308 (UDP)" rtable 0 -> ? port 9308
rdr pass log quick on igc0 inet proto udp from any to any port = 9308 keep state label "192.168.60.100:9308 to 9308 (UDP)" rtable 0 -> ? port 9308
The external interface is configured correctly and has a public IPv4 address:
ext_ifname=igc0
listening_ip=vlan060
The important part is `-> ?`. The outbound NAT rule should contain a valid translation address, while the redirect rule should point to the internal client—in this case, `192.168.60.100`.
This shows that:
- The UPnP request is accepted: ✓
- UDP port 9308 is registered as a mapping: ✓
- PF/NAT entries are created: ✓
- Valid translation targets are installed: ✗
- A valid, functioning port forward is created: ✗
This is therefore not an UPnP discovery problem. The client reaches MiniUPnPd and requests the mapping successfully, but the resulting PF rules do not contain valid translation targets.
The console's reported NAT type should not be used to confirm that the plugin is working. It appears that we will have to wait for a fix to the MiniUPnPd/PF integration.
Seeing the same hier with translation target ?.
nat log quick on pppoe0 inet proto udp from 192.168.100.21 port = 47141 to any keep state label "PCP MAP b939ca8f21f0c995ee240a6e" rtable 0 -> ? port 47141
rdr pass log quick on pppoe0 inet proto tcp from any to any port = 47141 keep state label "PCP MAP 0f926edb0b878a8d23d54b58" rtable 0 -> ? port 47141
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:
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:
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:
CELLULAR_IP:3880 > WAN_IP:3074
IP ID 21475
UDP length 10
TTL 47
The corresponding packet appeared on the Games VLAN as:
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:
pfctl -P -a miniupnpd -s nat
displays the translation target as:
-> ?
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'm experiencing the same issue. Is this plugin still supported?
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
Opened the feature request here: https://github.com/opnsense/plugins/issues/5674. Thanks again!
UPnP is working and displaying the internal IP again following the 26.7.3_x update. 🎉
Screenshot 2026-08-28 at 8.13.06 AM.png
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. 🎉
Screenshot 2026-08-28 at 8.13.06 AM.png
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.