UPnP Fix for multiple clients/consoles playing the same game

Saber

I have multiple Playstation consoles on the same LAN subnet. I've enabled upnp, configured the ACL with the static IP's of the consoles. Whichever console boots up first will get a NAT type 2 (Ideal), the second one to boot up and perform a Test Internet Connection will get a NAT Type 3 (restricted).

I've applied the patch, rebooted the firewall, and removed the static port mapping under Firewall-->NAT-->Outbound.

No Pure NAT, No Nat Reflection etc are currently enabled. So don't think its quite ironed out yet. What logs should I collect?

rivageeza

@m0nji it's a good test for me as prior to the patch, I couldn't play on PC and PS5 at the same time.

Without modifying any other setting and applying the patch, the issue is resolved 100%.

Neither the PC or PS5 failed over to a different port, which ever device booted the game first would work and the 2nd device would fail to connect.

Pre patch we could play PS5 and Xbox Series X as the xbox used port 3075 and PS5 would use 3074.

whiteshadow

@saber : try @rivageeza settings above.

It enables pure nat and reflection and 1:1 and also sets up static ports for gaming pc's/consoles in firewall outbound (easier to do with alias)

Reboot pfsense after and consoles
pc's (shutdown and power up)

test

Saber

@whiteshadow

Per jimp's first post the static port mapping shouldn't need to be enabled:

"Static port manual or hybrid outbound NAT rules are NOT required with this fix in place, provided the game in question uses UPnP. Such rules can be removed in many cases as they are no longer necessary."

I'm testing per suggestions. I'm not even getting to a game yet, just booting up the Playstations and know that it uses Upnp as it logs it in the upnp logs upon bootup to check NAT type.

encrypt1d

For those of you testing. It is super important to reboot the game machine, sometimes even multiple times. I have seen many scenarios where the game client just doesn't even try to use UPnP, and does not send any port programming requests to the firewall. (Detectable only via packet capture or starting the miniupnpd service with debug logs enabled, and tailing /var/log/routing.log)
You also need to make sure that UPnP is enabled on windows (if on a PC), and probably turn off your local firewall software if you have any.

jimp

@encrypt1d said in UPnP Fix for multiple clients/consoles playing the same game:

For those of you testing. It is super important to reboot the game machine, sometimes even multiple times. I have seen many scenarios where the game client just doesn't even try to use UPnP, and does not send any port programming requests to the firewall. (Detectable only via packet capture or starting the miniupnpd service with debug logs enabled, and tailing /var/log/routing.log)
You also need to make sure that UPnP is enabled on windows (if on a PC), and probably turn off your local firewall software if you have any.

What may be happening in some of these cases is that if a client or game is already running and miniupnpd restarts, the existing mappings are gone. The client may not request to open the ports again because it thinks they're still open, but the restart of miniupnpd cleared them out. So any time you restart UPnP on the firewall whatever UPnP clients are on the network also need a bump to make sure both sides agree on the state of UPnP mappings.

Saber

@jimp

So do we need to do the static port mappings? I had it there previously to get both Playstation consoles to get a NAT type 2, but couldn't play the same game due to the UPnP limitation there previously.

I have NOT enabled Pure NAT, NAT Reflection, and have removed the static port mappings.

Is that an improper configuration? I see @rivageeza configuration settings above, but was of the understanding that UPnP should work now without the additional steps / configurations as well as static port mappings?

As an update, I did reboot both Playstations after clearing the UPnP settings and whichever one boots up first gets NAT Type 2, while the other is Type 3.

jimp

@saber said in UPnP Fix for multiple clients/consoles playing the same game:

So do we need to do the static port mappings? I had it there previously to get both Playstation consoles to get a NAT type 2, but couldn't play the same game due to the UPnP limitation there previously.

You do not need any outbound NAT settings at all. No static port, no 1:1, no hybrid or manual outbound NAT, no port forwards. Nada. Not unless you use them for other things unrelated to games, naturally.

Saber

@jimp said in UPnP Fix for multiple clients/consoles playing the same game:

@saber said in UPnP Fix for multiple clients/consoles playing the same game:

So do we need to do the static port mappings? I had it there previously to get both Playstation consoles to get a NAT type 2, but couldn't play the same game due to the UPnP limitation there previously.

You do not need any outbound NAT settings at all. No static port, no 1:1, no hybrid or manual outbound NAT, no port forwards. Nada. Not unless you use them for other things unrelated to games, naturally.

Thanks for the confirmation that I shouldn't need those settings in place to get this to work as expected. I'm still testing, not having much luck as the Playstations appear to get the UDP 9308 port depending on who boots up and gets network connectivity first. I'm not technically into game play yet as I can't get both to have a NAT type of 2 with the recommendations so far.

I'm more than happy to test and provide logs to help get this resolved.

Saber

So I just took a packet capture, and I see the Playstation attempt an HTTP post regarding the port that it would like UPnP to map:

Playstation Sends this to Firewall (POST)

POST /ctl/IPConn HTTP/1.1
HOST: 10.0.0.254:2189
Content-Length: 636
Content-Type: text/xml; charset="utf-8"
SOAPACTION: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewRemoteHost></NewRemoteHost>
<NewExternalPort>9308</NewExternalPort>
<NewProtocol>UDP</NewProtocol>
<NewInternalPort>9308</NewInternalPort>
<NewInternalClient>10.0.0.18</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewPortMappingDescription>10.0.0.18:9308 to 9308 (UDP)</NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>
</u:AddPortMapping>
</s:Body>
</s:Envelope>

Firewall Responds: Http 500 Internal Server Error to a port conflict as port 9308 has already been mapped by the other Playstation on the network.

HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Connection: close
Content-Length: 406
Server: FreeBSD/12.3-STABLE UPnP/1.1 MiniUPnPd/2.2.1
Ext:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><s:Fault><faultcode>s:Client</faultcode><faultstring>UPnPError</faultstring><detail><UPnPError xmlns="urn:schemas-upnp-org:control-1-0"><errorCode>718</errorCode><errorDescription>ConflictInMappingEntry</errorDescription></UPnPError></detail></s:Fault></s:Body></s:Envelope>

This is repeated until it gives up:

rivageeza

@jimp I will repeat the test after removing the outbound NAT settings and report back.

encrypt1d

@saber

The error code 718 in that packet is normal for the second client. It just means the port was already in use by the first client. It seems like your patch might not be applied correctly, or you somehow have nat rules which are taking precedence.

Saber

@encrypt1d said in UPnP Fix for multiple clients/consoles playing the same game:

@saber

The error code 718 in that packet is normal for the second client. It just means the port was already in use by the first client. It seems like your patch might not be applied correctly, or you somehow have nat rules which are taking precedence.

I show this when I run the grep command from @jimp :

However I do still have some static Outbound NAT rules for a VPN Gateway that I am directing DNS traffic over.

The question is, if a NAT rule is taking precedence why would the Playstation that boots up first get port 9308 while the other one would not?

encrypt1d

@saber

The question is, if a NAT rule is taking precedence why would the Playstation that boots up first get port 9308 while the other one would not?

This is the magic that UPnP does. If your UDP packets always hit the predefined nat rule, it will never dynamically setup up a new port. UPnP literally programs your firewall with a different port for each client, that maps back to the original port on the client itself.

Maybe screenshot your outbound/port forward tabs. Mask out the IPs if they are sensitive.

encrypt1d

@saber I also should ask - is your WAN IP a public one, or a private one (like 192.168.x.x or 10.x.x.x)?

rivageeza

Ok, re-tested with all outbound NAT rules removed and still working for me, PS5 and PC, warzone, same time same lobby same match, both open NAT.

Actually set the mode back to Automatic outbound NAT rule generation. It's not been set like this in the 4 years I've been using PFSENSE.

Both devices using port 3074.

This is the first time I've ever seen an open NAT in COD without setting an outbound NAT rule with static port checked.

PFSENSE, PS5 and PC all rebooted once the outbound NAT rule was removed.

Saber

@encrypt1d said in UPnP Fix for multiple clients/consoles playing the same game:

@saber I also should ask - is your WAN IP a public one, or a private one (like 192.168.x.x or 10.x.x.x)?

Okay, I got a screen shot of my Outbound NAT rules. There are a lot. :) I had to cut the IPs out:

To answer your question the WAN IP is a Public one. What you see in the capture is LAN traffic.

encrypt1d

@saber

Yeah, any one of those could be interfering.

Saber

@encrypt1d said in UPnP Fix for multiple clients/consoles playing the same game:

@saber

Yeah, any one of those could be interfering.

I check the states for current ports in use for 9308, and nothing showed up.

encrypt1d

@saber

Honestly, I think the miniupnpd rules should actually take precedence - maybe @jimp can confirm that. That matches my testing anyway.

Is miniupnpd actually adding nat rules?
check using this command on the firewall:

pfSsh.php playback pfanchordrill

It should look like this, maybe with different ports (while you have a client actively running). I masked out the IP with X's.:

ipsec rules/nat contents:

miniupnpd rules/nat contents:
nat log quick on igb0 inet proto udp from 192.168.8.2 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> X.X.X.X port 3074
rdr pass log quick on igb0 inet proto udp from any to any port = 3074 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.8.2 port 3074

natearly rules/nat contents:

natrules rules/nat contents:

openvpn rules/nat contents:

tftp-proxy rules/nat contents:

userrules rules/nat contents:

If your client is stuck retrying, you may see lots in there.