UPnP Fix for multiple clients/consoles playing the same game

rivageeza · Feb 17, 2022, 7:18 PM

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

encrypt1d · Feb 17, 2022, 8:11 PM

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 · Feb 17, 2022, 8:19 PM

@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 :

login-to-view

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 · Feb 17, 2022, 8:32 PM

@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 · Feb 17, 2022, 8:35 PM

@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 · Feb 17, 2022, 8:39 PM

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.
login-to-view

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 · Feb 17, 2022, 9:35 PM

@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:

login-to-view

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

encrypt1d · Feb 17, 2022, 9:35 PM

@saber

Yeah, any one of those could be interfering.

Saber · Feb 17, 2022, 9:36 PM

@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 · Feb 17, 2022, 9:45 PM

@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.

jimp · Feb 17, 2022, 9:47 PM

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).

Saber · Feb 17, 2022, 10:07 PM

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

@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.

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 9308

natearly 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?

encrypt1d · Feb 17, 2022, 10:23 PM

@saber

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?

Saber · Feb 17, 2022, 11:17 PM

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

@saber

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.

jimp · Feb 18, 2022, 1:11 PM

@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.

Saber · Feb 18, 2022, 1:28 PM

@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.

jimp · Feb 18, 2022, 1:32 PM

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.

Saber · Feb 18, 2022, 1:55 PM

@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.

Saber · Feb 18, 2022, 3:11 PM

Is miniupnp for PFSense attempting a Source Port remapping?

Doing some digging on this and other Firewall venders are stating that Playstation does not support source port remapping and will error out.

encrypt1d · Feb 18, 2022, 3:57 PM

@saber

Just a few more things to double check:

Your allow/deny rules aren't interfering? (in the miniupnp config settings)
When client 2 retries, is it asking for the same port every time, or picking new ones (as it should be)? The content of the xml packets in the requests to the UPnP server contain that. If it continuously asks for the same port (9308), the client isn't behaving correctly - however the game might have its own implementation, so it may still work as @jimp mentioned.
a filter reload can never hurt.

You can also start the server manually on the firewall with debug turned on (if you haven't already). I prefer to stop the running one from the dashboard gui widget that shows the services. You can stop via cli too.

In one session, tail the logs.

tail -f /var/log/routing.log

Then start miniupnpd

/usr/local/sbin/miniupnpd -f /var/etc/miniupnpd.conf -P /var/run/miniupnpd.pid -L -vv

Then let your clients connect and see what they are asking for.