UPnP Fix for multiple clients/consoles playing the same game
-
@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.
-
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:
-
@jimp I will repeat the test after removing the outbound NAT settings and report back.
-
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.
-
@encrypt1d said in UPnP Fix for multiple clients/consoles playing the same game:
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?
-
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.
-
@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)?
-
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.
-
@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.
-
Yeah, any one of those could be interfering.
-
@encrypt1d said in UPnP Fix for multiple clients/consoles playing the same game:
Yeah, any one of those could be interfering.
I check the states for current ports in use for 9308, and nothing showed up.
-
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 pfanchordrillIt 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.
-
UPnP NAT rules will take precedence over outbound NAT provided the patch is applied and the nat-anchor for miniupnpd is in the ruleset.
What is less clear is how it might be interacting with NAT reflection (port forwards, 1:1 NAT).
-
@encrypt1d said in UPnP Fix for multiple clients/consoles playing the same game:
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 pfanchordrillIt 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.
Nothing other than the first Playstation logged. This is what I see when I run that command (x'd out public IP):
pfSsh.php playback pfanchordrill
ipsec rules/nat contents:
miniupnpd rules/nat contents:
nat log quick on em0 inet proto udp from 10.0.0.19 port = 9308 to any keep state label "10.0.0.19:9308 to 9308 (UDP)" rtable 0 -> xxx.xxx.xxx.xxx port 9308
rdr pass log quick on em0 inet proto udp from any to any port = 9308 keep state label "10.0.0.19:9308 to 9308 (UDP)" rtable 0 -> 10.0.0.19 port 9308natearly rules/nat contents:
natrules rules/nat contents:
openvpn rules/nat contents:
tftp-proxy rules/nat contents:
userrules rules/nat contents:
@jimp
I don't have NAT reflection or 1:1 configured or enabled. Should I try it? -
I have "NAT Reflection mode for port forwards" set to Pure NAT, and "Enable automatic outbound NAT for reflection" checked, nothing else.
Does your second client send any more port requests or does it die after the first try?
-
@encrypt1d said in UPnP Fix for multiple clients/consoles playing the same game:
I have "NAT Reflection mode for port forwards" set to Pure NAT, and "Enable automatic outbound NAT for reflection" checked, nothing else.
Does your second client send any more port requests or does it die after the first try?
It generates multiple requests at least according to the network capture. But gives up eventually and I have to reboot it to get it to try to initiate UPnP again.
Enabled both Pure NAT, and Enable Automatic Outbound NAT for reflection and still no go. I restarted UPnP service after that with no change.
-
@saber said in UPnP Fix for multiple clients/consoles playing the same game:
I don't have NAT reflection or 1:1 configured or enabled. Should I try it?
If you don't have anything configured in 1:1 NAT and have none of the reflection options enabled then that is probably not what's happening in your case.
It sounds more like whatever game you're using is doing something different than others here. In the other cases (fixed by the patch) the games/consoles were properly requesting the mappings and they were all showing up, but the NAT wasn't being applied properly. In your case it's not getting that far.
-
@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:
I don't have NAT reflection or 1:1 configured or enabled. Should I try it?
If you don't have anything configured in 1:1 NAT and have none of the reflection options enabled then that is probably not what's happening in your case.
It sounds more like whatever game you're using is doing something different than others here. In the other cases (fixed by the patch) the games/consoles were properly requesting the mappings and they were all showing up, but the NAT wasn't being applied properly. In your case it's not getting that far.
No gaming yet, this is just the consoles booting up. Whichever one boots up first gets NAT Type 2, while the second one to boot up gets NAT Type 3. This is after I removed the Static Port map and testing per your first post above.
From the network capture this is just the consoles checking NAT.
-
Out of curiosity what happens if you do try a game? Is the result inside the game reported the same? I got the impression from others above that they were checking inside a game, not just on the console, but I could be wrong there.
-
@jimp said in UPnP Fix for multiple clients/consoles playing the same game:
Out of curiosity what happens if you do try a game? Is the result inside the game reported the same? I got the impression from others above that they were checking inside a game, not just on the console, but I could be wrong there.
I haven't tried a game to be honest. Playstation will still play an online game with NAT Type 3, but you generally experience communication with other online gamer issues. In my case and maybe I'm wrong as I haven't tested, I believe it would run into an issue as both consoles currently can't get UDP port 9308. Only 1 can at a time. My theory is that if a console shows a NAT Type of 3, it won't try to initiate UPnP during game play. As it detected the NAT Type during bootup. I can see it in the network traffic now, after it receives a NAT Type of 3 I do not see any more UPnP related traffic and have to reboot the console to have it try again.
