Simple NAT question - how are multiple devices using same port behind NAT

[FreshJR]

I've been wondering about this for a while.

With wifi-calling, I see that many devices are listening on the same port. How is this possible with regards to network address translation/??

udp   192.168.1.1:4500                  222.222.111.111:4500                    ASSURED
udp   192.168.1.2:4500                  222.222.111.111:4500                    ASSURED
udp   192.168.1.3:4500                  222.222.111.111:4500                    ASSURED

Q1:
Does each packet arriving from 222.222.111.111:4500 simply get duplicated and pushed to all LAN devices that have an "ASSURED" connection in the NAT table. If this is the case, I am assuming that simultaneously any "non-ASSURED" devices would not be seeing any of this traffic?

Q2:
If I port-forward UDP:4500 -> 192.168.1.4:4500, would devices 1, 2, & 3 not see any of this traffic anymore?

OR

would all 4500 traffic always get forwarded to 192.168.1.4 (non-assured) && in addition to any assured devices (1, 2, & 3)

--

I assume that it gets pushed to all assured devices regardless of the port forward, but I would like to confirm since I never seen NAT (port address translation) have overlapping devices using the same port.

--

I ask because I just dealt with a friend on mine not receiving incoming calls on his VOIP device.
Sure enough I found that he had SIP disabled in his cisco router.
I was thinking of forwarding 500, 4500, 5060, 5061 to his VOIP device for good measure. I refrained from the port-forwarding since even though he had 1 VOIP device, he also has other Wifi-Calling devices which operate on the same ports.

If it was my router I would experiment and see, but since I was leaving I didn't want to cause service blackout issues on those devices.

 

[ColinTaylor]

If you read up on "Connection tracking" I'm sure you'll find many articles that can explain it much better than I ever could.

However, here's something to consider. In your example above let's assume we're just dealing with connections that are established in an outgoing direction from our LAN (192.168.1.x).

The device at 192.168.1.1 opens its port 4500 (192.168.1.1:4500) and connects to the remote server at 222.222.111.111 on its port 4500 (222.222.111.111:4500). What actually happens is the router translates the source address (192.168.1.1) to its WAN address, let's call it 23.45.67.89 (NAT). conntrack keeps a record of this connection. So the connection is between 23.45.67.89:4500 and 222.222.111.111:4500.

Next, the device at 192.168.1.2 also opens its port 4500 (192.168.1.2:4500) and connects to the remote server at 222.222.111.111:4500. Again, the router has to translate the internal address (192.168.1.2) to the WAN address (23.45.67.89). But wait, there's a problem. How can we differentiate between our two devices? Simply put, we can't unless we change something. We can't change our WAN address but can change our port number. This is what netfilter does. It tries to keep the internal and external port numbers the same, but if it can't (as in this case) it translates the internal port number to an unused external port number (PAT). Typically it just adds 1 to the source port number. So the connection is between 23.45.67.89:4501 and 222.222.111.111:4500.

So you have NAT and PAT. Connection tracking keeps track of the translation of addresses and ports. And therefore every outgoing connection (as seen from a device on the internet) is represented by a unique combination of IP address and port number.

 

[FreshJR]

So you have NAT and PAT. Connection tracking keeps track of the translation of addresses and ports. And therefore every outgoing connection (as seen from a device on the internet) is represented by a unique combination of IP address and port number.

I see where my all confusion was coming from.
I thought the connections listed in netstat-nat already had PAT performed.

From looking at the natstat-nat table I thought that multiple devices were somehow all listening on the same port, which didn't make much sense. (The table is correct since technically the LAN devices are listing on the same port, but in the communication between router and server, the router is actually listening on 4 different ports!)

Just to clarify, are port forward rule always applied to the EGRESS portion of incoming traffic?

[    <--   TRAFFIC FLOW  <--        ]

[      EGRESS       ]
[  dport  <-  sport ]               

           [        INGRESS         ]
           [   dport  <-   sport    ]

LAN1:4500 <- WAN:4501 <- SERVER:4500
LAN2:4500 <- WAN:4502 <- SERVER:4500
LAN3:4500 <- WAN:4503 <- SERVER:4500
LAN4:4500 <- WAN:4500 <- SERVER:4500

Since from what I can tell, if port forward rules applied to INGRESS traffic then devices 1, 2, & 3, would never see traffic any traffic originating from a server hosted on 4500 if a port forward sport 4500 rule was created.

Most likely port forwards are always EGRESS so I think I can port forward his glitchy VOIP device without breaking all his other VOIP devices that somehow have been working without SIP enabled behind a NAT&PAT!

I'm guessing the glitchy VOIP device doesn't keep a connection open/assured so NAT has been dropping his incoming calls.

This clarified basically everything lot! (Now I'm off to learn what the hell SIP & NAT Helper specifically do, but I can find this on my own).

 

[ColinTaylor]

I see where my all confusion was coming from.
I thought the connections listed in netstat-nat already had PAT performed.

From looking at the natstat-nat table I thought that multiple devices were somehow all listening on the same port, which didn't make much sense. (The table is correct since technically the LAN devices are listing on the same port, but in the communication between router and server, the router is actually listening on 4 different ports!)

To my mind the confusion comes because to output of netstat-nat doesn't show the external NAT address and PAT numbers. To be fair the external NAT address will always be our WAN address, but as we have seen above the port number may have changed.

Just to clarify, are port forward rule always applied to the EGRESS portion of incoming traffic?

No, port forwarding applies to incoming (WAN to LAN traffic). It's crucial to understand that with port forwarding (and the scenario in post #2) that we are talking about the initial establishment of the session, not what happens afterwards. So you always have to bear in mind "who is the initiating client" and "what is their IP address and port number" (because that uniquely identifies the session).

Port forwarding can (and often does) get very complicated, but lets take a simple example. We have a web server on our LAN at 192.168.1.50 listening on port 80. We want this accessible from the internet. So we create a port forwarding rule on our router that says "forward all unsolicited traffic that arrives at our WAN interface to 192.168.1.50:80". This will establish the initial connection and is tracked in the conntrack table. We know where to send the replies from our web server because the originating client is uniquely identified by their IP address and their port number. Remember, the client's port number will be a pseudo-random ephemeral port (typically between 49152 to 65535) whilst our server will always be listening on port 80.

As I said, port forwarding can get very complicated when you start doing things like forwarding to different LAN servers depending on the client's IP address. Or opening up other ports in response a client connection (port triggering or FTP).

I've never looked at SIP stuff but I know that it is one of the applications that has to be dealt with in a special way because of problems with NAT traversal.

 

[FreshJR]

No, port forwarding applies to incoming (WAN to LAN traffic).

"forward all unsolicited traffic that arrives at our WAN interface to 192.168.1.50:80". This will establish the initial connection and is tracked in the conntrack table.

Yes I understand this in its entirety, but unsolicited incoming WAN to LAN traffic has two parts.

From WAN to the router (INGRESS) and then from the router to the LAN device (EGRESS).

Ingress = towards the router.
Egress = away from the router.

( Egress != upload )
( Ingress != download )
( Download has an ingress/egress portion, Upload has an ingress/egress portion)

But now I see that it doesn't matter whether the port rule is applied on the egress or ingress portion of incoming traffic. (I definitely think port forward rules are consulted on the ingress traffic, but the potential issues I brought up in my previous post would not be happening!)

I thought port forwarding redirection was absolute (as in if the rules applied to incoming ingress traffic filtered by sport, then no other device on the LAN would be able to communicate with a server hosted on that sport since all incoming traffic would be redirected to the port forwarded device and away from the non-forwarded requesting device ).

Now I see that it doesn't matter and the above situation wouldn't happen, since if a connection is already present in the conntrack track table then the port forward redirection will not be consulted/applied.

So
- initial connection of unsolicited traffic will always consult port forward rules and be dropped if it doesn't produce a match.

- connections established, from non port-forwarded devices, to a server that is hosted on sport that matches a port-forwarded device will not have their return traffic redirected away from them as the conntrack table will be return a result before port forwarding table is consulted.

Many thanks Colin!! I am glad to understand how the various routing tools interact with each other. Now I don't have to rely on trial and error to see the results of my actions.

 

[ColinTaylor]

EDIT: Hang on a moment. I see you've updated your post. Let me re-read it.

OK Yes I think we're both on the same page now. Understandably you're viewing it from a QoS-type ingress/egress perspective. I just see it as WAN to LAN and vice versa.

 

[FreshJR]

Again, sorry I'm not quite understanding this. Can you rephrase it.

So I think I got it.

If you look at this table.

[    <--   TRAFFIC FLOW  <--        ]

[      EGRESS       ]
[  dport  <-  sport ]          

          [        INGRESS         ]
          [   dport  <-   sport    ]

LAN1:4500 <- WAN:4501 <- SERVER:4500  (established)
LAN2:4500 <- WAN:4502 <- SERVER:4500  (established)
LAN3:4500 <- WAN:4503 <- SERVER:4500  (established)
LAN4:4500 <- WAN:4500 <- SERVER:4500  (port forwarded)

It shows 3 established connections & the last one is a port forwarded connection.

A potential issue I thought was that port forwarding was a simple traffic rule that said:

- if sport = 4500, then forward it to LAN4:4500

If this rule is consulted on the INGRESS portion (right), then no traffic would flow to LAN 1, 2, & 3.

If this rule was consulted on the EGRESS portion (left), then traffic would still flow to LAN 1, 2, & 3

With your additional explanation, I see that it doesn't matter on which portion of traffic the port forward rule is consulted (with chances are it being consulted on the INGRESS portion of incoming traffic.)

You additional explanation made it seem like first the CONNTRACK table is consulted before the port forwarding rules are evaluated. If that is the case, the bolded situation will NOT be happening since the "established" connections will be present in CONNTRACK.

EDIT: Hang on a moment. I see you've updated your post. Let me re-read it.

OK Yes I think we're both on the same page now. Understandably you're viewing it from a QoS-type ingress/egress perspective. I just see it as WAN to LAN and vice versa.

That was my initial worry. That if I port forward the shared ports, that I will cause blackouts to non-portforwarded devices.

 

[ColinTaylor]

Your previous example can be a bit misleading. Because you're using port 4500 that implies SIP, but as we already know SIP through NAT is a special case that requires the use of other ports and helpers.

If we assume that port 4500 on SERVER is just a normal server and not a special case like SIP then the scenario described wouldn't occur.

LAN1:4500 <- WAN:4501 <- SERVER:4500 (established)
LAN2:4500 <- WAN:4502 <- SERVER:4500 (established)
LAN3:4500 <- WAN:4503 <- SERVER:4500 (established)
LAN4:4500 <- WAN:4500 <- SERVER:4500 (port forwarded)

LAN1, LAN2 and LAN3 are client devices that initiated the connection to SERVER that is listening on port 4500. You can if you want port forward incoming traffic to our router's port 4500 to LAN4 (also on port 4500). But in the specific example above you have a server (SERVER) behaving like a client and initiating a connection to our server. It's also using the same port (4500) for it's outgoing client connection that it is listening on for its server. This is not a realistic situation.

 

[FreshJR]

But in the specific example above you have a server (SERVER) behaving like a client and initiating a connection to our server. This is not a realistic situation.

Isn't that exactly what happens on an incoming phone call.
The SERVER initiates an unsolicited incoming connection our router(WAN). If a connection from this server is not already in the CONNTRACK table then the routers NAT would drop it since it wouldn't know which device to push it too.
So on every incomming phone call, the server does behave as a client and initiates a connection to our WAN in hopes of reaching the intended LAN device.

What's wierd is that:
Lan devices 1, 2, 3 keep an established connection 24/7 so there never an issue with transversing NAT (unsolicited incoming data).
Lan device 4 apparently, for whatever reason, doesn't keep an established connection, so any incoming phone calls never reaches LAN4. (I think it foolishly relies on the router having a working SIP passthrough implementation which in this case was disabled.)

As supplmentary bandaid fix, assuming the worst case scenario of the routers SIP pass through implementation not working, I was thinking of additionally forwarding all 500,4500 traffic into LAN4.
(This solution really is a bandaid fix since a "port forwarding" solution would not be possible if the network had more than one of these LAN4 VOIP devices. These devices are aparently 100% reliant on a working SIP implemention rather than keeping established connections as a backup) .

On a side note, I did enable the "SIP passthrough" setting on the cisco router which might now be enough for incoming data to transverse NAT and reach the poorly implemented LAN4. I think that besides relying on SIP, having port forwarding act as a backup wouldn't hurt anything either.

I trust port forwarding more than a working SIP implementation. But I guess I'll give ring my buddies "landline" once a week, and see if it glitches out.

 

[ColinTaylor]

Isn't that exactly what happens on an incoming phone call.

Indeed, that's why I was at pains to point out that my description/examples did not apply to SIP because SIP is an exceptional case. I was talking about traditional client/server setups.

I don't use SIP so I've only ever had a cursory look at it. But once you start talking about systems that require helpers and application level connection tracking all bets are off. The application designer can invent any system he likes, so it's impossible to generalise about these.