tl;dr It comes from STUN and is symmetric because it identifies a 1:1 relationship between NAT mapping and L4 flow.
The name symmetric NAT is as far as I know introduced by the original STUN RFC 3489, with the following definition:
A symmetric NAT is one where all requests from the same internal IP
address and port, to a specific destination IP address and port, are
mapped to the same external IP address and port. If the same host
sends a packet with the same source address and port, but to a
different destination, a different mapping is used. Furthermore, only
the external host that receives a packet can send a UDP packet back to
the internal host.
This may not clarify things if you are not that familiar with NAT and the whole concept of STUN. Let me try to build this up.
The first important concept is the 5-tuple
(protocol, host port, server port, host address, server address) where protocol is most commonly either
TCP. This 5-tuple is used to identify a L4 protocol flow. I use
server terminology to simplify some things and avoid directional terms such as source and destination.
Now, the whole concept of a
NA(P)T device is to dynamically replace the
(host port, host address) on the internal network (inside) with a
(NAT port, NAT address) on the external network (outside). The state of such a translation is also called a
NAT mapping. At its most simple the NAT function does not care about
server ip, and
server port. In this case multiple Layer 4 protocol flows may use the same NAT mapping, as long as the
host ip and
host-port used on the inside are the same. This N:1 model of multiplexing/demultiplexing flows to mappings is often represented via a funnel or cone.
The biggest alternative is to create a mapping for each new 5-tuple. So even if for example all of
protocol, host ip, host port, and
server ip are the same but
server port is different, a new mapping will be created and the resulting
NAT ip, NAT port will be different. There is thus a full 1:1 symmetry between a layer 4 flow and a NAT mapping.
Not relevant to the question, but just some history why this term is actually important for the STUN RFC and not left as an implementation detail. One of the goals of stun was to enable P2P connections between two clients behind NAT. The idea was that for many applications (e.g. VoIP) there would only be initial communication via servers, but all remaining communication would be P2P. To set up this P2P, the clients would make a connections to a stun server, which does three things:
- It informs them on the type of NAT, as this only worked with the 'full cone' version. So detecting cone vs symmetric is important here (stun has a few variants of cone actually)
- It creates a NAT mapping as explained above.
- The stun sever informs the client of the outside port+IP of that mapping.
Then, the client would send the learned port+IP via the application (voip) server to the other client, and now that can be used to set up a P2P connection.
In practice this barely works, and stun as described there was obsoleted and replaced by RFC 5389. In addition, many NAT implementations have added Application-level Gateways to solve certain protocols directly. On top of that there are specific protocols to create NAT mappings on demand, most prominently UPnP IGD and PCP. But, as often happens, some of the original STUN concepts stuck forever anyway :).