Non-symmetric NAT seems like a major security vulnerability, though. Couldn't I hijack any application whose eAddr:Port I knew simply be replying faster than the actual server? My traffic would appear to the client as identical to traffic from the actual server, no?
Why do people deploy NAT that is not symmetric?
Also, why couldn't Skype and BitTorrent simply use those techniques rather than relying on certain users to serve all the firewalled traffic?
What is the demographic of your product where you're seeing a 90-95% success rate?
It's actually hard for me to test symmetric, since I don't have access to any networks nor have I found any that are symmetric. I have to simulate it on a test net with a special iptables config.
Symmetric seems rare in the field, though it also seems most common in "enterprise" environments. My guess is that some major vendor like Cisco or Juniper sells symmetric NAT engines. All the users I've heard from who are behind symmetric are in large corporate or university networks. I've never even heard of a symmetric NAT consumer device.
My guess is that full cone is most common because (a) it's simpler at the router and (b) it guarantees maximum compatibility. As I said: NAT traversal is a "de facto standard" used by a number of products. If those products don't work or are slower than molasses, users complain that "the Internet is broken." That sword cuts both ways. Vendors probably found that fewer complaints about "broken Internet" came when they went to full cone NAT.
There are ways of traversing symmetric NAT, but none of them can be guaranteed to be successful the way full cone hole punching is, and some might look like a port scan or an attack and set off alarm bells. They include psychotic techniques like:
* Proposing that the symmetric NAT box assigns ports sequentially and trying the next few (may look like a port scan).
* Proposing that the symmetric NAT box may assign ports using the standard K&R linear congruential rand() function, inductively determining the PRNG state, and guessing the next ports by extrapolating the next sequence numbers (also may look like a port scan).
* Impersonating a DNS server and sending a packet that refers to the NAT-t target as if it were a delegated DNS server (apparently some symmetric NATs have DPI logic to make stuff like this work, which can be exploited... but this can look like an attack).
* Having the host behind symmetric NAT probe its own exterior ports 1024-65535 and determine the port assignment schema by doing NAT-t against itself (looks like an attack).
* Impersonating IPSec and triggering "make IPSec VPNs work" DPI logic in the router (absolutely requires 'root' on the host and SOCK_RAW, which Windows doesn't have).
* Various "Jackass stunts" with ICMP that can set of IDS systems.
I would not do any of that stuff in a Real Product(tm), but it's all cool in a cool hack kind of way.
Nevertheless, the statistical rarity of symmetric means that just relaying peoples' traffic for free is basically... free... at least within reason.
As far as I know BitTorrent does use hole punching, but maybe not in the official bittorrent.com client. Take a look at Transmission and uTorrent. They use uTP, which is basically an application mode TCP stack that runs over UDP, and they pair it with hole punching. I have used them many times behind NAT and they work... you'll notice that if you're behind NAT nearly all of your peer links are uTP instead of TCP.
I don't know about Skype. I know they use servers only on mobile, but I don't know what their desktop client does. Skype is super closed and obfuscated, so only way to tell there is to fire up a sniffer.
My demographic is mostly consumers and small businesses, so it's going to be mostly consumer routers and hotels and such. I do see some symmetric with .edu users.
Product is here: https://www.zerotier.com/
If it can't do NAT-t, it will relay UDP (for free). If it can't do UDP at all it will fall back to relayed TCP over port 443 that looks like TLS. It works just about everywhere. Being able to NAT-t just makes it run a lot faster.
I'm considering taking the engine behind this and SDKifying it and then trying to make it play nice on mobile. The latter is IMHO much harder than dealing with NAT, and if I could do it would make it a first-in-class product. But I don't want to spend the time if nobody wants such a thing.