UPnP Fix for multiple clients/consoles playing the same game

encrypt1d

I believe this is the RFC, and I have linked the relevant section. I am not a UPNP expert :)

https://datatracker.ietf.org/doc/html/rfc6970#section-5.6.2

It shows that when the UPNP client asks for a port that is already taken, the protocol dictates that it should respond with error 718 / ConflictInMappingEntry and then proceed to try another port.

The evidence @Saber collected showed it continuing to try the same port every time, which is where their problem likely is.

I don't have any playstations, so I would not be able to help further.

Argon 0

@encrypt1d I have tested the patch with two PlayStation 3's (OS also based on FreeBSD) and see the same behaviour as @Saber i.e. the first booted PS gets NAT type 2 and shows up in the UPnP & NAT-PMP status section, but the second PS does not and gets NAT type 3 assigned.

Is there any other way to setup both PlayStations with NAT type 2 i.e. "open"?

Saber

@argon-0 Yeah, just configure the normal gaming setup for PFSense which is to setup an Outbound static port rule:

https://docs.netgate.com/pfsense/en/latest/nat/outbound.html#nat-staticport

I configured that to get both my playstations on at the same time with NAT type 2. Network wise the behavior remains the exact same with second powered up playstation requesting the same damn port, but for whatever reason gets a Type 2 NAT with the outbound static port configuration.

encrypt1d

I had some friends over to really test this out last weekend and below are my results:

Verdict: Success

6 Windows PCs total, Five Windows 10 / One Windows 11.

Games tested: Call of Duty Black OPS III and WWII

All five of the windows 10 machines got OPEN NAT in game straight away. The Windows 11 machine would NOT play ball. No matter what we tried, the Win 11 game client just refused to send any UPnP requests to the pfSense. To be clear - that is not a pfSense issue. I have reproduced it since, and will continue to debug that. Manually adding the ports via the Windows 11 gui worked to get open NAT (Windows File Explorer -> Network -> Right click on FreeBSD router -> Properties -> General -> Settings -> Add). So Windows 11 can talk to the miniupnpd server, just CoD doesn't seem to even try.

Has anyone else gotten a CoD game on Windows 11 to talk UPnP? Would like to know if there is a magic secret. This is totally unrelated to pfSense as far as I know. Of course I had all software firewalls disabled for the test, and file & printer sharing on, network discovery on.

Saber

@encrypt1d

Did you confirm that the network is Private and not Public? This document discusses some steps for network discovery for Windows 11 which appears to be a little different than previous versions of Windows.

https://www.minitool.com/news/windows-11-workgroup-not-showing-all-network-computers.html

encrypt1d

@saber
Yes indeed it, is set to Private.

Saber

@encrypt1d

Win 11 is so new, it honestly wouldn't surprise me if its a bug.

encrypt1d

@saber
Could very well be. I plan to test CoD Warzone soon, as it works fine on Windows 10 with UPnP, and is updated regularly at this point.

encrypt1d

Tested at lunch today. Interesting results.

I installed CoD Warzone (which is free, relatively new, and constantly updated). I fired it up and immediately got UPnP requests/OPEN NAT.

Weird thing is, that ALSO fixed BO3 and WWII. They both instantly worked afterwards.

I can only guess, but they may all use some shared net code to access UPnP via the OS, which was updated by Warzone? Dunno.

Mystery somewhat solved. All 3 games working fine on Win 11 and behind a pfSense with this patch.

kevin.ruffus

Can confirm that the patch is at least part of resolving the issue, and that both the firewall and any system that will be using UPNP need to be rebooted in order for the fixes to take effect. I made multiple attempts reloading the filters and resetting the state tables with only rebooting the PC, resetting the NIC, etc, and only full reboots to both the PC and firewall worked.

I don't know if it's possible, but one thing that might help lessen the potential security issue with using UPNP would be to clear generated forwards after a certain amount of time of non-use. Just a thought.

Frisbee3713

Finally UPnP seems to work as expected upon applying the system patch. No additional configuration required: static port, 1:1, hairpin, etc need not be enabled.

Unfortunately UPnP is still very broken in dual stack situations where clients presumably send UPnP requests from the IPv6 link local address. I suspect users who could not get it to work in this thread are probably using dual stack deployments. Disabling IPv6 on client will make UPnP work as it should. Apps that only support IPv4 work regardless in my testing.

If only there was a way for miniupnpd to consider v6 GUA + v6 LL + v4 addresses as one entity and apply needed port forward and pinholes accordingly then all UPnP problems would be addressed for good?!

Thank you devs for this patch.

EDIT: There appears to be an issue where UPnP leases never expire: If not click ‘clear all session’ in web GUI port forward exist idefinitely. Should they not expire at some point?

jimp

Locking this as the core problem here is solved.

If you have an issue with UPnP in your specific environment with the fix in place, please start a new thread with the details.