Provided for informational purposes only. The terms used for describing NAT types here in this article are based on classical STUN[RFC3489], which has been obsoleted by subsequent amendments. For the latest definition of NAT behaviour, please refer to [RFC4787] and [RFC5389]
full cone NAT = network traffic-initiated automatic port-forwarding managed by the kernel
xx-restricted cone NAT = traffic-initiated automatic port-forwarding with firewall implemented in someways
symmetric NAT != port-forwarding
A symmetric NAT can map the same NAT port to multiple inner tuples based on the incoming packets' source(and the destination port on the NAT device, of course).
The differences:
cone NAT/port-forwarding = one-to-one mapping between (NAT port, inner tuple)
symmetric NAT = one-to-one mapping (NAT port && source, inner tuple)
Is symmetric-to-symmetric NAT traversal possible?
Though rarely being implemented in reality, theoretically, symmetric-to-symmetric NAT traverse is still possible through guessing or using an oracle, but only if is there a predictable pattern, such as a linear increase, in the NAT ports allocated on both sides.
With tricks implemented, we can send packets from a different source outside the LAN to a symmetric NATed socket behind the NAT (i.e. Linux's netfilter with several additional rules in place, such as DMZ or DNAT rules, which could lead to a "full cone" test result using classical STUN[RFC3489]).
However, the port allocation behaviour is ambiguous in some NAT implementations; take netfilter as an example. Technically, we can never say for sure using merely STUN if the port allocated on the NAT device is, in fact, consistent or mutable for the same tuple inside the LAN. Consequently, any "cone NAT" device tested using classic STUN could turn out to be "a symmetric NAT in disguise" in the end. We would never know for sure from outside the box.