1

There’s a software that provides peer-to-peer connections using random private dynamic ports in such way that the software will get users Public IP addresses and port information and store its specific unique source IP and port for each user’s Public IP address.

For example: in order for a source IP to connect to destination IP, it will retrieve that information from the software servers that has already stored ip/port of destination information of let’s say IP: 111.222.333.444 port:56344 and then initiates that connection with destination IP successfully which should work most of the time in this case.

To make things more complicated, let’s say the user router’s NAT Type is set to Symmetric NAT which in this case the user network information will be stored in software as a predefined source ip/port but due to the nature of how Symmetric NAT works, it is NOT going to be the same initiated source IP/Port when creating a connection session with destination IP because it is going to use different source IP&port altogether and that contradicts with software servers conserved predefined source ip/port that was saved beforehand, thus joining session will simply fail.

In theory, a user that has Full Cone NAT router should be able to communicate to a user that has Symmetric NAT router because it will allow any incoming connection for any source/destination port.

With all that said and explained, it is worth mentioning that the software recommends opening port 3074 for it to work properly. The question is: if this specific port doesn’t work for Symmetric NAT users (that did not port forward), then why it is advised by the software in the first place?

Turki Aldhuhayyan
  • 11
  • 2
  • Possible duplicate of [How NAT traversal works in case of peer to peer protocols like bittorrent.](https://stackoverflow.com/questions/37367769/how-nat-traversal-works-in-case-of-peer-to-peer-protocols-like-bittorrent) – the8472 Aug 23 '19 at 07:52

2 Answers2

0

UPnP IGD v1/v2, NAT-PMP and PCP are protocols that allow private network hosts to request a port to be forwarded to them by the gateway device. For that to work the gateway device obviously must support at least one of those protocols. It is commonly available (to facilitate networked games among other reasons) but not always enabled in many consumer devices. It is less likely to be found in enterprise environments due to security policies

Additionally gateways may also forward those port forwarding requests to the ISP's CGNAT, e.g. when it is behind a DSlite AFTR.

For full cone nat (also known as endpoint independent mappings) you can simply use UDP hole punching. This is not applicable for symmetric NATs (aka. address and port dependent mappings).

You can also try using IPv6 since that does not suffer from NAT, but gateways may still implement firewalls that block incoming connections by default, resulting in similar connectivity issues.

Community
  • 1
  • 1
the8472
  • 40,999
  • 5
  • 70
  • 122
0

If the client behind the full cone NAT uses the same port for both out- and incoming connections,
and also recently has made a outgoing connection attempt or has a already established connection to an arbitrary client,
there will be a opening that the client behind the symmetric NAT can connect through.

Doing a successful port forwarding will make the issue with NAT go away for that particular client and any other (NATed) client can connect to it.

Encombe
  • 2,003
  • 1
  • 17
  • 26