Normal port forwards won't work as we have two PS4 consoles online over here.
And how do you expect for upnp to work if it receives a request to open the same port for 2 devices?
Upnp handles it just fine and that's the reason why I need to use upnp. It's basically the only way to get Open NAT status at the same time on both PS4 consoles with Modern Warfare, BO4 and Destiny 2.
This question was alluded to by @WiteWulf and @trendy; but I'm not sure you answered:
- Are you attempting to run both PS4 consoles at the same time, with both needing the same port(s) opened?
- Has this ever worked for you?
The concept of a tracking a 4-way connection state (i.e. SRC IP/Port - DST IP/Port) prevents this. Lets use 3074/tcp as an example:
- PS4-a and PS4-b request 3074/tcp be opened via UPnP
- UPnP does this
- Inbound, unsolicited "Open NAT" traffic for PS4-a hits your WAN port destined for <your_IP>:3074 from <xxx.xxx.xxx.xxx>:xxxx
- Inbound, unsolicited "Open NAT" traffic for PS4-b hits your WAN port destined for <your_IP>:3074 from <yyy.yyy.yyy.yyy>:yyyy
- If this works, please explain how the router correctly selects which PS4 device to NAT X and Y traffic to!?!?
1 Like
Actually it has been soooo long since this thread started that I forgot what the problem was. 
It basically makes sense to have the port forwards disappearing if 2 consoles try to request the same port forward. Either the upnp is dropping connections of the first console or the second console will not be able to open any ports.
3 Likes
Sorry for the late response...
Yes with upnp enabled it works. The external/destination port will (ofc) not be the same but both consoles will get the "Open NAT status" at the same time.
Two consoles online at the same playing, active playing (1xBO4, 1xModern Warfare):
root@WRT:~# iptables -t nat -L MINIUPNPD -n -v
Chain MINIUPNPD (1 references)
pkts bytes target prot opt in out source destination
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3074 to:192.168.1.241:3074
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:9308 to:192.168.1.242:9308
1 43 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3078 to:192.168.1.242:3074
So both console have the Open NAT status but after ten minutes these fowards are getting deleted via miniupnpd.
Don't ask me why but with upnp enabled we are always able to hit Open NAT status on both consoles, even if we play the same online game. Of course the "External port number" will not be the same number on both consoles but with "Deamonware Port mapping" (e.g. any COD and Destiny 2) upnp is the only way to get the Open NAT status when both consoles are online and playing at the same time.
I don't understad the tecnical part behind upnp. The only thing that I was worried about is the fact that these port forwards from the PS4's are getting closed after 10 minutes. I configured a "Clean rules threshold of 1" with the "default Clean rules interval of 600 seconds" because otherwise I'll get like 10+ port forwards if I restart the game or restart the consoles. For some reason miniupnpd sees those PS4 port forwards as unused/inactive rules and that's why it's cleaning them up.
It also happens if only one console is active and there is more than one Port forward active (e.g. 3074 + 9308). As I said for some reason miniupnpd think that that these rules/forwards are unused/inactive and I don't understand this as I actively play a game which has traffic on the game port.
When I tested qBittorent with upnp on my Windows machine the two port forwards were not getting closed after 10 minutes and the miniupnpd firewall chain had active traffic (pkts + bytes).
Maybe upnp with the PS4 is designed different and everything works fine and expected but I find this a little bit odd.
So at this point I still don't know if miniupnpd is working as it should with the PS4 consoles and that's why I'm seeking help here.
1 Like
As you can see from the first 2 columns, the forwarded ports were barely used. (1 packet hit to:192.168.1.242:3074). Could be just to test the port forward and report to you that NAT is open.
Other than that the second PS4 is using a not standard port, since the 3074 is already used by the first PS4.
So I believe the upnpd is shutting down the ports due to inactivity.
I am not sure if you are really facing issues when you play a game or you are just preoccupied by the fact that port forwards are removed from upnpd. If your game is not having issues, I'd suggest to forget about it.
1 Like
What I still don't understand is why it does shut down the ports when there is active traffic running on the game port (e.g. 3074). Shouldn't the port forward stay active for the game when there is constant traffic at the forwarded port like with the bittorrent test I did on my Windows machine?
We were having some issues with joining lobbys and hearing people in the party chat after miniupnpd had removed the forwards but the weird thing is that this doesn't happen all the time.
For example after a couple MW matches today the NAT status changed to strict for me and my room mate console and we couldn't join our friends lobby after it happend. We both restarted the game and consoles but the only thing that miniupnpd did was adding more and more forwards but the NAT status didn't changed.
I've tried to restart the miniupnpd service but this didn't fix the problem. The only thing that helped was to remove the port forwards by hand and kill miniupnpd service + restart.
It would be great if someone could test miniupnpd with another OpenWrt build + PS4. If miniupnpd reports active traffic on the forwarded ports on another OpenWrt system I would know for sure that something is wrong on my end and miniupnpd isn't working as it normaly should...
I don't think it's UPnP, I think it's the firewall.
root@OpenWrt:~# cat /proc/sys/net/netfilter/nf_conntrack_generic_timeout
600
From: https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt
nf_conntrack_generic_timeout - INTEGER (seconds)
default 600
Default for generic timeout. This refers to layer 4 unknown/unsupported
protocols.
To be clear, I'm not advising that you raise this number; but it would be interesting to see if your made it 660, would you see the behavior every 11 minutes...
To be honest, what you're describing is the first time I've heard anyone talk as if this were possible with UPnP.
You do realize that both you and your roommate are playing: the same game from the same Public IP needing the same ports, correct?
Starts at 4 min mark:
I don't think the cleanup proccess is firewall related.
For testing I've deleated the threshold of 1 from my miniupnpd config and now the Port forwards are not getting deleted anymore after 10 Minutes, they basicialy stay forever.
If I set the threshold back to 1 and raise the Clean rules interval to 660seconds the forwards are getting deleted after 11 Minutes (if there is more than one active port forward).
Without Clean rules threshold set to 1 atfer one day:
root@WRT:~# iptables -t nat -L MINIUPNPD -n -v
Chain MINIUPNPD (1 references)
pkts bytes target prot opt in out source destination
5 215 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3074 to:192.168.1.242:3074
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:9308 to:192.168.1.242:9308
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:9304 to:192.168.1.242:9304
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:60950 to:192.168.1.241:60950
4 200 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3166 to:192.168.1.241:3074
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3135 to:192.168.1.241:3074
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3180 to:192.168.1.241:3074
133 16226 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:9306 to:192.168.1.241:9306
Yes I do understand this but upnp is the only solution to get the Open NAT status on both console at the same time, playing the same game. I don't want to use DMZ for our consoles as it's clearly not needed to get the Open NAT status on both consoles. Without upnp the NAT status will be Moderate on both consoles, period.
Please correct me if I'm wrong here but what UPNP does is to forward the same client port (in this case 3074) to different external ports as you can see above, so it's not like that it's trying to map the same client port to the same external port (which would clearly make no sense at all).
What I still trying to figure out is if miniupnpd is working correctly with the PS4. The only thing that I know for sure is that miniupnpd worked fine with my Windows machine and qBittorrent. The two forwarded ports (TCP+UDP) where not getting deleted after 10 Minutes when there was active traffic via qBittorrent and after I shutdown qBittorrent the fowards were getting deleted automaticly.
In the case of the PS4 miniupnpd doesn't seem to pickup the traffic and therefore it's shutting down the port forwards after the default timer of 600 seconds when the Clean rules threshold is set to 1. I do have a feeling that miniupnpd wouldn't clean up the forwards if it would pick that there is active traffic over the forwareded port (like with qBittorrent).
Maybe everything is working as expected but how can I be sure about this?
remove_unused_rules(struct rule_state * list)
{
................
syslog(LOG_DEBUG, "removing unused mapping %hu %s : still "
"%" PRIu64 "packets %" PRIu64 "bytes",
list->eport, proto_itoa(list->proto),
packets, bytes);
_upnp_delete_redir(list->eport, list->proto);
...............
}
So, actually, miniupnpd can output to (sys)log how many packets have passed through a connection.
Maybe something is bugged there? Either with packet accounting or with the timestamps...
How to toggle the debug log? option log_output?
Hmm.. some functions use timestamps, I don't know if miniupnpd handles them by itself or if it uses conntrack's timestamp feature.
There was a sysctl option net.netfilter.nf_conntrack_timestamp but it seems to be removed.
Maybe by default, it is always on now...?
Also:
nf_conntrack_acct - BOOLEAN
0 - disabled (default)
not 0 - enabled
Enable connection tracking flow accounting. 64-bit byte and packet
counters per flow are added.
1 Like
Thanks for your input...
I have no idea how to debug this but I have feeling that miniupnpd is behaving realy weird with the PS4.
Without the Clean rules threshold set to 1 there will be a bunch of unused port forwards for just one game after some time and with the threshold set to 1 miniupnpd will shutdown those forwards because it recongnizes them as "unused".
root@WRT:~# iptables -t nat -L MINIUPNPD -n -v
Chain MINIUPNPD (1 references)
pkts bytes target prot opt in out source destination
4 172 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3143 to:192.168.1.242:3074
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:9304 to:192.168.1.242:9304
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:60292 to:192.168.1.241:60292
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:56909 to:192.168.1.241:56909
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:58703 to:192.168.1.241:58703
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:9308 to:192.168.1.242:9308
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3113 to:192.168.1.242:3074
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:56097 to:192.168.1.241:56097
1 43 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3074 to:192.168.1.241:3074
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3104 to:192.168.1.242:3074
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3171 to:192.168.1.242:3074
0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3091 to:192.168.1.242:3074
Maybe Sony implemented upnp wrong with the PS4 as my test with qBittorrent on my Windows machine showed that miniupnpd did work completely fine (as it should?).
Anyway it would be helpful if a PS4 user could test miniupnpd with their router runing OpenWrt. It would be interesting to know that it's not a fault of my Firmware Build/Internet connection type/config.
Maybe. I don't know why the PS4 creates so much port forwards.
Seems like that the PS4 doesn't keep track of the port forwards and
requests new port forwards over and over.
As someone else suggested, did you try to enable option enable_natpmp ?
What happens when you lower the clean rule interval to a lower value, 120 for example?
(And keep the treshold at 1)
You could also try to modify the miniupnpd init script to change the values of
min_lifetime and max_lifetime.
Defaults are 120 and 86400
I've tried to enable nat-pmp but it doesn't seem to have any effect on the PS4.
If I lower the value to 120 with threshold set to 1 the port forwards are getting deleted after 2 Minutes (if there is more than 1 Port forward active).
Tue Nov 26 10:39:15 2019 daemon.debug miniupnpd[10532]: removing unused mapping 3074 UDP : still 1packets 43bytes
Tue Nov 26 10:39:15 2019 daemon.info miniupnpd[10532]: Trying to delete nat rule at index 1
Tue Nov 26 10:39:15 2019 daemon.info miniupnpd[10532]: Trying to delete filter rule at index 1
Tue Nov 26 10:39:15 2019 daemon.debug miniupnpd[10532]: removing unused mapping 9308 UDP : still 0packets 0bytes
Tue Nov 26 10:39:15 2019 daemon.info miniupnpd[10532]: Trying to delete nat rule at index 0
Tue Nov 26 10:39:15 2019 daemon.info miniupnpd[10532]: Trying to delete filter rule at index 0
Tue Nov 26 10:39:15 2019 daemon.notice miniupnpd[10532]: removed 2 unused rules
So miniupnpd actually does log the packet amount to syslog.
still 1packets 43bytes
So the question is how does it determine if a connection is unused or not.
Maybe when no packets are transmitted in the time window specified by min_lifetime.
So by default 2min.
But i have the feeling, the clean rule function does remove rules regardless of transmitted packets over time.
Actually how can this even work if you have option enable_natpmp '0'? pcp?
Miniupnpd does only pick up one packet when the game connects to the online service (I guess for the NAT test). Ater this there are no more packet flowing unless I restart the game.
At this point I think that it's the fault of the PS4 System or maybe it just designed like this on the PS4.
Tue Nov 26 10:35:16 2019 daemon.info miniupnpd[10532]: HTTP REQUEST from [::ffff:192.168.1.242]:54305 : GET /rootDesc.xml (HTTP/1.1)
Tue Nov 26 10:35:16 2019 daemon.debug miniupnpd[10532]: Host: 192.168.1.1:5000
Tue Nov 26 10:35:16 2019 daemon.info miniupnpd[10532]: HTTP REQUEST from [::ffff:192.168.1.242]:54307 : POST /ctl/IPConn (HTTP/1.1)
Tue Nov 26 10:35:16 2019 daemon.debug miniupnpd[10532]: Host: 192.168.1.1:5000
Tue Nov 26 10:35:16 2019 daemon.info miniupnpd[10532]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress
Tue Nov 26 10:35:17 2019 daemon.info miniupnpd[10532]: HTTP REQUEST from [::ffff:192.168.1.242]:54311 : POST /ctl/IPConn (HTTP/1.1)
Tue Nov 26 10:35:17 2019 daemon.debug miniupnpd[10532]: Host: 192.168.1.1:5000
Tue Nov 26 10:35:17 2019 daemon.info miniupnpd[10532]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping
Tue Nov 26 10:35:17 2019 daemon.info miniupnpd[10532]: AddPortMapping: ext port 3074 to 192.168.1.242:3074 protocol UDP for: DemonwarePortMapping leaseduration=604800 rhost=
Tue Nov 26 10:35:17 2019 daemon.debug miniupnpd[10532]: UPnP permission rule 1 matched : port mapping accepted
Tue Nov 26 10:35:17 2019 daemon.debug miniupnpd[10532]: Check protocol udp for port 3074 on ext_if pppoe-wan x.x.x.x, 378FF302
Tue Nov 26 10:35:17 2019 daemon.info miniupnpd[10532]: redirecting port 3074 to 192.168.1.242:3074 protocol UDP for: DemonwarePortMapping
That could be true but I didn't had this problem with qBittorrent on my Windows Machine and I could see alot of trasmitted packets and bytes in the miniupnpd firewall chain when downloading torrents.
Can you try this with an interval of 120?
If the rules don't get removed then miniupnpd does take 'packets transmitte over time' into account.
Miniupnpd doesn't delete the qBittorrent rules (even If there is no active torrenting) unless I shutdown the Programm. It will even keep those forwards active when the is no Down or Uploading going on.
After ~15 Minutes with Clean rules interval set to 120:
root@WRT:~# iptables -t nat -L MINIUPNPD -n -v
Chain MINIUPNPD (1 references)
pkts bytes target prot opt in out source destination
251 21448 DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6881 to:192.168.1.230:6881
545 65605 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:6881 to:192.168.1.230:6881
Edit
After I close qBittorrent:
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: HTTP REQUEST from [::ffff:192.168.1.230]:50150 : POST /ctl/IPConn (HTTP/1.1)
Tue Nov 26 12:32:54 2019 daemon.debug miniupnpd[16743]: Host: 192.168.1.1:5000
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#DeletePortMapping
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: DeletePortMapping: external port: 6881, protocol: TCP
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: removing redirect rule port 6881 TCP
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: Trying to delete nat rule at index 0
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: Trying to delete filter rule at index 0
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: HTTP REQUEST from [::ffff:192.168.1.230]:50151 : POST /ctl/IPConn (HTTP/1.1)
Tue Nov 26 12:32:54 2019 daemon.debug miniupnpd[16743]: Host: 192.168.1.1:5000
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: SOAPAction: urn:schemas-upnp-org:service:WANIPConnection:1#DeletePortMapping
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: DeletePortMapping: external port: 6881, protocol: UDP
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: removing redirect rule port 6881 UDP
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: Trying to delete nat rule at index 0
Tue Nov 26 12:32:54 2019 daemon.info miniupnpd[16743]: Trying to delete filter rule at index 0
Actually, PS4-B should automatically choose a different port.
(Because a request for a port forward whose port is already in use, will fail)
I had two PS4 here for testing a few month back and that is it actually what the second PS4 did.
@Kherby
All the logs you posted don't show a signifcant amount packets being forwarded.
Do you actually host a game session on the PS4?
If not, you don't need port forwards and restricted NAT will work fine.
Or do you host a game session on one PS4 and the other one is joining this session?
In that case, the forward packet counters will also show no packets because of nat loopback?
The min_lifetime and max_lifetime options are for PCP and that is what you are using(?)
Because of enable_natpmp = 0.
And if I understand this correctly, a client can request a port forward/lease with a lifetime value.
Those variables make sure that forwards/leases are not too short or too long.
For example:
max_lifetime is set to 86400 in miniupnpd conf.
Client requests port forward/lease with a lifetime of 172800
172800 > 86400
So the forward/lease time will be restricted/reduced to 86400.
min_lifetime works the other way around.
But I'm not sure but that would make sense.
Are these packets from qBittorrent in the miniupnpd firewall chain some sort of keep alive packets? The packet cound will even increase if there is no downloads running via bittorrent...
I never saw the packets from the PS4 forwards increase while gaming. Most of them are actually shown with 0 packets.
I don't host game sessions at the moment but without open NAT there will be problems for some people to join my Pre Lobby (party) session. Also had some problems with voice in PSN Party sessions where the PS4 indicated that there is a NAT problem and therefore people couldn't talk and hear me.
I don't know anything about the min_lifetime and max_lifetime options but I think the problem with the PS4 is that miniupnpd doesn't count any packets and therefore it sees the forwards as unused and shuts them down. Maybe I do missunderstand how upnp works with the PS4 but if the Gameserver uses active connection over port 3074 I dont understand why miniupnpd doesn't pick up any packets and keep the forward alive.
If the Open NAT status is only for hosted games it would make sense that there are no packets flowing as I'm not hosting a game where my PS4 acts as the gameserver. But what about the pre Lobby (party) for Call of Duty? Wouldn't this count as hosted if I'm the party leader?