Feature #7727
closeduPnP fails to properly give out subsequent reservations when multiple gaming systems are playing the same game/using the same port
100%
Description
It's a bug with pfsense, at least in my eyes (nearly 15 years experience in IT and am a senior security engineer with a fortune 500 company). You currently cannot have 2 systems, whether console or gaming PC playing the same game at the same time using pfsense. The second client will always fail to connect. I have done everything you are supposed to do:Static outbound ports, uPnP ACL, firewall rules, NAT reflection. I even hired a freelancer with pfsense experience going back to when it was monowall. He took 10 minutes to look at my config and told me that it looked exactly how it was supposed to look. He then did his own troubleshooting and came to the exact conclusion that I did. uPnP is broken in pfsense 2.4.
Just to prove a point I plugged in my netgear r8500, booted it up, updated its firmware and restored defaults. Upon the subsequent reboot, the 2 clients picked up uPnP reservations immediately (unlike pfsense where it takes 30+ seconds to get the one that does eventually pickup) and both reported back with open nat. I was able to join the same lobbys with both clients and play together for extended periods.
Files
Updated by Anonymous about 7 years ago
the game in question is "For Honor", but im pretty sure it affects any game that uses peer to peer matchmaking. There is also an issue with being the host, but that may be a hard limitation that cannot be overcome, unsure.
Updated by Shane Angelo over 5 years ago
Hi All,
I have experienced the same issue as reported in the bug descrip.
I have also discovered when searching the net for a solution that many other folks have too, all without solutions. I have followed the guides available which covers the configurations listed by the original bug descrip and gives me open NAT as reported on all the xbox consoles (3 in total).
However, when playing multiplayer from with LAN network using the same game, the second and subsequent xboxes to be connected always fails to connect to the game lobby.
With only one xbox there is no issue connecting and playing.
When playing different game titles at the same time there are no issues connecting and playing
Access to the lobby fails only for the second connected xbox console when playing the same title concurrently.
As a test, I replaced the pfsense firewall with an off the shelf generic router with uPnP enabled and immediately all xboxes are able to connect. No other settings were changed on the network.
I have a basic knowledge, but I am more than happy to help do my part to help resolve this issue. I'd rather not replace pfsense for all the other benefit it brings on account of the occasional xbox game with my son.
Seen this on Call of Duty WW2, Titanfall 2 and now Apex Legends. I have no doubt that it affects other titles too.
As a workaround I am going to try putting the second console in a DMZ.
Thanks,
CV8R
Updated by Jim Pingle about 5 years ago
- Tracker changed from Bug to Feature
- Project changed from pfSense Packages to pfSense
- Category set to UPnP/NAT-PMP
- Affected Version deleted (
2.4.x) - Affected Architecture deleted (
amd64)
AFAIK This is because last I looked, miniupnpd doesn't support its "masquerade" options on FreeBSD/pf like it does on Linux/netfilter. When it is set to masquerade, it sets up an outbound (snat/source nat) mapping to maintain a static source port for the same port requested by the client. Without that, you only get inbound NAT, and if you setup static port on outbound NAT you're only likely to get a single console working as expected.
I doubt there is anything we can do here unless someone adds support for that to miniupnpd
Updated by Russell Graville over 4 years ago
Jim Pingle wrote:
AFAIK This is because last I looked, miniupnpd doesn't support its "masquerade" options on FreeBSD/pf like it does on Linux/netfilter. When it is set to masquerade, it sets up an outbound (snat/source nat) mapping to maintain a static source port for the same port requested by the client. Without that, you only get inbound NAT, and if you setup static port on outbound NAT you're only likely to get a single console working as expected.
I doubt there is anything we can do here unless someone adds support for that to miniupnpd
I see it may have been updated in miniupnpd for FreeBSD. How soon can this me imported into pfsense?:
https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/Changelog.txt
$Id: Changelog.txt,v 1.458 2020/03/29 09:07:37 nanard Exp $
2020/03/29:
Fix FreeBSD build
Updated by Jim Pingle over 4 years ago
That isn't relevant to this feature. It's a different FreeBSD issue. I don't see anything about masquerade being added to pf.
Updated by Marc 05 over 4 years ago
Jim Pingle wrote:
That isn't relevant to this feature. It's a different FreeBSD issue. I don't see anything about masquerade being added to pf.
Looks like there is some progress on this:
"netfilter: addmasqueraderule() even if internal/external ports are the same"
https://github.com/miniupnp/miniupnp/commit/e49d44f700355552c45a95c1e067e4a815479557
I hope this gets patched in as a hotfix or something soon - many people have been waiting on this for a long time!
Updated by Marc 05 over 4 years ago
If it ends up working for you, would you provide it in a way that I could apply it using the System Patches package? Would be good to update this thread as well https://github.com/miniupnp/miniupnp/issues/413
Updated by Jim Pingle over 4 years ago
Marc05 M wrote:
Looks like there is some progress on this:
"netfilter: addmasqueraderule() even if internal/external ports are the same"
https://github.com/miniupnp/miniupnp/commit/e49d44f700355552c45a95c1e067e4a815479557I hope this gets patched in as a hotfix or something soon - many people have been waiting on this for a long time!
That still isn't adding masquerade support for PF. It's not related.
Joel Samson wrote:
Kind of ridiculous this has has been open for nearly 3 years and nothing, I am in the process of setting up my build server to compile this above and manually install it over the pfsense base version using the instructions found here: https://docs.netgate.com/pfsense/en/latest/packages/installing-freebsd-packages.html?highlight=pkg as I no longer have time to wait, either a solution is applied or I move back to Untangle.
You need to advocate to miniupnpd for them to add support for masquerade to their PF code. It's a missing feature in miniupnpd, not much we can do about that.
Updated by Joel S over 4 years ago
Jim Pingle wrote:
Marc05 M wrote:
Looks like there is some progress on this:
"netfilter: addmasqueraderule() even if internal/external ports are the same"
https://github.com/miniupnp/miniupnp/commit/e49d44f700355552c45a95c1e067e4a815479557I hope this gets patched in as a hotfix or something soon - many people have been waiting on this for a long time!
That still isn't adding masquerade support for PF. It's not related.
Joel Samson wrote:
Kind of ridiculous this has has been open for nearly 3 years and nothing, I am in the process of setting up my build server to compile this above and manually install it over the pfsense base version using the instructions found here: https://docs.netgate.com/pfsense/en/latest/packages/installing-freebsd-packages.html?highlight=pkg as I no longer have time to wait, either a solution is applied or I move back to Untangle.
You need to advocate to miniupnpd for them to add support for masquerade to their PF code. It's a missing feature in miniupnpd, not much we can do about that.
To be fair, that is already done as found here: https://github.com/miniupnp/miniupnp/issues/413 and the change discribed above does seem to be related.
Otherwise, if you have another feature missing not identified in that Github change for miniupnpd, then YOU should request the change to them, as clearly it's an open request here for as long as 3 years and you have still not reached out to the vendor?
Sounds like some slacking on some side. Defiantly not the client side of your software lmao.
Updated by Jim Pingle over 4 years ago
Nothing on that bug report mentions pf, all of the example commands are for Linux. It may be about masquerade mode issues in general but it doesn't appear to be specifically doing anything for pf.
Updated by Marc 05 over 4 years ago
Hi Jim. Given you likely understand the issue much better than I, would you help me in making the request necessary to resolve this? What exactly should be requested - would it just be creating a feature request in the miniupnp repo asking for "add support for masquerade to their PF code" and nothing else?
Updated by Joel S over 4 years ago
Marc05 M wrote:
Hi Jim. Given you likely understand the issue much better than I, would you help me in making the request necessary to resolve this? What exactly should be requested - would it just be creating a feature request in the miniupnp repo asking for "add support for masquerade to their PF code" and nothing else?
I would agree with this. I am willing to submit the request on Github for pfsense specific issues.
But we need to better understand what to request, what support needs to be added specifically for PFsense?
While those changes are specific to Linux, PFsense is FreeBSD based (Unix-based) and you would expect the feature to be added/migrated fairly easily if we can get a clear picture of what needs to be added/ported to the pfsense (unix-based) version.
Thanks,
Updated by Jim Pingle over 4 years ago
Marc05 M wrote:
Hi Jim. Given you likely understand the issue much better than I, would you help me in making the request necessary to resolve this? What exactly should be requested - would it just be creating a feature request in the miniupnp repo asking for "add support for masquerade to their PF code" and nothing else?
I'm not sure what detail they would need beyond "Add masquerade feature to pf support" or something along those lines. Currently the masquerade references are all inside their netfilter
code which is only on Linux.
The request is not specific to pfSense, but pf in general (So, primarily FreeBSD and OpenBSD).
Updated by Jim Pingle over 4 years ago
I don't see anything like that in the linked reference. Only confirmation that the issue/commit only apply to netfilter.
And no, an update for miniupnpd wouldn't be in the package manager. It's a base system package and would only be updated with a new release.
Updated by Jim Pingle over 4 years ago
Joel S wrote:
He specifically comments that "I'm stupid, e49d44f is only for netfilter :( it will change nothing for pf :( I don't know how I forgot this issue was about netfilter in the 1st place."
Obviously, he will ask for a new bug report outside of the netfilter one, or simply make the commit change from that existing bug now that he realizes his mistake that the changes are only for linux and not Pfsense.
I saw that, but nothing in that implies any action for pf. Only that the issue is about netfilter. There is no masquerade code at all for pf, they'd have to completely port over the feature. You're reading an awful lot between the lines there that isn't even implied. Kudos to you for being optimistic, but I'm not holding my breath on it happening any time soon.
I hope you generally understand that once this is done, this issue then falls directly on you to update the package on the base system if it's not available as an update.
Not sure why it sounds like you keep trying to redirect this, it's coming your way either way within a few days at most (Likely Thursday it will be resolved). At which point this thread will become the highlight, not: https://github.com/miniupnp/miniupnp/issues/413
When they have it in their code base and we know it works on FreeBSD+pf, it will find its way into a pfSense release. We redirect the issue to miniupnpd because they're the ones that need to add the feature first. It's entirely up to them, until they include it in a release.
Updated by Marc 05 over 4 years ago
A bit off-topic:
It's funny that throughout all of the years, many people have encountered and posted about the issue in one way or another, and only in the last few days has there been any semblance of progress.
Thank you Joel for all of the follow-up, and please keep it up. It's appreciated, even if you are just copying and pasting.
Thank you Jim for telling us what to do :D No doubt there are plenty of other things in need of attention. I hope this issue finally gets its spotlight after being background noise for so long.
Updated by Cameron O over 4 years ago
Hi, I'm also interested in this issue and really glad to see there's an active effort to get it resolved. Thanks Joel, Marc, and Jim!
I'm posting because I think it may help myself and others to clearly understand the issue.
Based on comments in the linked Github issue, past forum posts, and how long this issue has been around, I think users have been at least a little confused about what exactly the problem is.
- To easily allow multiple devices to play the same online games, pfsense needs to be able to create an inbound and outbound NAT rule for every UPnP port forward.
- The version of the uPnP library used by pfsense only allows creating inbound NAT rules.
Jim did sort of say as much in the beginning, I'm just not sure if my reading is correct.
Jim Pingle wrote:
When it is set to masquerade, it sets up an outbound (snat/source nat) mapping to maintain a static source port for the same port requested by the client. Without that, you only get inbound NAT, and if you setup static port on outbound NAT you're only likely to get a single console working as expected.
"Masquerade" has been thrown around a lot in this thread, and it's pretty confusing, especially if the issue is more about having a two-way mapping.
nefilter's iptables MASQUERADE option just allows making an outbound NAT (SNAT) rule without specifying the public external IP address.
I can see why this is necessary since many users might have dynamic IP addresses, but it does look like pf can do the same thing—pulling an address from an interface (eth0 in this example).
IPTABLES
iptables -t nat -a POSTROUTING -s 1.2.3.4 -o eth0 -j MASQUERADE
PF
nat on eth0 from 1.2.3.4 to any -> (eth0)
So is the pf-based miniupnpd just missing some internal or API feature that's in the netfilter-based version or does pf itself actually not have a way to do what iptables does?
There's a big difference if this some functional gap between netfilter and pf or something of an oversight/backlogged feature in miniupnpd.
Updated by Star Jesus over 4 years ago
I bought the SG-3100 because I wanted to have the BiS router for epic gaming moments
Turns out one of the "features" of the wonderful pfsense software is that two PCs can't play Call of Duty at the same time together
What was supposed to be an epic moment is actually an epic fail
I spent my Trump bucks on this crap
Updated by Jim Pingle over 4 years ago
Cameron O wrote:
So is the pf-based miniupnpd just missing some internal or API feature that's in the netfilter-based version
pf is capable of doing this kind of NAT, it's the same kind of NAT rules people set manually to make single consoles work (static port).
The problem is that miniupnpd doesn't have any pf code to set that up (no masquerade code for pf in miniupnpd)
Updated by Joel S over 4 years ago
Jim Pingle wrote:
pf is capable of doing this kind of NAT, it's the same kind of NAT rules people set manually to make single consoles work (static port).
The problem is that miniupnpd doesn't have any pf code to set that up (no masquerade code for pf in miniupnpd)
Marc05 M wrote:
A bit off-topic:
It's funny that throughout all of the years, many people have encountered and posted about the issue in one way or another, and only in the last few days has there been any semblance of progress.
Thank you Joel for all of the follow-up, and please keep it up. It's appreciated, even if you are just copying and pasting.
Thank you Jim for telling us what to do :D No doubt there are plenty of other things in need of attention. I hope this issue finally gets its spotlight after being background noise for so long.
Opened a new issue for this pf masquerade feature implementation at the dev's request, it can be found here: https://github.com/miniupnp/miniupnp/issues/448
The other issue linked was cleaned up to keep it related to Netfilter, as expected though this is still moving, I was not surprised he asked for a new issue report as I mentioned above.
Maybe Jim can review the new issue created, and provide feedback on anything or any details missing which I can add :)
Thanks again all!
Happy to see this moving in the right direction finallllllyyyy!!!
Updated by Joel S over 4 years ago
Jim Pingle wrote:
pf is capable of doing this kind of NAT, it's the same kind of NAT rules people set manually to make single consoles work (static port).
The problem is that miniupnpd doesn't have any pf code to set that up (no masquerade code for pf in miniupnpd)
miniupnpd dev would like the following information from our setup:
the AddPortMapping() requests done
the subsequent pf rules created by miniupnpd
the ones that would be expected so the traffic flows properly and the game works on all xbox's
Which commands can I use to get the first 2 results? I can at least provide that to him to start.
As for the rules/flows to be expected, we may need to wait to see what is actually happening...
Thanks again guys.
Joel S.
Updated by Joel S over 4 years ago
Jim Pingle wrote:
pf is capable of doing this kind of NAT, it's the same kind of NAT rules people set manually to make single consoles work (static port).
The problem is that miniupnpd doesn't have any pf code to set that up (no masquerade code for pf in miniupnpd)
He also mentioned how it looks like pf used in pfSense is an old version as rdr-anchor are not used since OpenBSD 4.7 (2010)
Updated by Thomas BERNARD over 4 years ago
Hello, I'm miniupnp main author.
The user Joel S came from here to open an issue on https://github.com/miniupnp/miniupnp/issues/448
From the start he showed no understanding of the problem, just asking for "high priority" fixing of a bug he was unable to expose clearly.
He then became very disrespectful, requiring me to work on his problem and opening several duplicate issues.
In 15 years, I have not seen such disrespect behavior from a "bug reporter".
The pfSense community has given a lot to miniupnp over the years, that's a shame that today such a spoiled boy wastes our time.
To come back to the issue itself:
I have seen no detailed description of the problem (AddPortMapping requests from the consoles, the pf rules that are produced, etc.) but I guess it has something to do with the inability of miniupnp/pf to make "bidirectional port mappings" it is possible to do with netfilter : ie when there is a port mapping added for external port 1111 to internal port 2222. Outbound UDP packets from port 2222 are not forced to be translated to source port 1111.
If it is confirmed that is it the real issue here, and if someone is able to produce the pf rules needed, I will be able to implement it in miniupnp pf backend.
But I'm afraid it is a feature currently not available in pf.
The static-port option to nat in pf just works for mapping with same external and internal port, so that source port 2222 is kept and not mapped to a random port.
Regards,
Thomas Bernard
Updated by Joel S over 4 years ago
Thomas BERNARD wrote:
Hello, I'm miniupnp main author.
The user Joel S came from here to open an issue on https://github.com/miniupnp/miniupnp/issues/448
From the start he showed no understanding of the problem, just asking for "high priority" fixing of a bug he was unable to expose clearly.
No, I fully understand the problem. In-fact, you show zero understanding of the problem.
I don't understand the solution, there's a difference, which is why we came to you and Jim. Sadly after 3 years this is where we are, still no where with a solution.
He then became very disrespectful, requiring me to work on his problem and opening several duplicate issues.
In 15 years, I have not seen such disrespect behavior from a "bug reporter".The pfSense community has given a lot to miniupnp over the years, that's a shame that today such a spoiled boy wastes our time.
To come back to the issue itself:
I have seen no detailed description of the problem (AddPortMapping requests from the consoles, the pf rules that are produced, etc.) but I guess it has something to do with the inability of miniupnp/pf to make "bidirectional port mappings" it is possible to do with netfilter : ie when there is a port mapping added for external port 1111 to internal port 2222. Outbound UDP packets from port 2222 are not forced to be translated to source port 1111.
If it is confirmed that is it the real issue here, and if someone is able to produce the pf rules needed, I will be able to implement it in miniupnp pf backend.
But I'm afraid it is a feature currently not available in pf.The static-port option to nat in pf just works for mapping with same external and internal port, so that source port 2222 is kept and not mapped to a random port.
Regards,
Thomas Bernard
I would agree, I have never found someone so disrespectful to someone simply asking a question and/or for assistance. I love the name calling though, keep it up ;)
Doesn't bother me none, maybe that's all how your french coders are, all with their heads up their ass. Let me help you understand the issue. "pfsense = toi et Jim corrigez le probleme"
I would love for you, no I would dare for you, to show me in the thread where I become disrespectful, at least until you told me to stop "wasting your time".
You and Jim has been wasting everyone's time from the start, if you could of simply talked to each-other as we requested, this wouldn't be an issue, but somehow the last time was in 2010, and since then you guys have been scared of each
other.
We simply want you two to stop ignoring it for over 3 years and start looking into it. Not a hard request.
Finally someone comes out from the darkness and crosses worlds, just had to piss him off a bit but that's fine. I don't care if what Jim is asking for isn't possible or if I don't understand. "THATS WHY YOUR HERE" :D
Now if you and Jim come to the conclusion this isn't a bug and everyone's configuration is wrong, at least it will become public knowledge. But I am pretty sure that is not the case ;) And you will need to prove it with all the users with the issue.
Get off your high horse bud, start being respectful to people asking you questions if you don't want to be shown disrespect, and don't kill the messenger, as you said all I do is copy and paste.
If it doesn't make sense, don't blame me. Blame the people asking me to bring it to you and telling us what to say (Jim).
But you don't deserve any respect for closing an issue early and shitting on the messenger. I am not impressed rolf. I'll be impressed when you do your job correctly and drop the god complex.
I swear you don't even read, you just slam the ban button, which sadly will not work.
Maybe if you and Jim and discussed this conversation 3 years ago, I wouldn't need to be a dick to get you to do stuff ;) But I don't mind it. It's moving ;)
Thanks,
Joel S.
Updated by Jim Pingle over 4 years ago
Joel,
Please stop. That kind of unhelpful dialog is unproductive and not welcome here, and is getting in the way of any meaningful discussion about solving the problem.
Updated by Jim Pingle over 4 years ago
Thomas BERNARD wrote:
I have seen no detailed description of the problem (AddPortMapping requests from the consoles, the pf rules that are produced, etc.) but I guess it has something to do with the inability of miniupnp/pf to make "bidirectional port mappings" it is possible to do with netfilter : ie when there is a port mapping added for external port 1111 to internal port 2222. Outbound UDP packets from port 2222 are not forced to be translated to source port 1111.
If it is confirmed that is it the real issue here, and if someone is able to produce the pf rules needed, I will be able to implement it in miniupnp pf backend.
But I'm afraid it is a feature currently not available in pf.
OK, it's possible I'm misunderstanding what that does. I thought it setup an outbound rule which did the opposite of that, which translated outbound packets from the target to use the same port requested for UPnP. So for example:
S:12345->E:1111->C:2222
C:X->E:1111->S:Y (for new connections not replies on the state created for 1111->2222 since those would always reply from 2222->1111)
The pf rule for that would look something like this (client 10.6.0.11, ext addr 198.51.100.6, server 1.2.3.4):
nat on $WAN inet proto tcp from 10.6.0.11/32 to 1.2.3.4/32 -> 198.51.100.6/32 port 1111
Though I could see that failing in some cases if an overlapping state already exists for an inbound connection. It would only work for a single concurrent outbound connection to the same remote server, additional connections would fail since the external state portions would conflict.
From your last comment it sounds like what the netfilter rules do is to allow the replies to have a different source port on the way out, sort of like:
S:12345->E:1111->C:2222
C:2222->E:<some random port>->S:12345
I don't see a way to that in pf but I'm not sure I'm reading your statement properly. That doesn't seem to make sense, since the server would typically reject replies from a source port it wasn't actively communicating with.
Do you have an example set of netfilter rules/chains which shows the type of rules you are describing? That might help make it more clear since I'm fairly certain the problem is my (lack of) understanding.
Updated by Thomas BERNARD over 4 years ago
We have not enough precise details on the issue :
What AddPortMapping requests the XBoxes are doing and what traffic they are expecting.
It is important to note that everything applies only to UDP, not TCP.
My guess is that somehow they are expecting their outbound UDP traffic to be translated to a precise port.
When opening a port mapping with external port 1111 and internal port 2222.
If that is the Remote that sends the 1st packet to <public ip>:1111 everything works fine.
subsequent packets sent by the XBox to the remote will be translated with a source port of 1111 (existing "UdP connection")
But if that is XBox that sends the 1st packet to a remote host, the source port would either be kept as 2222 (static-port set) or a random one (non pre-existing "UDP connection")
With netfilter/iptables, we are using SNAT to force translation to the wanted source port.
Updated by Thomas BERNARD over 4 years ago
Joel S wrote:
Jim Pingle wrote:
Joel,
Please stop. That kind of unhelpful dialog is unproductive and not welcome here, and is getting in the way of any meaningful discussion about solving the problem.
I will gladly stop now that progress is being made... Observing only for now. The fact is I had to do this, or we would be waiting another 2 years as you said, "You need to advocate to miniupnpd for them to add support for masquerade to their PF code" and we were tired waiting for nothing.
It was helpful in that regard :)Thanks!
Joel S.
I hope you will someday stop believing we are at your service. As far as I know, Jim is not your employee. He surely has more urgent issues than you and your friends not being able to play your favorite video games.
The fact that you believe that progress is being made just shows how deeply you don't understand the issue.
And the fact that you believe it is thanks to your aggressive behavior proves that you are not going to improve it anytime.
Such disrespect ruins the motivation of people involved in OSFS projects.
Updated by Jim Pingle over 4 years ago
I removed the irrelevant comments made after the warning and locked their account. Further comments unrelated to the technical nature of the issue alone will also be removed. Such comments only further erode the available time developers have to work on actual problems.
Updated by Dakota Marshall over 4 years ago
I've been watching this bug for the past 2 years and am excited that there is some traction on it. Though I'm very disappointed that it took such a sour turn. I would love to be of assistance on trying to figure out what exactly is going on. To note first I currently do not have an active PfSense box to test but I can likley get one up and running to help with any testing.
At this point, what is needed to try and further troubleshoot this issue? I will be more than happy to assist the best I can.
I do know that this issue is not isolated to Xbox if that matters. It applies to PC aswell, really any game service that uses matchmaking services over UDP. If it would help, I can setup 2 devices behind a pfsense router and attempt to have them connect to the same matchmaking service, I can do a full packet capture on all devices. Would there be any other details needed to try and troubleshoot?
Updated by Thomas BERNARD over 4 years ago
Dakota Marshall wrote:
At this point, what is needed to try and further troubleshoot this issue? I will be more than happy to assist the best I can.
I do know that this issue is not isolated to Xbox if that matters. It applies to PC aswell, really any game service that uses matchmaking services over UDP. If it would help, I can setup 2 devices behind a pfsense router and attempt to have them connect to the same matchmaking service, I can do a full packet capture on all devices. Would there be any other details needed to try and troubleshoot?
- We first need the AddPortMapping requests sent by the 2 (or more) devices. (you can capture traffic on the miniupnpd HTTP port).
if you run miniupnpd in debug mode, it will also send theses info to syslog.
- then you can check which pf rules are created.
depending on pf version, they are visible with
pfctl -a miniupnpd -s rules
and/or
pfctl -a miniupnpd -s nat
(if the miniupnpd version compiled for pfSense does use the "miniupnpd" anchor)
- then you can capture all traffic on your lan on the redirected port so we would know if game send packets to a remote host before it receives any from the same host.
After that we'll have confirmation of the diagnostics. But still no solution to make outgoing UDP packets translated with the right source port.
Updated by Connor Ness over 4 years ago
I can test this right now. I currently have two PCs unable to play Call of Duty together behind a pfSense 2.4.4-RELEASE-p3 box via upnp.
I have configured:
System -> Advanced -> Firewall & NAT -> Network Address Translation -> NAT Reflection mode for port forwards = "Pure NAT"
System -> Advanced -> Firewall & NAT -> Network Address Translation -> Enable automatic outbound NAT for Reflection = "True"
Firewall -> Aliases -> IP -> Firewall Aliases IP = [{"UPnPGames": ["192.168.1.48", "192.168.1.49", "192.168.1.50"]}]
Firewall -> NAT -> Outbound -> Outbound NAT Mode -> Mode = "Hybrid Outbound NAT rule generation"
Firewall -> NAT -> Outbound -> Mappings = [{"Enabled": True, "Interface": "WAN", "Source": "UPnPGames", "Source Port": "*", "Destination": "*", "Destination Port": "*", "NAT Address": > "WAN address", "NAT Port": "*", "Static Port": True, "Description": ""}]
Services -> UPnP & NAT-PMP -> UPnP & NAT-PMP Settings -> Enable = "True"
Services -> UPnP & NAT-PMP -> UPnP & NAT-PMP Settings -> UPnP Port Mapping = "True"
Services -> UPnP & NAT-PMP -> UPnP & NAT-PMP Settings -> Log Packets = "True"
Services -> UPnP & NAT-PMP -> UPnP & NAT-PMP Settings -> Default Deny = "True"
Services -> UPnP & NAT-PMP -> UPnP Access Control Lists -> ACL Entries = ["allow 0-65535 192.168.1.48/32 0-65535", "allow 0-65535 192.168.1.49/32 0-65535"]
My PC (.48) was able to connect with "Open" NAT. My brother's PC (.49) was unable; the game launches, then complains that it was unable to connect to the server. His only option from there is to quit to desktop.
Here is the response to `pfctl -a miniupnpd -s rules`:
pass in log quick on re0 inet proto udp from any to 192.168.1.48 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0
pass in log quick on re0 inet proto udp from any to 192.168.1.49 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0
pass in log quick on re0 inet proto udp from any to 192.168.1.49 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0
pass in log quick on re0 inet proto udp from any to 192.168.1.49 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0
pass in log quick on re0 inet proto udp from any to 192.168.1.49 port = 3074 flags S/SA keep state label "DemonwarePortMapping" rtable 0
Here is the response to `pfctl -a miniupnpd -s nat`:
rdr log quick on re0 inet proto udp from any to any port = 3074 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.48 port 3074
rdr log quick on re0 inet proto udp from any to any port = 3148 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.49 port 3074
rdr log quick on re0 inet proto udp from any to any port = 3194 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.49 port 3074
rdr log quick on re0 inet proto udp from any to any port = 3155 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.49 port 3074
rdr log quick on re0 inet proto udp from any to any port = 3162 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.49 port 3074
Here is a pastebin dump of the packet capture, listening on 2189:
Let me know if you want the .cap file, and how you would prefer I deliver it.
Since it seems the redirected port jumps around while the game client (re)tries to get a upnp session, I'm not sure how to listen to traffic on that port without capturing all traffic from my brother's pc on the interface, which is what I have done. I'd be willing to share this directly, but not publicly.
Also, it seems that checking "Log Packets" does not put them in the syslog. After a cursory glance, I don't see that they're being logged at all. If I'm not looking in the right place, let me know.
If you need me to check anything else, I may not be able to until tomorrow. Hopefully this helps.
Updated by Thomas BERNARD over 4 years ago
Connor Ness wrote:
If you need me to check anything else, I may not be able to until tomorrow. Hopefully this helps.
unfortunately it shows that everything is OK when the external port is mapped to the same internal port (3074 => 192.168.1.48:3074)
but it doesn't work for (3148 => 192.168.1.49:3074)
I don't know how to force pf to translate outgoing UDP packets from 192.168.1.49:3074 to src <public ip>:3148
my email address is available here : https://miniupnp.tuxfamily.org/
thank you.
Updated by Connor Ness over 4 years ago
Thank you very much, Thomas. I emailed the captures to you.
For what it's worth, I did have both PC's showing "Open" NAT types, and both were able to join each other's lobby, without upnp. I manually created port forwards and outbound mappings.
For outbound, I had:
192.168.1.48:3074 => WAN:13074
192.168.1.49:3074 => WAN:23074
For port forwards:
ANY:13074 => 192.168.1.48:3074
ANY:23074 => 192.168.1.49:3074
This worked, but my understanding is that this is what upnp should be able to achieve automatically. I'm imagining the process looks something like this:
1. PC1 requests upnp create outbound mapping and port forward for PC1:3074
2. upnp checks that a session is not currently alive for WAN:3074
3. there is no session, so create outbound mapping and port forward for WAN:3074 <=> PC1:3074, and we are done
4. PC2 requests upnp create outbound mapping and port forward for PC2:3074
5. upnp checks that a session is not currently alive for WAN:3074
6. there is a session, deny the request to PC2
7. PC2 requests upnp create outbound mapping and port forward for PC2:3076 (picked from a hat)
8. upnp checks that a session is not currently alive for WAN:3076
9. there is no session, so create outbound mapping and port forward for WAN:3076 <=> PC2:3076, and we are done
From what we're seeing, upnp is indeed creating these sessions, but the client is still unable to connect, so it retries until it decides no connection can be made. But with my manual port forwards and outbound mappings, it works as expected. Would it be worth setting those back up and comparing the entries?
Updated by Jim Pingle over 4 years ago
Thomas BERNARD wrote:
unfortunately it shows that everything is OK when the external port is mapped to the same internal port (3074 => 192.168.1.48:3074)
but it doesn't work for (3148 => 192.168.1.49:3074)I don't know how to force pf to translate outgoing UDP packets from 192.168.1.49:3074 to src <public ip>:3148
That's just a matter of using the right nat on
rule.
Taking this specific inbound example:
rdr log quick on re0 inet proto udp from any to any port = 3148 keep state label "DemonwarePortMapping" rtable 0 -> 192.168.1.49 port 3074
This is the equivalent outbound NAT example:
nat on re0 inet proto udp from 192.168.1.49 port 3074 to any -> (re0) port 3148
The (re0)
is a pf macro which expands to the IP address on that interface. You can also explicitly specify the external IP address to use there.
EDIT: I removed some comments after this which were not relevant to the technical part of this discussion. If you want to discuss tangents/related topics, please move that discussion to a forum thread.
Updated by Thomas BERNARD over 4 years ago
thanks, so
nat on re0 inet proto udp from 192.168.1.49 port 3074 to any -> (re0) port 3148
is the additional pf rule that need to be created for outbound traffic when a port mapping (3148 => 192.168.1.49:3074 UDP) is created.
Updated by Jim Pingle over 4 years ago
Thomas BERNARD wrote:
thanks, so
[...]
is the additional pf rule that need to be created for outbound traffic when a port mapping (3148 => 192.168.1.49:3074 UDP) is created.
Yes, that's the equivalent "outbound NAT" rule which would mirror the rdr rule. The only possible issue might be that it would be added to a "nat-anchor" instead of the "rdr-anchor". We have a couple NAT anchors (like "natearly") and I'm not sure if we can repeat a name in those to have "miniupnpd" exist in both nat-anchor and rdr-anchor tabs. I'd have to test that out. pf doesn't complain when I load it, but I didn't run a practical test. If the specific anchor names were config options that would be simple to work around either way.
Updated by Thomas BERNARD over 4 years ago
@jim
you can already have a look at what I've done :
https://github.com/miniupnp/miniupnp/pull/455
Updated by Jim Pingle over 4 years ago
Thomas BERNARD wrote:
@jim
you can already have a look at what I've done :
https://github.com/miniupnp/miniupnp/pull/455
I'm not terribly familiar with pf code in C but if the result is what you show in your comments that's very promising. Though it shouldn't explicitly need the external IP address on the rule if you use the literal string '(re0)
' for interface re0
pf will do the expected thing automatically and internally substitute the address.
Will this be an option behavior or only a compile-time choice? Seems like a good candidate for a command line parameter or config file knob.
Updated by Thomas BERNARD over 4 years ago
I don't know the equivalent of using '(re0)' with the ioctl() API. any pointer will be appreciated.
could you please test https://github.com/miniupnp/miniupnp/pull/455 ?
(my branch pf-nat-rules)
I'm not able to test myself, so I need testers or else I'll never validate theses changes.
Updated by Jim Pingle over 4 years ago
I don't know how that might be expressed in the ioctl/API, unfortunately. I've posed the question to some of our other developers and if I turn up anything, I'll pass it along.
I'll see about getting a version compiled with those changes for testing internally, thanks!
Updated by Jim Pingle over 4 years ago
According to one of our other developers, the (name)
syntax is resolved by pfctl so it isn't in the API. It uses ifa_load()
which in turn calls getifaddrs()
which appears to be similar to what you're doing already so there probably isn't anything different you need to do.
Updated by Jim Pingle over 4 years ago
I don't have two identical consoles with identical online games to test, but just testing with a upnp client I see the extra NAT rules for UDP and they appear to be correct, though I see two rules instead of the one I'd expect, the labels are different:
miniupnpd rules/nat contents: nat log quick on igb2 inet proto udp from 192.0.2.87 port = 62322 to any keep state label "NAT-PMP 62322 udp" rtable 0 -> 192.xxx.xxx.111 port 62322 nat log quick on igb2 inet proto udp from 192.0.2.87 port = 62322 to any keep state label "192.0.2.87:62322" rtable 0 -> 192.xxx.xxx.111 port 62322 rdr log quick on igb2 inet proto tcp from any to any port = 62322 keep state label "192.0.2.87:62322" rtable 0 -> 192.0.2.87 port 62322 rdr log quick on igb2 inet proto udp from any to any port = 62322 keep state label "192.0.2.87:62322" rtable 0 -> 192.0.2.87 port 62322 pass in log quick on igb2 inet proto tcp from any to 192.0.2.87 port = 62322 flags S/SA keep state label "192.0.2.87:62322" rtable 0 pass in log quick on igb2 inet proto udp from any to 192.0.2.87 port = 62322 flags S/SA keep state label "192.0.2.87:62322" rtable 0
The client opened both a TCP and UDP forward for the same port, and as expected only the UDP one was reflected in the outbound NAT rule. Not sure where the second one came from but since it's labeled NAT-PMP it's different from all the others.
I am attaching a version of the miniupnpd pkg for pfSense 2.5.0 snapshots (must be on the latest available snapshots to use it). This code is not in snapshots, it must be installed manually. Updating to a new snapshot may replace this with the stock version, so be careful when updating.
If anyone else wants to test:
1. Download that file and copy it to the firewall (scp, fetch, etc)
2. Install it with this command, run from the directory with the file: pkg add -f miniupnpd-2.1.20190210,1.txz
3. From the GUI, save on the miniupnpd settings to restart it properly
4. Test.
To back it out if it doesn't work:
1. pkg delete -fy miniupnpd
2. pkg install -y miniupnpd
Updated by Marc J over 4 years ago
I disabled IPv6 from the WAN interface as I don't use it anyways.
Now I get this in the logs:
Seems possibly related to: https://redmine.pfsense.org/issues/10398 ?
I added the ext_ip to the "Override WAN address" without any luck here either.
@Jun 2 06:33:11 miniupnpd 26938 no HTTP IPv6 address, disabling IPv6
@
Jun 2 06:33:11 miniupnpd 26938 Listening for NAT-PMP/PCP traffic on port 5351
Jun 2 06:33:11 miniupnpd 26938 PCPSendUnsolicitedAnnounce() IPv6 sendto(): Bad file descriptor
Jun 2 06:40:05 miniupnpd 26938 ioctl(s, SIOCGIFADDR, ...): Can't assign requested address
Jun 2 06:40:05 miniupnpd 26938 ioctl(s, SIOCGIFADDR, ...): Can't assign requested address
Jun 2 06:40:05 miniupnpd 26938 Failed to get IP for interface pppoe0
Jun 2 06:40:05 miniupnpd 26938 SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Jun 2 06:40:05 miniupnpd 26938 PCPSendUnsolicitedAnnounce() sendto(): No route to host
Jun 2 06:40:05 miniupnpd 26938 PCPSendUnsolicitedAnnounce() IPv6 sendto(): Bad file descriptor
Jun 2 06:40:11 miniupnpd 26938 SendNATPMPPublicAddressChangeNotification: sendto(s_udp=10, port=5351): No route to host
Jun 2 06:40:11 miniupnpd 26938 PCPSendUnsolicitedAnnounce() sendto(): No route to host
Jun 2 06:40:11 miniupnpd 26938 PCPSendUnsolicitedAnnounce() IPv6 sendto(): Bad file descriptor
Thanks!
Updated by Jim Pingle over 4 years ago
I started a forum thread for people to share experiences testing this: https://forum.netgate.com/topic/154153/test-request-upnp-fix-for-multiple-consoles-playing-the-same-game-static-port-outbound-nat
Let's keep the discussion there and only put information on this issue which is strictly relevant to the new changes.
Updated by Thomas BERNARD over 4 years ago
please test with miniupnpd-2.2.0-RC1.tar.gz
released on https://miniupnp.tuxfamily.org/files/
Updated by Marc 05 over 4 years ago
Thomas BERNARD wrote:
please test with miniupnpd-2.2.0-RC1.tar.gz
released on https://miniupnp.tuxfamily.org/files/
I take it I have to wait for Jim to make a patched version for us to use in pfSense 2.5.
Updated by Jim Pingle over 4 years ago
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 for additional (and easier) testing.
Updated by Jim Pingle over 4 years ago
- Status changed from New to Feedback
- Assignee set to Jim Pingle
- Target version set to 2.5.0
Updated by Jim Pingle over 4 years ago
The latest 2.5.0 snapshot now contains miniupnpd-2.2.0.r1,1 for testing
Updated by Mike Smith about 4 years ago
I believe pf is only capable of symmetric NAT. I know pfSense pf is different from FreeBSD pf but I'm curious about this FreeBSD pf patch from 2017 that was intended to implement full cone NAT into pf. The patch was never implemented so I'm wondering without the patch it's potentially not allowing miniupnpd to completely do it's job and instead is having to deal with symmetric NAT only.
https://reviews.freebsd.org/D11137
Interesting read on the different kinds of NAT's dealing with gaming:
Updated by Kris Phillips over 3 years ago
Based on Feedback from testers on the forums, they are stating this is not fixed currently.
Updated by Polar Nerd over 3 years ago
I can confirm that this is still a problem in 2.5.0.a.20210129.1122.
I upgraded a school system today from 2.3.x to 2.4.5-p1. Multiple game consoles were able to play prior to the upgrade.
After the upgrade, uPnP only provided one game console with a reservation, and the rest were strict NAT.
Based on this page, I upgraded to the latest snapshot 2.5.0.a.20210129.1122 and it still doesn't work.
I reinstalled 2.3.5.p2 and restored the configuration and multiple game consoles worked again.
I hope this is helpful.
Updated by Renato Botelho over 3 years ago
I just updated net/miniupnpd to 2.2.1 so it would be nice to get it tested again after that
Updated by Renato Botelho over 3 years ago
- Status changed from New to Feedback
Keith contacted me and said it will be tested during the weekend. Leave it in feedback state until hear about results
Updated by YP Lo over 3 years ago
I think other than adding the static NAT port entry (which is only for the single port requested by the console for external access with static NAT), it may also be useful to have an option that also automatically adds full static-port mapping entry added to pf via miniupnpd which ensures that any other dynamic ports used by the console will be also be statically mapped instead of being randomised by NAT. This is especially the case with Nintendo switch, which without static-port map will result in NAT Type D and can be resolved by doing static port map which changes it into NAT Type B [https://www.reddit.com/r/splatoon/comments/6rtgmg/nat_types_and_connection_problems_explained/] and also topic [https://forum.netgate.com/topic/112631/nintendo-switch-needs-static-port-on-its-outbound-nat/35].
The corresponding pf rule should be something like...
nat on (wan-if) inet from (lan-ip) to any -> (wan-ip) static-port
The second "problem" I noticed is that uPnP mapped ports have its source address rewritten by NAT, while manual port-forwarded ports is a pure redirect. Is it possible to have miniuPnP add the port-forwarding entry without NAT? It is possible that some consoles require the WAN source address and doesn't work well with the NATed internal gateway IP address (which I presume is automatically added by 'Automatic outbound NAT rule generation' NAT mode configuration)?
Updated by Marc 05 over 3 years ago
YP Lo wrote:
Is it possible to have miniuPnP add the port-forwarding entry without NAT?
Can you explain in more detail what source -> destination you're seeing now, and what you believe would work better?
Updated by Jim Pingle over 3 years ago
YP Lo wrote:
I think other than adding the static NAT port entry (which is only for the single port requested by the console for external access with static NAT), it may also be useful to have an option that also automatically adds full static-port mapping entry added to pf via miniupnpd which ensures that any other dynamic ports used by the console will be also be statically mapped instead of being randomised by NAT. This is especially the case with Nintendo switch, which without static-port map will result in NAT Type D and can be resolved by doing static port map which changes it into NAT Type B [https://www.reddit.com/r/splatoon/comments/6rtgmg/nat_types_and_connection_problems_explained/] and also topic [https://forum.netgate.com/topic/112631/nintendo-switch-needs-static-port-on-its-outbound-nat/35].
That isn't possible. First, because the Switch doesn't request UPnP so there is nothing to trigger the setup, and second, adding static port for more than one internal host is going to break for the second console, so it's best to do that manually.
The second "problem" I noticed is that uPnP mapped ports have its source address rewritten by NAT, while manual port-forwarded ports is a pure redirect. Is it possible to have miniuPnP add the port-forwarding entry without NAT? It is possible that some consoles require the WAN source address and doesn't work well with the NATed internal gateway IP address (which I presume is automatically added by 'Automatic outbound NAT rule generation' NAT mode configuration)?
That isn't correct. UPnP rules only affect connections on WAN, so the net result is exactly the desired output. It wouldn't NAT anything to an "internal" gateway unless your configuration is very broken. UPnP sets up a port forward on WAN and (now) an additional outbound NAT rule for new connections leaving WAN using the same port requested by UPnP.
Sounds like you may have a misconfiguration, post on the forum to discuss and figure it out.
Updated by Polar Nerd over 3 years ago
I can confirm that this is still a problem in 2.5.0.a.20210129.1122.
I upgraded a school system today from 2.3.x to 2.4.5-p1. Multiple game consoles were able to play prior to the upgrade.
After the upgrade, uPnP only provided one game console with a reservation, and the rest were strict NAT.
Based on this page, I upgraded to the latest snapshot 2.5.0.a.20210129.1122 and it still doesn't work.
I reinstalled 2.3.5.p2 and restored the configuration and multiple game consoles worked again.
I hope this is helpful.
Last night we repeated this experiment with the latest snapshot 2.5.0.a.20210204.2250
Again:
1. Made a backup of the current system running 2.3.5.p2 after confirming that multiple game consoles were operating in "open" firewall status
2. Upgraded to 2.5.0.a.20210204.2250 making no other changes to the configuration, and only one game console was able to operate in "open" status
3. Reinstalled 2.3.5.p2 and restored configuration, again multiple game consoles worked in "open" status
4. Just for kicks I inserted a Netgear Nighthawk R8000 and it also allowed the game consoles to all work in "open" status.
The configuration is a simple layer 2 Ethernet network with a pfSense machine (Intel i5 with an SSD and 8 gigs RAM) connected to a Comcast modem with a single WAN IP address.
We aren't making any configuration changes, and I confirmed that the UPnP configuration is the same on 2.5.0.a.20210204.2250. Are there any changes that we need to make?
We can keep trying this every week until it works. If there is anything I can do or provide that will help diagnose and fix this problem, please let me know. Thank you
Updated by Renato Botelho over 3 years ago
- Status changed from Feedback to In Progress
- Target version changed from 2.5.0 to CE-Next
There is clearly more to be done here. Move to 2.5next
Updated by Michael Clews over 3 years ago
Will this work on 2.5.1, as still having the same issue.
would love to test on 2.5.1 as i have 3 pcs all with COD that want to use port 3074 and upnp just wont do it for more than one client.
Updated by Marc 05 over 3 years ago
Likely not as miniupnp hasn't changed afaik.
If you have time, find a copy of 2.4.0 and test it. It may help narrow down where the issue is.
Updated by Polar Nerd over 3 years ago
Marc 05 wrote:
Likely not as miniupnp hasn't changed afaik.
FYI here is a link to where they are discussing this problem in miniupnp.
https://miniupnp.tuxfamily.org/forum/viewtopic.php?t=393&highlight=xbox
Until they figure out how to get it working in miniupnp, it won't work in pfSense.
Right now it seems as though they have decided it's a problem with Xbox and no further work is being done.
I know this isn't true because a cheap Netgear wifi router works fine with a dozen Xbox game consoles behind it.
Updated by Shane Angelo over 3 years ago
Polar Nerd wrote:
Marc 05 wrote:
Likely not as miniupnp hasn't changed afaik.
FYI here is a link to where they are discussing this problem in miniupnp.
https://miniupnp.tuxfamily.org/forum/viewtopic.php?t=393&highlight=xbox
Until they figure out how to get it working in miniupnp, it won't work in pfSense.
Right now it seems as though they have decided it's a problem with Xbox and no further work is being done.
I know this isn't true because a cheap Netgear wifi router works fine with a dozen Xbox game consoles behind it.
I gave up 2 years ago and moved to Untangle Firewall. Worked instantly for all the xboxes in our house. All my research pointed to miniupnd on any BSD based OS.
Updated by Polar Nerd over 3 years ago
I gave up 2 years ago and moved to Untangle Firewall. Worked instantly for all the xboxes in our house. All my research pointed to miniupnd on any BSD based OS.
My biggest clients are about to jump because they need this feature to work, and they're too afraid of security holes if they roll back to an older version of pfSense when UPnP was working. That's the disadvantage with open-source software, though-- everything about pfSense is excellent except what they are forced to inherit from BSD.
Updated by Charles Jackson over 3 years ago
I've managed to get two XBoX's and a gaming PC on my network and one Xbox and the PC to connect to and play the same game at the same time (War Thunder). I found UPnP didn't work, but I followed [[https://forums.lawrencesystems.com/t/pfsense-and-multiple-xbox-ones-open-nat-guide/2409]] to manually connect and show open NAT. Both XBox's have access to live at the same time as well.
Updated by Polar Nerd over 3 years ago
Charles Jackson wrote:
I've managed to get two XBoX's and a gaming PC on my network and one Xbox and the PC to connect to and play the same game at the same time (War Thunder). I found UPnP didn't work, but I followed [[https://forums.lawrencesystems.com/t/pfsense-and-multiple-xbox-ones-open-nat-guide/2409]] to manually connect and show open NAT. Both XBox's have access to live at the same time as well.
Thank you for the workaround. I'm going to play with this some more.
I have two clients (schools) who have game development labs with many game consoles behind the firewall, and if they are behind a cheap Netgear router, it simply works, with no special configuration. So I have isolated both labs behind Netgears until I can come up with a working Pfsense solution so the clients can have more visibility and control over the lab's Internet use. I've been hopeful that Pfsense can be the solution, but Pfsense depends on the developers of miniupnp to fix this problem so I'm not sure if will be fixed any time soon.
Updated by T S over 3 years ago
Charles Jackson wrote:
I've managed to get two XBoX's and a gaming PC on my network and one Xbox and the PC to connect to and play the same game at the same time (War Thunder). I found UPnP didn't work, but I followed [[https://forums.lawrencesystems.com/t/pfsense-and-multiple-xbox-ones-open-nat-guide/2409]] to manually connect and show open NAT. Both XBox's have access to live at the same time as well.
As soon as i read "Make sure “Static Port” is ticked" then i stop reading because this is no feasible workaround. This will definitly limit you to 1 Device at a time on many Multiplayer Games like CS, BF, PUBG etc at the same Server. This may work for Game Console to see open NAT/moderate NAT but not much more.
Updated by Jon8RFC . about 3 years ago
Here's something mentioning IGDv2 being the problem in miniupnp, and solving it by reverting to IGDv1:
https://www.reddit.com/r/xboxone/comments/6j3cwv/may_have_solved_the_xbox_one_issues_with_some/
And an Xbox engineer mentions what I infer as IGDv2 not being implemented properly to be backward compatible:
https://www.reddit.com/r/xboxone/comments/6j3cwv/may_have_solved_the_xbox_one_issues_with_some/djbhzk2
OpenWRT has this option for whatever their implementation is, which resolved it for a ps4 player:
https://forum.openwrt.org/t/solved-miniupnpd-not-opening-ports-for-ps4/24591/3
In Call of Duty, I have this problem with a PS5 being, at best, "moderate" with pfsense or with DD-WRT. On pfsense, if the PS5 connects first as moderate, the Windows 10 computer will be reduced to moderate. If the Windows device connects first, Windows (I have some static ports forwarded) will be open and PS5 will be moderate.
So, maybe one of you savvy people can revert pfsense's miniupnp package to exclusively use IGDv1 or maybe it's just a matter of advertising as IGDv1 like with OpenWRT, or fix whatever miniupnp people aren't able to fix with regard to IGDv2 backward compatibility?
Updated by Marcos M about 3 years ago
IGDv2 is not currently used:
[21.05-RELEASE][root@local]/root: pkg info miniupnpd miniupnpd-2.2.1_1,1 Name : miniupnpd Version : 2.2.1_1,1 Installed on : Sun Jul 25 13:59:52 2021 CDT Origin : net/miniupnpd Architecture : FreeBSD:12:amd64 Prefix : /usr/local Categories : net Licenses : BSD3CLAUSE Maintainer : squat@squat.no WWW : http://miniupnp.free.fr/ Comment : UPnP IGD implementation which uses pf/ipf Options : CHECK_PORTINUSE: on IPV6 : on LEASEFILE : off PF_FILTER_RULES: on UPNP_IGDV2 : off UPNP_STRICT : off Annotations : FreeBSD_version: 1202505 cpe : cpe:2.3:a:miniupnp_project:miniupnpd:2.2.1:::::freebsd12:x64:1 repo_type : binary repository : pfSense Flat size : 160KiB Description : Mini UPnPd is a lightweight implementation of a UPnP IGD daemon. This is supposed to be run on your gateway machine to allow client systems to redirect ports and punch holes in the firewall. WWW: http://miniupnp.free.fr/
Updated by Greg Wallace about 3 years ago
Have you guys tried manually adding
force_igd_desc_v1=yes
to the config located at
/var/etc/miniupnpd.conf
Just looking briefly it looks like this may be what the OpenWRT check box does.
(I can't test this because my xbox ones already seem to match up fine as long as UPnp and Nat reflection are configured properly.)
Updated by Marcos M about 3 years ago
That would not make a difference in this case unfortunately - the IGDv2 issue was fixed long ago and has its own redmine entry.
Updated by Jim Pingle over 2 years ago
- Target version changed from CE-Next to 2.7.0
- Plus Target Version set to 22.05
Found a potential issue with the order of outbound NAT rule processing that seems to indicate that the new outbound NAT rules from miniupnpd are being processed after the other outbound NAT rules (manual or auto), so making NAT anchors for miniupnpd should correct the processing order. Commit coming shortly and then it will be in development snapshots for testing.
Updated by Jim Pingle over 2 years ago
- Status changed from In Progress to Pull Request Review
MR: https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/602
Diff for those wanting to test using the System Patches package :
diff --git a/src/etc/inc/filter.inc b/src/etc/inc/filter.inc
index d36d6df2e2f982fbb3c456b5cde380de02eea6c0..5a7c21bc2ae94dad9da9a00d4231ff1645ac200b 100644
--- a/src/etc/inc/filter.inc
+++ b/src/etc/inc/filter.inc
@@ -2091,6 +2091,8 @@ function filter_nat_rules_generate() {
$natrules = "no nat proto carp\n";
$natrules .= "no rdr proto carp\n";
+ $natrules .= "binat-anchor \"miniupnpd\"\n";
+ $natrules .= "nat-anchor \"miniupnpd\"\n";
$natrules .= "nat-anchor \"natearly/*\"\n";
$natrules .= "nat-anchor \"natrules/*\"\n\n";
Updated by riva geeza over 2 years ago
Would like to test this but I'm not a developer, I've copied the diff text into the Patch Contents, left everything else blank/default, but when I hit the test button it comes back as :-
Patch can be applied cleanly (detail)
/usr/bin/patch --directory=/ -t -p2 -i /var/patches/62066e0c1d7d9.patch --check --forward --ignore-whitespace
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/etc/inc/filter.inc b/src/etc/inc/filter.inc
|index d36d6df2e2f982fbb3c456b5cde380de02eea6c0..5a7c21bc2ae94dad9da9a00d4231ff1645ac200b 100644
|--- a/src/etc/inc/filter.inc
|+++ b/src/etc/inc/filter.inc
--------------------------
Patching file etc/inc/filter.inc using Plan A...
Hunk #1 succeeded at 2020 (offset -71 lines).
done
and
Patch can NOT be reverted cleanly (detail)
/usr/bin/patch --directory=/ -f -p2 -i /var/patches/62066e0c1d7d9.patch --check --reverse --ignore-whitespace
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/src/etc/inc/filter.inc b/src/etc/inc/filter.inc
|index d36d6df2e2f982fbb3c456b5cde380de02eea6c0..5a7c21bc2ae94dad9da9a00d4231ff1645ac200b 100644
|--- a/src/etc/inc/filter.inc
|+++ b/src/etc/inc/filter.inc
--------------------------
Patching file etc/inc/filter.inc using Plan A...
Hunk #1 failed at 2091.
1 out of 1 hunks failed while patching etc/inc/filter.inc
done
Is it ok to proceed? I don't want to mess my pfsense up but I'm so keen to try this, my son and I cannot play warzone on ps5 and pc at the same time unless I plugin the ISP router.
Updated by Jim Pingle over 2 years ago
That is normal. It's telling you that it can apply the patch but it can't revert it. This means that the patch has not yet been applied. Once you apply the patch it would then tell you it could revert it. You only need to apply it once.
Updated by riva geeza over 2 years ago
Perfect thank you and sorry for the noob question, I'm just really keen to see this resolved. Will report back later today.
Updated by riva geeza over 2 years ago
Pleased to say this has resolved the issue for me also! I can finally play warzone with my son, so happy thank you so much.
As I say I'm not a developer and don't even dabble with Beta's or RC's, only final versions, therefore when 2.6 drops should I keep this in place, or remove during the update then re-apply once 2.6 is installed? I see this is being targeted for 2.7 which is a shame but I understand further testing is required.
If you need me to test anything or provide logs etc, just let me know.
Updated by Jim Pingle over 2 years ago
It is too late to include the fix in Plus 22.01 or CE 2.6.0, so you will need to re-apply the fix after upgrading.
Updated by T S over 2 years ago
Just to make sure, you need "static port" outbound nat rules, for this to work? I applied the patch but i get "strict NAT" mode, when using the standard nat outbound rules, which have no "static port" mapping.
Updated by Jon8RFC . over 2 years ago
T S wrote in #note-82:
Just to make sure, you need "static port" outbound nat rules, for this to work? I applied the patch but i get "strict NAT" mode, when using the standard nat outbound rules, which have no "static port" mapping.
I do have Firewall>NAT>Outbound set to "Hybrid".
But, I disabled everything I had in port forwarding, NAT, and WAN rules for the problematic game in question, for both devices, and the patch worked to show "open NAT".
I'm paraphrasing what Jim explained in the other thread:
Either apply the patch and then reboot PFSense, or apply it and then go to Status>filter reload>reload filter and then Diagnostics>states>reset states>checkmark>reset
Updated by Jim Pingle over 2 years ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 3b50f7656967fbb4daa869a7ae6d18bc5ab6eec3.
Updated by Polar Nerd over 2 years ago
This patch worked on our configuration here as well.
UPnP seems to be fully functioning now. Thank you!!
Updated by Michael Clews over 2 years ago
No fix here.
playing COLD WAR or VANGURD. Both PC players. Applied the patch and restarted pfsense box. Shows open for one and the other pc gets connecting to finally, unable to connect. I collected tcpdump collected will review
Tried on my Sons pc as well and same issue.
Trace shows conversation over port 3074 so it "seems" like it worked but doesn't always show under "status > upnp" or under states (see rst pckt so expect state to be clear).
Settings:
running: 2.6.0
System > Advanced > Firewall & NAT >
"NAT Reflection mode for port forwards" : Pure NAT
Enable automatic outbound NAT for Reflection : checked
Enable NAT Reflection for 1:1 NAT : unchecked
Nothing in "port Forwarding" for these pcs just my "calibre and minecraft server"
Firewall > NAT > Outbound
Hybrid : set
Mappings: alias name for my PC's set to static port <-- is this what is killing me?
Snip:
https://drive.google.com/drive/folders/1rPumILNl6trWzYoMOh_d-Id1dJ8_O2pC?usp=sharing
plug my netgear router and no issues.
update:
Error for Cold War: Negative 345 Blazing Gator | Which leads to port forwarding and all that
Interesting I use to see COD try and open other ports, but I no longer see that behaviour. A
update 2: Disabled and rebooted :
Firewall > NAT > Outbound > Mappings: alias name for my PC's set to static port
get strict now
Updated by Jim Pingle over 2 years ago
For those who still have issues, please start a new forum thread in the gaming category of the forum and provide more detail about the situation there. From all of the positive responses here and on the forum it is likely to be working about as well as expected and the only exception I'm aware of is for those behind double NAT which is a much different problem that isn't relevant to this issue.
Updated by Jim Pingle over 2 years ago
Also there is a new forum thread for general feedback on this issue:
https://forum.netgate.com/topic/169837/upnp-fix-for-multiple-clients-consoles-playing-the-same-game
Updated by Jim Pingle over 2 years ago
- Status changed from Feedback to Resolved
Lots of positive feedback on the forum here showing it's working as well as can be expected now.
There are still some cases that have issues but they are not related to pf/upnp but the device itself. For example PlayStation devices do not request a higher port if the first request fails, so they have to come up first. PC and Xbox appear to DTRT and try other ports until they hit an open one.
Updated by Jim Pingle over 1 year ago
- Subject changed from uPnP fails to properly give out subsequent reservations when multiple gaming systems are playing the same game/using the same port. to uPnP fails to properly give out subsequent reservations when multiple gaming systems are playing the same game/using the same port