I have a question regarding NAT, UDP and TCP.
Given a standard NAT server, is it a problem for it that UDP is connectionless? If so, why?
And does TCP or QUIC solve this problem?
-
Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.– Ron Maupin ♦Jan 7, 2021 at 0:59
Add a comment
|
2 Answers
UDP poses a problem to NAT as there is no traffic to indicate whether a connection (source/destination port pair) is in use any longer or not. UDP reverse routes have to be aged out generally - in contrast to TCP connection states which can usually be tracked by traffic and just need some timeout for cleaning up.
Imagine a DNS request: a client sends a UDP datagram to an outside IP address. The NAT router translates the source address & port and needs to remember where to forward any reply to - but it can't be sure when the replies are actually finished. Aging out these entries too fast breaks several protocols, aging them out too slowly wastes router resources (to the point where it doesn't work reliably any more).
... does the fact that udp is connectionless is a problem for him?
It is not the fact that UDP is connection-less; it is the question if the NAT can figure out the destination computer of incoming packets.
Typically NATs assume that when an UDP packet is sent to some "server" and an UDP packet is coming back from that "server" (using the same port numbers) the computer which sent the first UDP packet is the receiver of the UDP packet being returned.
In this scenario UDP is working well using most NATs.
However in a scenario where simple rules like "the port numbers must match" do not work a NAT will have problems - even in the case of TCP:
Using the original variant of the file transfer protocol (FTP) the client establishes a TCP connection to the server and then the server establishes a second TCP connection back to the client.
This typically will not work when the client is behind a NAT.
Layer 4 protocols that are not "known" by the NAT (maybe GRE, for some NATs maybe even UDP!) will not work anyway.
And does ... QUIC solve this problem?
QUIC is based on UDP and as far as I have understood the port numbers of the packets returned by the server match the port numbers in the packet sent by the client. If a NAT supports UDP the way described above QUIC will work on that NAT.
