[solved] UPnP behind double NAT is not working, even with a STUN-Server

[Bob.Dig]

What is not working is UPnP behind another router, although pfSense is the exposed host of this router. Tried with the now pinned patch also.

login-to-view

[viktor_g]

This is correct
See "behind the restrictive NAT"
"port forwarding is now impossible"

[Bob.Dig]

@viktor_g said in UPnP behind double NAT is not working, even with a STUN-Server:

See "behind the restrictive NAT"
"port forwarding is now impossible"

But that is not true, it is not restricted, it is exposed.
I have regular open ports on pfSense working without any problem.

I created a redmine issue: https://redmine.pfsense.org/issues/12797

[jimp]

1. Make sure you have the patch applied from the latest sticky post about UPnP. It's required even on 22.01 and 2.6.0.
2. This is likely the same problem from another existing thread:
   https://forum.netgate.com/topic/169773/miniupnp-full-cone-double-natincorrectly-adding-rules

[Bob.Dig]

@jimp For me, with STUN it looks like it is not working at all. When I use the "Override WAN address", even with the IP 6.6.6.6 it is doing something and the rules in UPnP Status are shown.

login-to-view

[jimp]

When you have that client active, see what shows up in the rules. Run this:

pfSsh.php playback pfanchordrill

And post what shows up in the miniupnpd anchor. You can mask the external address if it's identifiable and not a dummy address.

And also confirm that you've patched in the required fix I mentioned.

[Bob.Dig]

@jimp I auto-applied the patch and had pfSense restarted but the patch is doing nothing for my double-NAT problem it seems.

Your command is only showing something when there is also something to see in "UPnP & NAT-PMP Rules" in the Web-UI.

And this is only the case when I am using the WAN override. Not using the override or using the STUN-Server, there is nothing.

ipsec rules/nat contents:

miniupnpd rules/nat contents:
nat log quick on hn0 inet proto udp from 192.168.1.10 port = 19503 to any keep state label "Tixati" rtable 0 -> 6.6.6.6 port 19503
rdr pass log quick on hn0 inet proto tcp from any to any port = 19503 keep state label "Tixati" rtable 0 -> 192.168.1.10 port 19503
rdr pass log quick on hn0 inet proto udp from any to any port = 19503 keep state label "Tixati" rtable 0 -> 192.168.1.10 port 19503

natearly rules/nat contents:

natrules rules/nat contents:

openvpn rules/nat contents:

tftp-proxy rules/nat contents:

userrules rules/nat contents:

Just to let you know, tixati is a filesharing program for windows. Just install it, it will do UPnP out of the box, nothing to configure, super easy.

[jimp]

I use deluge for testing like that, it's similarly easy to trigger. But I'm not behind double NAT on my edge, and I don't have a STUN setup currently. If it isn't adding the NAT rules it must not be getting a proper result from the STUN server. In the other case I linked I believe it was was getting a STUN server response and making rules just using the wrong address on the outside.

When you force the external address it makes sense that it's using it directly since the use case for that is different (e.g. you have an IP alias VIP or CARP VIP on WAN and want to NAT the UPnP stuff out that).

If there is some deeper issue with STUN inside UPnP that's a much different problem.

[Bob.Dig]

@jimp In the first screenshot there you can see my public wan address, so I guess the STUN is working.

[jimp]

@bob-dig said in UPnP behind double NAT is not working, even with a STUN-Server:

@jimp In the first screenshot there you can see my public wan address, so I guess the STUN is working.

But it said you were behind restrictive NAT and port forwarding wasn't possible. So it may have worked to detect your IP address but it did not detect your NAT properly. I'd still consider that an issue in STUN. The STUN code in miniupnpd is capable of detecting if you are behind restrictive NAT, symmetric NAT, 1:1, etc. It's also possible the STUN server you are using isn't responding as expected to all the probes.

[Bob.Dig]

@jimp I went back for now, because of a real problem described here.
I used the STUN Server from sipgate, didn't checked any other.

[jimp]

FYI, I setup a test with a 1:1 NAT and STUN and it worked fine for me here for inbound connections. If I disable STUN, the client cannot open UPnP ports and a port test fails. If I enable STUN, it works.

That said, outbound connections aren't right as it's trying to NAT to the IP address it discovered via STUN and not the actual WAN, but as I mentioned someone else is already looking into that.

When it works properly there is no log message about STUN or the external IP address, so there must be some filtering happening upstream from you. I also received a similar error to the one you saw until I made sure I was behind 1:1 NAT with all incoming traffic passed through to the internal firewall.

[Bob.Dig]

@jimp said in UPnP behind double NAT is not working, even with a STUN-Server:

so there must be some filtering happening upstream from you.

I wouldn't know any, but as I have general problems described elsewhere, it is not the best test situation in the first place, at least for now.

[jimp]

Sure, but as there is at least one other person having an issue with UPnP+STUN and outbound NAT I figured it was worth mentioning what I found.

[Bob.Dig]

@jimp @viktor_g I now tested it with the google STUN Server and it is working for me. With the two other ones it is not. I consider this as solved from my point of view, because some of the other stuff mentioned here is telling me nothing.
I guess the redmine Issue https://redmine.pfsense.org/issues/12797 could be closed too.

[jimp]

@bob-dig said in [solved] UPnP behind double NAT is not working, even with a STUN-Server:

@jimp @viktor_g I now tested it with the google STUN Server and it is working for me.

Great! That's the same one I used when testing and it worked well here.

I guess the redmine Issue https://redmine.pfsense.org/issues/12797 could be closed too.

The problem I mentioned on the Redmine issue is still a legitimate issue that is being worked on. It affects new outbound connections (like for game clients) and not inbound connections like those for torrent/download clients.