@stephenw10 said in CGNAT UPnP Issue Advice:
Yeah set an override or enable the STUN external IP detection.
UPnP can still work in that situation if the upstream router is forwarding traffic. So if you set the pfSense as the DMZ IP in your ISP router for example.
Steve
For this scenario, where UPnP isn't actually used for anything towards external servers/devices, STUN might work as a way to remove the errors.
It might also work for e.g. a gaming scenario, at least if the mobile router has a public IP, (I'll make sure to test that). But in this case the mobile router is behind CG-NAT, so it might not work for gaming.
What I don't understand though, is why does miniupnp give this error and refuses to do it's job if the WAN IP is from the private IP range?
If the upstream router places pfsense in DMZ, it should still work!
I have tested this and it does actually work fine if you can "fool it"...
My failover goes over LTE and the mobile router has a public IP but doesn't do bridging. It does however have DMZ and most importantly, it allows me to set any IP on the LAN interface. If I set it to a public IP, UPnP on pfsense works perfectly fine, giving me Open NAT on all the games I throw at it, double NAT and all. Other routers, like Ubiquiti edgerouter, also work, but they do it even if WAN has a private IP...
The problem that you run into when doing it this way, is that it breaks the Dynamic DNS setup, since it will now take the fake WAN IP and not use the "Check IP Service".
I see three simple things that we need here.
Provide an override selection to prevent miniupnp to check for private IP on the WAN interface.
Introduce Gateway Group into the External Interface selection for UPnP, so it can follow the default gateway in a failover scenario, or allow multi select not only for Internal interfaces.
Not really a necessity if 1 & 2 are in place but still a good idea to have the option to force "Check IP service" regardless of the WAN IP.