Double NAT topologies broken

[iserlohn]

pfSense 2.4.5 was released a few days ago which included a miniupnp update and I started migrating some systems across.

I found that this change change effectively breaks all double NAT setups (in combination with this), even when STUN or ext_ip is used.

Details can be found at -

https://redmine.pfsense.org/issues/10398

Summary -

ISP provided outside router is on 192.168.10.254 forwarding all ports to 192.168.10.1.

pfSense -
External WAN interface is 192.168.10.2 (192.168.10.1 CARP)
Internal LAN interface is 192.168.20.2 (192.168.20.1 CARP)

Test host is on 192.168.20.100

On 2.4.4p3 -

# upnpc -a 192.168.20.100 63000 64000 tcp
upnpc : miniupnpc library test client, version 2.1.
 (c) 2005-2018 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
 desc: http://192.168.20.2:2189/rootDesc.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found a (not connected?) IGD : http://192.168.20.2:2189/ctl/IPConn
Trying to continue anyway
Local LAN ip address : 192.168.20.100
ExternalIPAddress = 192.168.10.2
InternalIP:Port = 192.168.20.100:63000
external 192.168.10.2:64000 TCP is redirected to internal 192.168.20.100:63000 (duration=0)

On 2.4.5 -

# upnpc -a 192.168.20.100 63000 64000 tcp
upnpc : miniupnpc library test client, version 2.1.
 (c) 2005-2018 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
 desc: http://192.168.20.2:2189/rootDesc.xml
 st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found a (not connected?) IGD : http://192.168.20.2:2189/ctl/IPConn
Trying to continue anyway
Local LAN ip address : 192.168.20.100
GetExternalIPAddress failed.
AddPortMapping(64000, 63000, 192.168.20.100) failed with code 501 (Action Failed)

After upgrading pfSense to 2.4.5, miniupnp refuses to assign port mappings when the WAN interface is RFC1918.

This is due to the following - #298 #333 8e10a1a

If we set ext_ip to an public address, mappings are assigned, but the subsequent rules inserted into pf still breaks a double NAT setup -

#pfctl -a miniupnpd -sr
pass in log quick on igb0.10 inet proto tcp from any to 192.168.20.100 port = 63000 flags S/SA keep state label "libminiupnpc" rtable 0

#pfctl -a miniupnpd -sn
rdr log quick on igb0.10 inet proto tcp from any to 1.1.1.1 port = 64000 keep state label "libminiupnpc" rtable 0 -> 192.168.20.100 port 63000

As the traffic arriving on the inside router WAN interface will already be NATed by the outside router, the above rule(s) inserted by minipnp on the inside router will prevent all double NAT setups from working with miniupnp.

This is due to - #231 53e8185

The current solutions of ext_ip and ext_perform_stun don't seem to be able to work in such cases either. I can see why asuswrt-merlin had to revert in https://github.com/RMerl/asuswrt-merlin.ng/issues/444

[miniupnp]

I think I will first make the change in 53e8185 configurable at build time

[bobdig]

I also have this problem with pfSense. My ISP is doing 1:1 CG-NAT for IPv4 (100.65..) and I can manually open ports and use them with no problems at all, but not with UPnP anymore... It has worked before.

[miniupnp]

@iserlohn / @bobdig could check that 3f04f79 fixes your issue ? setting the dst address will be disabled by default.

[bobdig]

Can't test it because I don't know stuff, my account on github is only for complaining. But I hope that fix did it.

[kevindd992002]

Any updates to this issue?

[miniupnp]

@kevindd992002 can you check 3f04f79 ?

[kevindd992002]

@miniupnp Yeah, sorry I'm no programmer. I just use pfsense 2.4.5 and started to have issues because of this and I was hoping it can be fixed with a workaround/patch/something.

[miniupnp]

@kevindd992002 well, that's a patch, that needs to be tested...

[mstargard]

I dropped in the miniupnpd binary from the 2.4.4 pfsense release and it worked like it did before. I also have a special use case where I'm using miniupnpd to create the NAT and firewall rules for a port forward from a VPN vendor. The network space is RFC1918 on the ovpnc1 interface to my exit point in the VPN vendor's facility. I have no control over which port they decide to forward and I only get one when I ask for it via a web json call. Knowing this is not ideal, it gets folks moving.

[miniupnp]

I consider 3f04f79 fixed the problem, as no feedback was received to state otherwise.