Test Request: UPnP Fix for Multiple Consoles playing the same game / static port outbound NAT
-
Make sure you enable Pure NAT, and check "Enable automatic outbound NAT for Reflection" under System / Advanced / Firewall & NAT
-
@Marc05
After changing those settings this is what I get:[2.5.0-DEVELOPMENT][admin@BridgesSense.localdomain]/root: pfSsh.php playback pfanchordrill ipsec rules/nat contents: miniupnpd rules/nat contents: nat quick on em0 inet proto udp from 192.168.1.31 port = 9308 to any keep state label "192.168.1.31:9308 to 9308 (UDP)" rtable 0 -> 24.255.xxx.xxx port 9308 nat quick on em0 inet proto udp from 192.168.1.31 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> 24.255.xxx.xxx port 3074 nat quick on em0 inet proto udp from 192.168.1.30 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> 24.255.xxx.xxx port 3108 nat quick on em0 inet proto udp from 192.168.1.30 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> 24.255.xxx.xxx port 3167 nat quick on em0 inet proto udp from 192.168.1.30 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> 24.255.xxx.xxx port 3116 nat quick on em0 inet proto udp from 192.168.1.31 port = 9305 to any keep state label "192.168.1.31:9305 to 9305 (UDP)" rtable 0 -> 24.255.xxx.xxx port 9305 nat quick on em0 inet proto udp from 192.168.1.31 port = 9306 to any keep state label "192.168.1.31:9306 to 9306 (UDP)" rtable 0 -> 24.255.xxx.xxx port 9306 nat quick on em0 inet proto udp from 192.168.1.31 port = 3659 to any keep state label "EA Tunnel" rtable 0 -> 24.255.xxx.xx port 3659 nat quick on em0 inet proto udp from 192.168.1.30 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> 24.255.xxx.xxx port 3172 nat quick on em0 inet proto udp from 192.168.1.30 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> 24.255.xxx.xxx port 3096 rdr pass quick on em0 inet proto udp from any to any port = 9308 keep state label "192.168.1.31:9308 to 9308 (UDP)" rtable 0 -> 192.168.1.31 port 9308 rdr pass quick on em0 inet proto udp from any to any port = 3074 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.31 port 3074 rdr pass quick on em0 inet proto udp from any to any port = 3108 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.30 port 3074 rdr pass quick on em0 inet proto udp from any to any port = 3167 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.30 port 3074 rdr pass quick on em0 inet proto udp from any to any port = 3116 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.30 port 3074 rdr pass quick on em0 inet proto udp from any to any port = 9305 keep state label "192.168.1.31:9305 to 9305 (UDP)" rtable 0 -> 192.168.1.31 port 9305 rdr pass quick on em0 inet proto udp from any to any port = 9306 keep state label "192.168.1.31:9306 to 9306 (UDP)" rtable 0 -> 192.168.1.31 port 9306 rdr pass quick on em0 inet proto udp from any to any port = 3659 keep state label "EA Tunnel" rtable 0 -> 192.168.1.31 port 3659 rdr pass quick on em0 inet proto udp from any to any port = 3172 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.30 port 3074 rdr pass quick on em0 inet proto udp from any to any port = 3096 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.30 port 3074 natearly rules/nat contents: natrules rules/nat contents: openvpn rules/nat contents: tftp-proxy rules/nat contents: userrules rules/nat contents:
It now appears to be working. Tonight we will try it out and see if we can get matchmaking.
-
When playing I get Strict NAT on both devices. Should this be the case with UPnP setup?
-
Under firewall rules, make an IPv4 allow LAN to any rule with the advanced option checked "Allow IP options". Test again after and see what happens.
-
@Marc05 said in Test Request: UPnP Fix for Multiple Consoles playing the same game / static port outbound NAT:
Under firewall rules, make an IPv4 allow LAN to any rule with the advanced option checked "Allow IP options". Test again after and see what happens.
Still STRICT
-
You tried playing the game?
Try following the steps in this guide:
https://www.youtube.com/watch?v=whGPRC9rQYwThen test again, first without the outbound NAT rules, and second with them. Make sure the test involves playing a game, and not just doing a network test in the console.
-
Upgraded today to 2.5.0DEVELOPMENT and getting this error miniupnpd 80987 setsockopt(udp, IPV6_RECVPKTINFO): Invalid argument
After looking at the redmine, it did't look like i needed to update miniupnpd.Any ideas or more info needed?
-
Tested today with a base installation of 2.5.0DEV and two PS4s.
Base config, just UPNP enabled and Pure NAT.
I get NAT Type 2 on one console but always type 3 on the second.
I can see the following:
miniupnpd rules/nat contents: nat log quick on ix0.10 inet proto udp from 10.XX.XX.XX port = 9308 to any keep state label "10.XX.XX.XX:9308 to 9308 (UDP)" rtable 0 -> XX.XX.XX.XX port 9308 rdr pass log quick on ix0.10 inet proto udp from any to any port = 9308 keep state label "10.XX.XX.XX:9308 to 9308 (UDP)" rtable 0 -> 10.XX.XX.XX port 9308
So UPNP seems to be working but for some reason only allowing one console, any additional debugging I should do here?
-
It seems that static ports on outbound NAT is still necessary. Make sure to create that rule as well.
-
@Marc05 static port NAT is a workaround, and not a nice one.
The implementation we hope for is that two or more consoles work with only UPNP without any other special rules (similar to consumer grade routers)
The output above proves that upnp is working, I guess now the challenge is figuring out why only for one device/console. -
In my previous test earlier in the thread, I had tested with the patch provided in the redmine bug entry. I believe I had tested without the outbound rule enable, and just the patch. The results I posted seem to have UPnP working as intended for multiple consoles. After removing that patch and updating to the latest dev version of pfSense with the miniupnp RC version, the outbound rule was required.
@jimp
Did the code change from your patch make it into the miniupnp RC version provided in the latest dev release of pfSense? -
It wasn't my code/patch, I had just posted a compiled version of the code from miniupnpd. The latest RC code should be what's in snapshots now.
-
This is a fresh install upgraded the 2.5.0
I have enabled
Pure NAT
Automatic outbound NAT reflection
Default LAN to any rule has IP options
Enabled UPnP & NAT-PMP both have port mapping onSo the most basic setup
COD Warzone
Both machines can connect and play the game however both report strict NATWindows Xbox networking
Both machines can form Teredo IPV6 over IPV4 tunnel but it reports strict NATminiupnpd rules/nat contents: nat quick on pppoe0 inet proto udp from 192.168.1.100 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> 81.158.220.33 port 3074 nat quick on pppoe0 inet proto udp from 192.168.1.30 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> 81.158.220.33 port 3160 nat quick on pppoe0 inet proto udp from 192.168.1.100 port = 55226 to any keep state label "Teredo 192.168.1.100:55226->55226 UDP" rtable 0 -> 81.158.220.33 port 55226 nat quick on pppoe0 inet proto udp from 192.168.1.30 port = 50805 to any keep state label "Teredo 192.168.1.30:50805->50805 UDP" rtable 0 -> 81.158.220.33 port 50805 rdr pass quick on pppoe0 inet proto udp from any to any port = 3074 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.100 port 3074 rdr pass quick on pppoe0 inet proto udp from any to any port = 3160 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.30 port 3074 rdr pass quick on pppoe0 inet proto udp from any to any port = 55226 keep state label "Teredo 192.168.1.100:55226->55226 UDP" rtable 0 -> 192.168.1.100 port 55226 rdr pass quick on pppoe0 inet proto udp from any to any port = 50805 keep state label "Teredo 192.168.1.30:50805->50805 UDP" rtable 0 -> 192.168.1.30 port 50805
I then tried the rules andrew_r posted earlier
To do this the machines were set with a static IP and outbound NAT rule was created with Static port option selected
(I just realised I did not have anything in the ACL field but I also did not select default deny so it should not matter)
I restarted the pf box and both machinesCOD Warzone
The first machine connects and can play with moderate NAT
The second machine cannot connectWindows Xbox networking
Both machines report an Open NATminiupnpd rules/nat contents: nat quick on pppoe0 inet proto udp from 192.168.1.6 port = 50805 to any keep state label "Teredo 192.168.1.6:50805->50805 UDP" rtable 0 -> 86.138.134.168 port 50805 nat quick on pppoe0 inet proto udp from 192.168.1.6 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> 86.138.134.168 port 3074 nat quick on pppoe0 inet proto udp from 192.168.1.7 port = 55226 to any keep state label "Teredo 192.168.1.7:55226->55226 UDP" rtable 0 -> 86.138.134.168 port 55226 rdr pass quick on pppoe0 inet proto udp from any to any port = 50805 keep state label "Teredo 192.168.1.6:50805->50805 UDP" rtable 0 -> 192.168.1.6 port 50805 rdr pass quick on pppoe0 inet proto udp from any to any port = 3074 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.6 port 3074 rdr pass quick on pppoe0 inet proto udp from any to any port = 55226 keep state label "Teredo 192.168.1.7:55226->55226 UDP" rtable 0 -> 192.168.1.7 port 55226
Interestingly I ran the Xbox networking test first and as you can see above an automatic rule was created for both machines, however, when I tried to play Warzone it did not work but also the previously generated automatic rule disappeared
nat quick on pppoe0 inet proto udp from 192.168.1.6 port = 50805 to any keep state label "Teredo 192.168.1.6:50805->50805 UDP" rtable 0 -> 86.138.134.168 port 50805 nat quick on pppoe0 inet proto udp from 192.168.1.6 port = 3074 to any keep state label "DemonwarePortMapping" rtable 0 -> 86.138.134.168 port 3074 rdr pass quick on pppoe0 inet proto udp from any to any port = 50805 keep state label "Teredo 192.168.1.6:50805->50805 UDP" rtable 0 -> 192.168.1.6 port 50805 rdr pass quick on pppoe0 inet proto udp from any to any port = 3074 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.6 port 3074
-
Still getting stick Nat.
2.5.0-DEVELOPMENT (amd64)
built on Wed Jul 08 13:03:53 EDT 2020
FreeBSD 12.1-STABLEipsec rules/nat contents:
miniupnpd rules/nat contents:
nat quick on em0 inet proto udp from 192.168.1.26 port = 55768 to any keep state label "Teredo 192.168.1.26:55768->55768 UDP" rtable 0 -> (WAN IP) port 55768
rdr pass quick on em0 inet proto udp from any to any port = 55768 keep state label "Teredo 192.168.1.26:55768->55768 UDP" rtable 0 -> 192.168.1.26 port 55768natearly rules/nat contents:
natrules rules/nat contents:
openvpn rules/nat contents:
tftp-proxy rules/nat contents:
userrules rules/nat contents:
-
@m0t0k0 I'm having the same problem with WZ on 2 XBOX consoles
-
@borediniraq I gave up and moved back to OpenWRT works with just the click of a button
-
I'm not sure when it happened, but I installed the latest dev update as of last night and it's broken this again.
-
Update: false alarm; somehow something changed in one of the updates that broke my OpenVPN connection. "Fixing" that ended up routing ALL traffic through the VPN. Breaking it again fixed the NAT problem, but there is still something squarely with the OpenVPN client rules.
I hadn't changed anything in the rules before it stopped working. I'll try setting it up again from scratch to see if that fixes it, but...
Hopefully the 2.5.0 stable release will be out soon, that's all I can say on that! :/
-
@jimp quick question as this popped up in my subforum: does the new miniupnp daemon to test or the version in 2.5 also have the patch for https://redmine.pfsense.org/issues/10398 included?
Namely that was this miniupnp discussion: https://github.com/miniupnp/miniupnp/issues/433 about problems with RFC1918 addresses on WAN.
Also: the snapshots now already contain the new version, no need to manually patch/install it anymore?
Thanks,
\jens -
Is this topic really going to die like all the other previous topics on this same issue over the years. This has been ongoing for years now. Can we get a little more developer traction on this issue? What is needed at this point from the pfSense side of things? What is needed for the miniupnpd side of things? Please, lets not let this die again.