would it hurt the kernel to "borrow" the port from the TCP port pool when it becomes actively masqueraded?
I guess the answer is "no, but it doesn't matter much."
I incorrectly assumed R only used the destination transport address of the response packet to tell whether it was headed towards A or itself. It actually seems to use the entire source-destination transport addresses tuple to identify a connection. Therefore, it's actually normal for NAT to create multiple connections using the same (R owned) port; it doesn't create any confusion. Consequently, the TCP/UDP port pools don't matter.
It's pretty obvious now that I think about it.
I then tried to open the following client on R: nc -4 192.0.2.8 60000 -p 50000
. I sent messages, nothing happens. No packets can be seen on R's tcpdump.
This is the part of the experiments where I messed up.
The failure happens because both the source and destination transport addresses are the same, not just because the source address is the same.
If I do, say, nc -4 192.0.2.8 60001 -p 50000
, it actually works. Even if it's using the same port as a NAT mask.
I feel the NAT's behaviour is wrong. I could accidentally configure a port for both masquerading (particularly, by not specifying --to-ports
during the iptables rule) and a service, and the kernel will drop connections silently.
It won't, because the masked connections and the R-started connections will most likely have different destinations.
Because the masquerade rule exists, or at least because it's active, I would have expected R's nc to fail with the error message "nc: Address already in use", which is what happens if I bind two ncs to the same port.
I'm still looking for a bulletproof answer to this, but everything seems to point to "it's an adverse consequence of how it's implemented, and it's so small we're willing to live with it."
Best Answer
For this example, I launched Transmission to download Ubuntu 15.04 via BitTorrent protocol. Here is a quick way to see if there is some UDP involved:
So yes, it looks like there is some UDP involved.
Now if you want to go further, you could capture and analyze the network data using a tool like Wireshark.
Editor's note:
I self-compiled Transmission 3.00, launched my VPN, opened both TCP and UDP ports for torrenting, results after a few minutes are clear, Transmission received 8 TCP packets, while at the same time frame 1673 UDP packets as documented by a snippet from
iptables
:Anyhow, another thing I found as proof of UDP action = trackers: