Bug #14065
closed
UPnP not working when WAN IP is private IP range.
Added by Greger Blennerud about 1 year ago.
Updated about 1 year ago.
Affected Architecture:
All
Description
The changes and updates to miniupnp that have been made in the last year have been much appreciated by everyone having gamers in their households. However, there is still an issue for those who are stuck behind a modem or router providing a private IP to pfsense WAN. One where bridge mode is not available, such as most consumer 4G/5G routers.
The issue is not related to double NAT. Rather it simply seems to throw an error if WAN IP is detected to be private IP.
All games tested (mostly various CoD games) get Open NAT despite the double NAT situation provided the IP on the WAN side is * not * of "private IP tyoe". A further prerequisite is that pfsense is placed in DMZ (all ports open) on the upstream router. Testing verified on LTE-router which allows setting any IP range on LAN side.
Providing a simple override mechanism to manually force UPnP not to check for Private IP, would solve this "bug" in a simple way...
- Status changed from New to Duplicate
Duplicate of #10398
This is, unfortunately, outside of our control. Any changes for this will have to come from the miniupnp project.
Jim Pingle wrote in #note-1:
Duplicate of #10398
This is, unfortunately, outside of our control. Any changes for this will have to come from the miniupnp project.
Ok, but I'm assuming you do communicate? A request from the pfsense team would bear more weight than coming from me I suppose. Nevertheless I did register and entered a topic under the bug section in their (I think) forum...
We've tried communicating with them before about this but they didn't see the need to make an option for it.
There are options to hardcode an external address or use a STUN server to find it and they think that's good enough. There is a public STUN server from Google and likely others around that may help here, too.
Jim Pingle wrote in #note-3:
We've tried communicating with them before about this but they didn't see the need to make an option for it.
There are options to hardcode an external address or use a STUN server to find it and they think that's good enough. There is a public STUN server from Google and likely others around that may help here, too.
Ok perhaps something to look into then. I do realize that another thing which is lacking, is the inability to multiselect WAN or to use WANgroup (to follow failover)... Is this also a miniupnp issue or something that can be solved here?
Greger Blennerud wrote in #note-4:
Jim Pingle wrote in #note-3:
We've tried communicating with them before about this but they didn't see the need to make an option for it.
There are options to hardcode an external address or use a STUN server to find it and they think that's good enough. There is a public STUN server from Google and likely others around that may help here, too.
Ok perhaps something to look into then. I do realize that another thing which is lacking, is the inability to multiselect WAN or to use WANgroup (to follow failover)... Is this also a miniupnp issue or something that can be solved here?
After extensive testing I can only conclude that miniupnp is not fully functional with the solutions they suggest. Using Google STUN does make UPnP accept requests and they show up in the status list. But for some reason the connections are not establised. Same thing happens when using a hardcoded IP... The most challenging game MW2 (2009) doesn't even establish a connection to Infinity Ward servers.
Changing the IP on the upstream router to a public IP emakes all games connect with Open NAT across the board. There must be something else going on behind the scenes that involves the actual WAN IP...
Also available in: Atom
PDF
Updated by 
Updated by