0

Say I have two devices on a router which both have software listening on port 999. A client outside my local network attempts to connect to my public IP address via port 999.

How does the router know which device to route the connection request to? Both devices are listening on port 999, but the traffic can only ultimately end up at one of the devices, can't it?

I know port forwarding would be the proper way to ensure the data is getting to the correct device, but what if no port forwarding configuration is set up? Does the packet get rejected by the router since it doesn't know which device is the "correct" device?

0

It depends on how the router is configured. The most common configuration will result in the packet either being ignored or resulting in the connection being reset. Typically, SoHo routers doing NAT only accept inbound connections if port forwarding is specifically configured or the connection is to the router itself.

One wrinkle would be if the router has a default destination or DMZ configured. In that case, the connection would be forwarded to the default destination.

Another wrinkle would be if the router supported UPnP. In that case, the connection would be forwarded to whatever host first asked to have that port forwarded, if any.

Lastly, some routers have permissive NAT. In that case, the router would make its best guess. For example, if there was only one device active recently, that device might get the connection. Or if one device had previously communicated with the IP address this connection came from, that device might get the connection.

It completely depends on how the router is configured and what features the router supports.

  • Thanks a bunch. I've heard the terms "solicited" and "unsolicited" data with regard to routing packets before. Where "solicited" packets are packets that were requested in some capacity, and therefore the router knows where to return them to. Would that play a role in this equation as well? – Rudy Feb 27 '17 at 10:48
  • 1
    The question seems to be strictly about unsolicited packets, that is, ones that do not appear to be a direct reply to a previously-NATted outbound packet. Solicited reply packets are NATted back to the sender of the packet that solicited them, unless forbidden by firewall settings. – David Schwartz Feb 27 '17 at 11:11
  • Gotcha. I was thinking that was the case. Is there an industry term for "solicited" and "unsolicited" packets? I've only seen them called this in a few videos where I was trying to learn more about how packets are handled, but I don't tend to find much actual documentation calling it "solicited" and "unsolicited" data. – Rudy Feb 27 '17 at 11:13
  • 1
    Those terms are not that common, at least in my experience. I've more commonly heard the term "reply" used. But I don't think there's any common term for a packet that is not a reply. – David Schwartz Feb 27 '17 at 11:39
-1

For incoming connections (note I'm using the word connections, not packets), without any port forwarding/UPnP set up it would reject or drop the packet.

For outgoing connections (using SNAT), the router will keep 'state'. It will look at all the outgoing connections (for simplicity, a TCP packet going from inside to outside with a SYN flag), rewrite the source address/port to the WAN connection and send the packet onwards. It knows what it has rewritten the source address/port to, and when a packet comes back, it'll reverse that process to the original address/port.

So for my NAT router, I would get the following table:

TCP state codes: SS - SYN SENT, SR - SYN RECEIVED, ES - ESTABLISHED,
                 FW - FIN WAIT, CW - CLOSE WAIT, LA - LAST ACK,
                 TW - TIME WAIT, CL - CLOSE, LI - LISTEN

CONN ID    Source                 Destination            Protocol         TIMEOUT             
201805472  10.100.0.95:62110      83.69.0.50:42018       udp [17]         7                   
213891648  10.100.0.95:43327      176.68.233.117:53228   tcp [6] ES       4631                
213891928  10.100.0.95:38139      213.101.14.165:54764   tcp [6] ES       6995                
213223160  10.100.0.95:35725      176.68.233.117:53228   tcp [6] ES       386                 
215913952  10.100.0.1:38340       10.100.0.11:53         udp [17]         8                   
205319000  10.100.0.95:62110      95.22.94.199:22634     udp [17]         41                  
214931472  10.100.0.95:60500      213.101.14.165:5524    tcp [6] ES       6478                
205547536  10.100.1.26:37992      141.138.198.177:993    tcp [6] ES       7118                
387202720  10.100.1.26:58156      141.138.198.177:993    tcp [6] ES       7122                
[output omitted]

If there is a packet coming back from 176.68.233.117 with destination port 53228, it will rewrite the destination address/port to 10 10.100.0.95:43327.

  • This propagates the dangerous myth that permissive NAT does not exist. – David Schwartz Feb 27 '17 at 10:40
  • It also does about 150 other assumptions, but we're not here to write full RFC compliant technical manuals... – mtak Feb 27 '17 at 12:37
  • Except the OP specifically asked about something that is impacted by permissive NAT in ways that can be surprising and dangerous. – David Schwartz Feb 27 '17 at 18:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.