Console Gaming - NAT Issues - Workaround and Solut...

Question

I've already used the BT Broadband Contact Us, to raise this issue. They said it was beyond them and that they'd forward me an address for a technical forum. They've not managed to do so yet, so I'm trying here.
Problem:
NAT hole punching regularly fails between peers/players, manifests as "Cannot chat to player due to NAT Issues" on many different broadband routers.
TL/DR:
The BT Home Hub iptables INPUT chain should have a default action of DROP and not REJECT.
Long Version:
I'm a network engineer and programmer analyst and have been for approaching two decades. I'm also a gamer. I'm regularly frustrated by NAT Issue errors while trying to play online games with my friends.
Frustrated for so long, we decided to start analysing the problem. Using packet captures and simulations, we have reproduced the problem and identified dubious logic in the netfilter conntrack module in the Linux kernel.
When it works:
When using a Playstation 4 to play Destiny, using either in-game or PS Party chat, each console uses a NAT discovery service to find it's external IP address and make an educated guess as to whether there is port translation.
At the end of this process, each Player Console receives IP/Port pairs for the other players, they then emit UDP from their desired port to the IP/Port pair of each of the other Players. These UDP packets pass through their NATing routers and establish conntrack entries for the source ip/port, destination ip/port and protocol (here on referred to as five-tuple) with NAT associations with the console's LAN ip address and port; this is the hole-punching.
All being well, each players console has created an association for each of the other players packets to come back through and then they are able to send each other data on these ports.
When it doesn't work:
However, here's the race condition: if player B's packet reaches player A's router before player A has sent theirs, there is no NAT association, no conntrack entry for the 5-tuple. The incoming packet instead considered as intended for the router.
The iptables configuration on the router says that the packet is not allowed and REJECTs it, sending an ICMP destination unreachable packet in response. This reply is then inspected by conntrack, which decapsulates is and erroneously creates a conntrack entry for the 5-tuple.
Now when Player A's console does manage to send it's own hole punching UDP packet, the 5-tuple for the desire hole is associated with the router's ICMP destination-unreachable. So Player A's packet can't have the desired port number and is renumbered to the first available port (e.g. 1025). Player B's subsequent packets to A follow the conntrack entry started by the ICMP destination-unreachable and are sent to the router which continues to reject them.
How to fix this mess
Linux conntrack
Arguably the decapsulation of the ICMP payload and the usage of it to create a conntrack entry is erroneous. The ICMP unreach should not stop the port from being used by a NAT client.
This will take a long time to fix and when fixed may never be back-ported to home routers which may never see new firmware again anyway.
Modify the routers configuration
If the router dropped instead of rejecting the traffic (relatively simple administrative task given appropriate access), the ICMP destination-unreachable wouldn't be generated, conntrack wouldn't create the erroneous entry and then even if Player B's packets arrived before Player A had sent theirs, it would still work.
Disable the "firewall" and put your console in the "DMZ"
These are terms borrowed from the Home Hub 3 admin interface. If you set your console as the "DMZ", it will receive any internet traffic that isn't associated with an already established flow. Actually at this point I'm not certain whether or not you *have* to set the "firewall" to disabled. It depends on how the "firewall" is implemented.
On my console disabling the firewall and setting the console to be the DMZ works around the problem. However, you can only have one default NAT target. So any other device suffering from this problem would be out of luck without you reconfiguring your router each time. Also I'm not thrilled by my console receiving unfiltered internet traffic.
In closing
Race-conditions depend on timings. This one is exacerbated by low latency between players. In this case the difference between server<->PlayerA and server<->PlayerB latencies has to be lower than the PlayerA<->PlayerB latency. If PlayerA and PlayerB have low latency between each other they are more likely to suffer from this problem.
Please, please, please bring this to the attention of someone who is responsible for the configuration of your routers. A simple configuration change on the HomeHub would prevent this problem from happening and remove the need for customers to add special configuration to their router and lowering their security.
Thanks for reading.
Matt

Answer 1

Welcome to this forum.
This is a customer to customer forum only,
This is where customers help each other get the most out of BT products & services.
Anything you post here does not go to BT. Although the forum is moderated by BT, not all posts are read.
This is a public forum which can be viewed worldwide, so please do not post any personal information, especially phone numbers, account numbers, fault numbers, address information or email addresses, as this could be used to impersonate you.
I would suggest that maybe you try using a different router?
There are some useful help pages here, for BT Broadband customers only, on my personal website.
BT Broadband customers - help with broadband, WiFi, networking, e-mail and phones.