3 ms·
> To connect between NATted hosts, you need control of a host that is not Um, no? https://github.com/samyk/pwnat https://github.com/samyk/pwnat
by quantumofalpha 6y ago
> To connect between NATted hosts, you need control of a host that is not
Um, no?
https://github.com/samyk/pwnat https://github.com/samyk/pwnat
- ohazi 6y agoSo we've known about this for years, but does anyone actually rely on this behavior in production, or are we all still pretending that this clever hack could be patched out of existence any day now? It clearly works. It's worked for a long time. But the common opinion still seems to be "well, this isn't supposed to work, so using it is a bit dodgy..."
- octoberfranklin 6y agoI don't think anybody sane tries to get two machines behind different NATs to talk to each other without the NATs' cooperation in production.
- quantumofalpha 6y agoWell, you need just one NAT to be cooperative, like a full cone. There's enough legitimate interest in NAT traversal that big NAT deployments like CGNATs tend to cooperate Traversing non-cooperative fully symmetric NATs, which randomize ports, is hard enough also for pwnat. Though in theory should be doable - you just need a lot of patience to brute force ports (there's only 64k of them) until it finally clicks
- ncmncm 6y agoThank you for this. I will try it.
- ncmncm 6y agoI tried it... SEGFAULT in the client: Null pointer to a port-number arg. I supplied all of the optional arguments...
- ncmncm 6y agoFrom the paper, "Autonomous NAT Traversal", Mueller/Evans/Grothoff/Kamkar, IEEE P2P 2010: "Conclusion: ... the presented method works ... virtually never if both peers are behind NAT." Still, "virtually never" is not "never".