I'll try it myself during weekend, it is becoming interesting.
So, you were right about the installation issue, I had to downgrade whole OpenWrt in order to compare. The problem definitely is not in transition to nftables.
Another interesting observation regarding testing. I used Transmission to quick test if miniupnpd works or not and it was not a very good idea. Actually Transmission never uses NAT-PMP (renamed to PCP in latest miniupnpd versions) if it discovers UPnP (IGD) support regardless confusing log record about "initnatpmp successful". It is better test UPnP and NAT-PMP separately with proper tools like upnpc and miniupnpc.
https://github.com/miniupnp/miniupnp/issues/333 - this is miniupnpd's creator explaining whole situation. He resists fixing this problem in UPnP because it is against protocol's specification (only UPnP not NAT-PMP). He proposes using external_ip option which you already discovered.
I updated the wiki pages:
https://openwrt.org/docs/guide-user/firewall/upnp/upnp_setup
https://openwrt.org/docs/guide-user/firewall/upnp/miniupnpd
Check the new Troubleshooting section.
I also have a CGNAT and for some reason the STUN didn't worked. When executed the natpmpc command it returned:
initnatpmp() returned 0 (SUCCESS)
using gateway : 192.168.1.1
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned -7 (FAILED)
readnatpmpresponseorretry() failed : the gateway does not support nat-pmp
errno=111 'Connection refused'
Once I specified the external_ip manually it started to working:
natpmpc -a 9999 9999 tcp
initnatpmp() returned 0 (SUCCESS)
using gateway : 192.168.1.1
sendpublicaddressrequest returned 2 (SUCCESS)
readnatpmpresponseorretry returned 0 (OK)
Public IP address : 188.163.41.4
epoch = 12167
sendnewportmappingrequest returned 12 (SUCCESS)
readnatpmpresponseorretry returned 0 (OK)
Mapped public port 9999 protocol TCP to local port 9999 liftime 3600
epoch = 12167
closenatpmp() returned 0 (SUCCESS)
Maybe this can help to you to debug the issue.
@timur.davletshin it would be great if you can review it and something to improve. If you don't have an access just let me know what to add (Links, issues, commands, etc). See my contacts in bio
Kudos for using proper approach in testing (natpmpc and upnpc). I recommended in one of the threads running transmission to quick test it. It was wrong. It has rather weird behavior (at least the one which comes with Debian 12). It always prefers UPnP, not NAT PMP. If UPnP fails it never tries NAT PMP (even more, it wrights in log about initnatpmp being successful). And even when it does (for example I disable UPnP in miniupnpd) it opens only TCP port (with UPnP it opens both UDP and TCP with a same port number).
Probably the only improvement I could think of (but it's not your job) is extending luci-app-upnp and adding protocol information with expiration time. Current one has weird behavior. Mine shows client information (something like "Transmission at 56508") in Description but after some time it loses it and shows protocol instead "NAT-PMP at 56508". It happens to all clients I use.
I can send a PR to the Luci app so if anything can be changed there let me know. For now I'm going to add a few public stun servers as an example so that users can copy-paste.
The description of a protocol is possible only with UPnP. The PCP is a stripped packet to just open and close a forwarding with the only option is lifetime.
You can specify a description manually like upnpc -e DESC -a 192.168.1.114 9999 9999 tcp
I checked in Transmission 3 on Ubuntu 22.04 and it first tries the UPnP and if it's disabled then it uses the NAT-PMP. So you probably can upgrade.
This is not exactly what I meant. If UPnP fails for the reason of being behind CGNAT it never reaches NAT-PMP which in fact may work. This all thing of STUN not working as we expect is because this behavior is against IGD specs.