The really cool part about this is that the server does not need to know the client's ip address. Instead a new original form of ICMP hole punching is used to allow any client to punch the NAT so that the server can dynamically learn the client ip, and then regular UDP hole punching is used.
> This will work behind many NATs and firewalls, but not all.<p>While this is an interesting concept, the hard part in NAT traversal is getting it to work on all the possible NAT types. In particular, I believe that this method doesn't work for symmetric NAT devices[1], which are widespread in corporate environments. It's not a surprise that this idea from 2010 didn't take off, ICE/TURN are still kings.<p>[1] These devices assign a different port for each destination address, and this ICMP method doesn't help predict the port that will be assigned.
This is old technique from early 2000 and flawed as others have described. Outgoing ICMP is blocked in every corporate environment I have ever been to and never makes it to the Internet facing gateway.
I had a quick test, not working for me
many previous comments about this script
<a href="https://hn.algolia.com/?q=pwnat" rel="nofollow">https://hn.algolia.com/?q=pwnat</a>
So is this a tool or an exploit? Or both? Is this something likely to get patched by the major software/hardware vendors? Would this be a tool that would be safe to use at home if I wanted to connect to a private network on AWS or GCP and did not want to poke a hole through my nat gateway at home?
I think you might have a typo in your FAQ.<p>"Does the server have to specify the client host?
No!.....
The server does need to have any unique prior knowledge about the client. "<p>Should that read, "The server does NOT need to have any unique...." ?
Cool, I used to do this by spoofing udp packets from 3.3.3.3 from the client to the servers public up, but was unreliable due to anti spoofing filter. This way is better