0

First of all, I know this question has been asked before

It seems, however, that none of these yet have a full solution. My question is essentially the same. I have a device connected to a wifi network, am also setting up a server on port 8080, but due to the way NAT routers work, there is no way to send requests to the individual device as it shares a public IP with numerous other computers.

The accepted answer mentioned a multitude of workarounds, but it seems that such necessary functionality needs to exist in some legitimate form. (Note video games for example. Even clients still need to be sent packets, and I have yet to see my games do any port forwarding on my router on their own.)

In fact, pretty much any application that interacts with the internet needs to receive data and requests from the internet without forwarding ports. How is this done?

2 Answers2

2

Connection tracking.

If the device connects from inside the NAT to outside, then related packets from the outside system are permitted in. This can be done with both TCP and UDP in some cases.

EEAA
  • 108,414
  • 18
  • 172
  • 242
  • So this means that NAT routers "port forward" automatically? all I need to do is [hole punching](http://resources.infosecinstitute.com/udp-hole-punching/)? It seemed really sketchy but the more i read about it the more commonplace it seems. – Aleksandr Savchenkov Apr 12 '15 at 19:38
  • The nat router remebers the source port and destination port along with the ip. So when a packet comes back it knows where to send it. The problem with a server is that client need to connect to it first, the nat router needs to know prior to the first packet where to send it hence the need for port forwarding. – Gopoi Apr 12 '15 at 19:51
  • Sorry for the late response, but would it be possible to have a separate program send packets out on the port the server plans to use? This way, when requests start coming in (Its an image server)they are routed to the correct port and machine? – Aleksandr Savchenkov Apr 12 '15 at 20:47
  • When TCP-connection has been established from inside to outside, NAT has the requester's IP in his tables so can determine destination for response. If connection established from outside to the inner host, NAT knows nothing about destination. Therefore you have to use some workaround. The simplest if the NAT port-forwarding, but sometimes that can be performed by other software like nginx. Sometimes you can use UPnP for automatical setup of incoming connection forwarding. – Kondybas Apr 13 '15 at 02:58
1

Although traffic can flow in both directions when NAT is in place, the important distinction is that without port forwarding, a server cannot "listen" for new connections on a specific port from hosts outside that network.

Take the example of when one browses a web page. The important point here is that your browser is the client; it's reaching out to connect to another web server that's listening on port 80. Once the connection is set up, yes, traffic can flow in both directions. However, without some form of port forwarding, it wouldn't be possible to do the reverse and have a web server running within your network that can "listen" for connections in the same way.

The reason traffic can flow in both directions once the connection is set up is because of the connection tracking that EEAA mentions. Routers maintain NAT/PAT translation tables which enables them to keep track of "who's speaking to who".

So, to summarise, it's the ability for an application to "listen" and "accept" connections that's not possible without port forwarding. If you can't port forward (even using 'DMZ host' type of feature), then you're stuck with the work arounds I'm afraid.

dbr
  • 1,812
  • 3
  • 22
  • 37
  • So asking the same question I asked EEAA, With something like Hole Punching, is it possible for one program to punch the hole, on the same port the server plans on using, and have the requests come in on that port to that machine? – Aleksandr Savchenkov Apr 13 '15 at 00:20
  • From what I know of hole-punching, it's not meant as a replacement for forwarding ports when a server needs to accept connections. It's a "hack" that's designed to attempt to allow two hosts who are both behind NAT to initiate a direction connection to eachother. It can be flakey and dependent on the specifics of how particular firewalls/routers implement NAT. For this reason, it's nearly always used in conjunction with other methods. – dbr Apr 13 '15 at 18:13