Something maybe worth checking out when googling. Seems very impressive from this ex hackerhttp://samy.pl/pwnat/
My method of penetrating NATs is two-fold which I will describe below.
In order for the full tunnel to be established, the client side needs to
know the public IP address of the server, and the server needs to learn
the public IP address of the client.
However, in a true client-server model, the server doesn't know the client IP
until the client connects, and NATs will normally drop unknown incoming packets.
In pwnat, the server also does not need to know the client IP address.
Here is how the pwnat server learns the IP address of the client:
I get around this by having the client "pretend" to be a random hop on
the Internet. I'm essentially using the same technology a traceroute uses
to detect hops on the Internet, but I'm doing the reverse in order to
penetrate the NAT.
Specifically, when the server starts up, it begins sending fixed ICMP echo
request packets to the fixed address 126.96.36.199. We expect that these packets
won't be returned.
Now, 188.8.131.52 is *not* a host we have any access to, nor will we end up spoofing
it. Instead, when a client wants to connect, the client (which knows the server
IP address) sends an ICMP Time Exceeded packet to the server. The ICMP packet
includes the "original" fixed packet that the server was sending to 184.108.40.206.
Why? Well, we're pretending to be a hop on the Internet, politely telling the
server that its original "ICMP echo request" packet couldn't be delivered.
Your NAT, being the gapingly open device it is, is nice enough to notice that
the packet *inside* the ICMP time exceeded packet matches the packet the server
sent out. It then forwards the ICMP time exceeded back to the server behind
the NAT, *including* the full IP header from the client, thus allowing the
server to know what the client IP address is!
Thx again for UVNC