Project

General

Profile

Actions

Bug #14070

open

STUN or Override WAN address in UPnP breaks working port forwarding if WAN IP is Private IP

Added by Greger Blennerud about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
UPnP/NAT-PMP
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
All
Affected Architecture:

Description

I discovered some weird behavior when experimenting with UPnP - STUN and Override WAN address in a failover scenario where WAN ends up on a Private IP.

A proposed solution was to try and use STUN (using Google server) as a way to make UPnP accept a double NAT scenario when WAN IP is RFC 1918. Another proposed solution was to use Override WAN address.

So I went through a lot of testing, and found the following:

First test run is with pfsense 23.01 behind a 4G router with pfsense in DMZ on a Private IP.

1. As a reference point, using only Port forwarding of relevant ports allowed for Open NAT in all COD Games tested, except MW2 (2009) (Strict).
2. With port forwards in place, and UPnP activated (as is), the same set of games still get Open NAT (and MW2 still has Strict). The only visible change is that syslog shows minupnp complaining about private IP.
3. With port forwarding still in place and STUN activated, UPnP Status page now lists the expected ports being requested by the games. HOWEVER, games will no longer connect and do not start in multiplayer mode !! MW2 shows error page about not reaching IW Servers.
4. With port forwarding in place and Override WAN address, same result as 3.

Changing the set up so that 4G router provides pfsense with a fake Public IP , still in DMZ.

1. Port forwarding reference, same as in 1 above
2. Port forwarding and UPnP activated, all games now show Open NAT , including MW2 (2009).
3. No port forwarding, only UPnP, all games show Open NAT
4. Activating STUN or Override WAN address IP doesn't change or break anything, same Open NAT as in 3.

Clearly there is some miscommunication between pfsense and miniupnp where miniupnp seems to claim "responsibility" of the port forwarding but doesn't follow thru at all when a Private IP is on WAN.

Actions

Also available in: Atom PDF