ASUS ROG RAPTURE GT-AXE16000 Firmware version 3006.102.6 UPNP not working

[nagyimre1980]

Could it be disappearing because your ISP renewed/changed your IPv6 lease?

Honestly, IPv6 pinhole is one of these things that since nobody ever uses, I doubt the miniupnpd author even tested its implementation. He probably just implemented the official RFC specs, and left it at that. Whether it works in a real-life setup is unknown. Same thing with most of the IGDv2 implementation, that was broken in Windows itself for multiple years. So far, the only workaround is for miniupnpd fake some of its internal data structures to fool Windows.

IGD is one of these technologies that exists on paper, but barely gets any real life use beyond the very basics, so nobody is debugging and fixing it (by "nobody", I mostly mean Microsoft/Apple/Google). The miniupnpd author's stance has been to just implement the RFCs as they are stated, which is really the only thing he can really do.

On my end, all I could do is test creating a pinhole using upnpc when I implemented pihole support, and that part was working for me. If however there is no mechanism to refresh them from the router's point of view whenever the IPv6 allocation changes, then nothing can be done about it. If your application creates a pihole using an ephemerous IPv6, and that IPv6 eventually expires, it will be up to the client (qbittorrent in this case) to notice that, and refresh the piholes it manages.

Update: I have disabled IPv6 temporary addresses and randomized identifiers in Windows 11 via PowerShell (Set-NetIPv6Protocol -UseTemporaryAddresses Disabled). I’m testing this now to see if the stable IPv6 address prevents the UPnP pinhole from disappearing. I'll report back if this solves the issue.

Set-NetIPv6Protocol -RandomizeIdentifiers Disabled
Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

unfortunately this doesn't help

 

[DiGz_Au]

NAT type is when you have a remote connection connecting with you, it determines how the port mapping will be handled.

Whether NAT type is restricted or full cone, a port forward will still work if it's forwarded (i.e. masqueraded or static NAT). It will either be more or less restrictive in which remote connections get accepted. Fullcone might allow unsollicited inbound connections, which is a security risk. Fullcone is also only supported by very few routers - the Linux kernel itself does not have fullcone support. Any router supporting it has to do it through a custom kernel/netfilter patch.

There has been zero changes in recent firmwares on this subject. None of the 3006.102 router models ever supported Fullcone NAT, only older 3004.388 models based on kernel 4.1 ever did. If you are now experiencing new issues, that is not related to NAT type in any way.

UPnP is working. Here is my GT-AXE16000 with a pair of port forwards configured by qBittorrent on a Windows laptop, through UPNP:

View attachment 69802

And here is the telnet connection to that forwarded port, done from the GT-AXE16000 WAN side.

View attachment 69803

Just because your test method reports Restricted NAT does not mean that port forwarding through UPnP doesn't work.

I know about nat but even when the router reports zero ports being forwarded on firmwares past 388.9-2 and games report moderate Nat as a direct reason ie upnp isnt working doesnt that tell you something? Just load up a game and check? Torrent clients also show the port being forwarded for me in the router aswell but gaming is what most of us here are using upnp for. As I said all works fine ar 388.9-2 and prior. Infact i resorted to flashing 388.9-2 and then updating without a wipe to latest and doing this makes upnp work fine so its evident there's something more going on.

 

[RMerlin]

Just load up a game and check

I don't have a gaming console.

I know about nat but even when the router reports zero ports being forwarded on firmwares past 388.9-2 and games report moderate Nat as a direct reason ie upnp isnt working doesnt that tell you something?

Consoles can also report moderate NAT with a working port forward because it's not identified as Fullcone NAT.

Infact i resorted to flashing 388.9-2 and then updating without a wipe to latest and doing this makes upnp work fine so its evident there's something more going on.

The last change to UPnP was actually in 388.9_2 itself, where miniupnpd was updated to 2.3.8. There has been no change since then.

 

[RMerlin]

Update: I have disabled IPv6 temporary addresses and randomized identifiers in Windows 11 via PowerShell (Set-NetIPv6Protocol -UseTemporaryAddresses Disabled). I’m testing this now to see if the stable IPv6 address prevents the UPnP pinhole from disappearing. I'll report back if this solves the issue.

Set-NetIPv6Protocol -RandomizeIdentifiers Disabled
Set-NetIPv6Protocol -UseTemporaryAddresses Disabled

unfortunately this doesn't help

Check your System Log if you see events related to miniupnpd cleaning ups or ISP renewing your IPv6 allocation or lease.

 

[DiGz_Au]

I don't have a gaming console.


Consoles can also report moderate NAT with a working port forward because it's not identified as Fullcone NAT.

The last change to UPnP was actually in 388.9_2 itself, where miniupnpd was updated to 2.3.8. There has been no change since then.

Load up a game on windows, plenty have the nat status that shows and check the logs for upnp entries.

 

[RMerlin]

Load up a game on windows, plenty have the nat status that shows and check the logs for upnp entries.

I don't play any multiplayer games, so that will have to wait to some later time where I feel like trying hunt for something to test.

 

[DiGz_Au]

I don't play any multiplayer games, so that will have to wait to some later time where I feel like trying hunt for something to test.

No worries. Thanks for taking the time to look at this.