Test Request: UPnP Fix for Multiple Consoles playing the same game / static port outbound NAT
-
Not yet, we'd have to build a new version with the new changes manually patched in like we did before. Time is short at the moment so unlikely to happen any time in the next few days.
-
No worries at all Jim :) Take your time. I at least have a static config that works for the 2 conflicting consoles for now.
I will keep watch for any updates or requests for testing in the future. -
I tested this with two PS4's.
The network test on a PS4 is set to a constant port of 9308. Hence, running the PS4's network test on the first console gives NAT Type 2, and running the same test on the second console gives NAT Type Failed (sometimes NAT Type 3). Running the game Destiny 2, I can see ports being opened in UPnP in the GUI, with and without the patch.
Here is the command output without the patch:
[2.5.0-DEVELOPMENT][admin@gw.ruhex.net]/root: pfSsh.php playback pfanchordrill ipsec rules/nat contents: miniupnpd rules/nat contents: rdr quick on igb0 inet proto udp from any to any port = 9308 keep state label "10.0.5.40:9308 to 9308 (UDP)" rtable 0 -> 10.0.5.40 port 9308 # First PS4 network test rdr quick on igb0 inet proto udp from any to any port = 3074 keep state label "DemonwarePortMapping" rtable 0 -> 10.0.5.40 port 3074 rdr quick on igb0 inet proto udp from any to any port = 3075 keep state label "DemonwarePortMapping" rtable 0 -> 10.0.5.43 port 3075 rdr quick on igb0 inet proto udp from any to any port = 22389 keep state label "DemonwarePortMapping" rtable 0 -> 10.0.5.40 port 22389 rdr quick on igb0 inet proto udp from any to any port = 14626 keep state label "DemonwarePortMapping" rtable 0 -> 10.0.5.43 port 14626 pass in quick on igb0 inet proto udp from any to 10.0.5.40 port = 9308 flags S/SA keep state label "10.0.5.40:9308 to 9308 (UDP)" rtable 0 pass in quick on igb0 inet proto udp from any to 10.0.5.40 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0 pass in quick on igb0 inet proto udp from any to 10.0.5.43 port = 3075 flags S/SA keep state label "DemonwarePortMapping" rtable 0 pass in quick on igb0 inet proto udp from any to 10.0.5.40 port = 22389 flags S/SA keep state label "DemonwarePortMapping" rtable 0 pass in quick on igb0 inet proto udp from any to 10.0.5.43 port = 14626 flags S/SA keep state label "DemonwarePortMapping" rtable 0 natearly rules/nat contents: natrules rules/nat contents: openvpn rules/nat contents: tftp-proxy rules/nat contents: userrules rules/nat contents:
Same tests/game with the patch:
[2.5.0-DEVELOPMENT][admin@gw.ruhex.net]/root: pfSsh.php playback pfanchordrill ipsec rules/nat contents: miniupnpd rules/nat contents: nat quick on igb0 inet proto udp from 10.0.5.40 port = 9308 to any keep state label "10.0.5.40:9308 to 9308 (UDP)" rtable 0 -> x.x.x.x port 9308 nat quick on igb0 inet proto udp from 10.0.5.40 port = 22388 to any keep state label "DemonwarePortMapping" rtable 0 -> x.x.x.x port 22388 nat quick on igb0 inet proto udp from 10.0.5.43 port = 3076 to any keep state label "DemonwarePortMapping" rtable 0 -> x.x.x.x port 3076 nat quick on igb0 inet proto udp from 10.0.5.43 port = 14625 to any keep state label "DemonwarePortMapping" rtable 0 -> x.x.x.x port 14625 nat quick on igb0 inet proto udp from 10.0.5.40 port = 3075 to any keep state label "DemonwarePortMapping" rtable 0 -> x.x.x.x port 3075 rdr quick on igb0 inet proto udp from any to any port = 9308 keep state label "10.0.5.40:9308 to 9308 (UDP)" rtable 0 -> 10.0.5.40 port 9308 rdr quick on igb0 inet proto udp from any to any port = 22388 keep state label "DemonwarePortMapping" rtable 0 -> 10.0.5.40 port 22388 rdr quick on igb0 inet proto udp from any to any port = 3076 keep state label "DemonwarePortMapping" rtable 0 -> 10.0.5.43 port 3076 rdr quick on igb0 inet proto udp from any to any port = 14625 keep state label "DemonwarePortMapping" rtable 0 -> 10.0.5.43 port 14625 rdr quick on igb0 inet proto udp from any to any port = 3075 keep state label "DemonwarePortMapping" rtable 0 -> 10.0.5.40 port 3075 pass in quick on igb0 inet proto udp from any to 10.0.5.40 port = 9308 flags S/SA keep state label "10.0.5.40:9308 to 9308 (UDP)" rtable 0 pass in quick on igb0 inet proto udp from any to 10.0.5.40 port = 22388 flags S/SA keep state label "DemonwarePortMapping" rtable 0 pass in quick on igb0 inet proto udp from any to 10.0.5.43 port = 3076 flags S/SA keep state label "DemonwarePortMapping" rtable 0 pass in quick on igb0 inet proto udp from any to 10.0.5.43 port = 14625 flags S/SA keep state label "DemonwarePortMapping" rtable 0 pass in quick on igb0 inet proto udp from any to 10.0.5.40 port = 3075 flags S/SA keep state label "DemonwarePortMapping" rtable 0 natearly rules/nat contents: natrules rules/nat contents: openvpn rules/nat contents: tftp-proxy rules/nat contents: userrules rules/nat contents:
I'm not certain if this is an improvement given that I no longer have the game I could reproduce the issue with 100% of the time (Ghost Recon Wildlands). I do see that additonal NAT rules are added however, and I'd assume that these are an improvement, though @jimp would have to say if that's true or not.
-
So if am reading this correctly through the various posts I see two issues, uPNP isnt working at all and more than one console or system attempting to play the same game or service can fail if they need to use the same port on the firewall? I just installed pfSense this weekend and immediately started running into issues with our Nintendo Switch, Amazon tablet etc.
Can someone smarter than myself help me understand how this works with consumer grade firewalls like eero, netgear, comcast, etc...without issue but pfSense chokes on it? This isn't a knock on pfSense by any means as the increase level of visibility and control and plethora of additional features is worth the extra steps provided they work as I am looking to invest in the 7100 model router/firewall but I am just having hard time wrapping my head around an issue thats apparently been around for at least three years and still isnt fully functional. I have read that other routers apparently can be affected by the NAT traversal issue but on my old router I could use two Nintendo Switch's on the same network and same game without NAT issues.
I would love to help test but with the flack I am receiving from my kids I will be forced to put back the other router for now.
Regards
-
There are plenty of topics covering those questions already, this thread is only for testing this fix.
-
This post is deleted! -
So I'm willing to upgrade to 2.5.0 image to test. My only concern is if I switch to the new image will I be able to get back to a stable version without having to wait for a new version? For instance can I go to 2.5.0 and then downgrade back to 2.4.5_1?
-
@vMAC said in Test Request: UPnP Fix for Multiple Consoles playing the same game / static port outbound NAT:
So I'm willing to upgrade to 2.5.0 image to test. My only concern is if I switch to the new image will I be able to get back to a stable version without having to wait for a new version? For instance can I go to 2.5.0 and then downgrade back to 2.4.5_1?
There is no downgrade procedure. Take a config backup first and keep an installer handy for 2.4.5-p1. If something goes wrong on 2.5.0, reinstall 2.4.5-p1 and restore the 2.4.x backup.
-
We have added the 2.2.0-RC1 version of miniupnpd to the repository for pfSense 2.5.0 and so it should be included in snapshots shortly, later today or tomorrow, for additional (and easier) testing.
-
I updated my 5100 from the web UI this morning (from the latest stable official release to the latest devel release.)
I can confirm that, with the correct NAT rules, I seem to be able to get multiple consoles online successfully using UPNP. My household has 3 switches, 2 XBox Ones and 2 PS4s, and I was able to get them all connected simultaneously with suitable NAT levels and no error reports.
I can provide more detailed information to @jimp if necessary.
I'll be doing some more testing later today to make sure I haven't missed anything, but so far so good.
Andrew
-
That's good news!
@andrew_r said in Test Request: UPnP Fix for Multiple Consoles playing the same game / static port outbound NAT:
with the correct NAT rules
Do you mean the correct NAT rules generated automatically by UPnP, or did you have manual rules setup for those consoles?
-
@jimp I had some manual rules set up from previous attempts, but they are fairly simple.
(1) Assign each console a static IP.
(2) Set up an firewall alias called UNPNP_NAT_GROUP containing those IPs.
(3) Set up an outbound NAT rule as follows:
Interface: WAN
Address Family: IPv4 (I don't use IPv6)
Protocol: any
Source: Network / UNPNP_NAT_GROUP / 32 <-- not sure the 32 is right.
Destination: Any
Static Port: Checked
Description: UNPNP NAT Static Port RuleAnything not mentioned was left as default.
(4) UPNP Settings:
Enable UPnP & NAT-PMP: Checked
Allow UPnP Port Mapping: Checked
Allow NAT-PMP Port Mapping: CheckedExternal Interface: WAN
Interfaces: LANLog Packets: Checked.
I haven't played around with the default deny option, and I have "allow 1024-65535 x.x.x.0/24 1024-65535" in the ACL field (where x.x.x is my network), although I think it might not be necessary unless I enable default deny.
I'm not a firewall expert by any means, but this seems to do the trick. I'd appreciate it if you let me know if I've done something dumb here :)
Andrew
-
@jimp
By the way; I do get this on reboot:Crash report begins. Anonymous machine information: amd64 12.1-STABLE FreeBSD 12.1-STABLE 1626cb2f005(factory-devel-12) pfSense Crash report details: PHP Errors: [11-Jun-2020 13:20:35 America/New_York] PHP Warning: Invalid argument supplied for foreach() in /etc/rc.dyndns.update on line 52 No FreeBSD crash data found.
-
@andrew_r said in Test Request: UPnP Fix for Multiple Consoles playing the same game / static port outbound NAT:
@jimp I had some manual rules set up from previous attempts, but they are fairly simple.
Can you try with those rules disabled?
Was that working before this version of UPnP?
We are primarily interested in knowing if this fixed situations that were broken before, or allows things to work with less intervention overall.
-
@jimp It was not working with the previous release. There were errors upnp errors in my log, and nothing showing in the upnp status area.
I'll test disabling the rules, and get back to you but, if it's any help, I forgot to add the second xbox to the alias group at first (so the rules weren't applied to it), and that xbox reported back that it was double-nat'ed. Similarly, I forgot with the 2nd PS4 and the third Switch, they reported NAT Type 3 (rather than 1) and Nat Type 3 (rather than 2).
Does this answer your question, or would it help for me to retest with the rules completely disabled? (I have hybrid mode set, by the way).
Andrew
-
@jimp PS. Is the boot error I posted something to be concerned with?
-
@andrew_r
Please test without any Outbound rules enabled.Also, do you have any games of the same console that previously had issues with joining a lobby or playing together? If so, are those working now?
-
@andrew_r said in Test Request: UPnP Fix for Multiple Consoles playing the same game / static port outbound NAT:
eans, but this seems to do the trick. I'd appreciate it if you let me know if I've done som
I tested Minecraft on both xboxes with and without the outbound nat rule enabled.
With; everything worked fine.
Without; the first xbox was able to connect to the realm fine, but the second hung on "loading resources" before it even got to the main menu for me to join the realm.So, I'd say the outbound rule is necessary, at least as far as Xbox goes.
Note that each console (including PS4 and Switch) reports the NAT as strict and/or double-nat'ed without the rule.
Oh, I also had "Enable NAT Reflection for 1:1 NAT" and turned on and "Automatic create outbound NAT rules that direct traffic back out to the same subnet it originated from." in the system/advanced/nat and firewall menu, if that makes a difference.
-
That's weird. In my tests, I did not have the outbound rules set up and it seemed to work.
-
@Marc05
That is strange.Not sure what's going on, but for some reason in my configuration, I require the outbound rules.
It may be to do with the ATT fiber connection? I've set the ATT box to behave as passthrough directly to the 5100, but I'm not sure that's doing exactly what I hope it is (or else why would people use pfatt?). I suspect that's the cause of the double nat error, and possibly why you're seeing a different result to me.
I guess the question I have is, if you add the rule, does your configuration still work?