3 ms·
> That is completely untrue. The vast majority of home routers (I would venture 99% of them) run Linux, and use the built in NAT, which does check source IP, fo
by vetinari 8y ago
> That is completely untrue. The vast majority of home routers (I would venture 99% of them) run Linux, and use the built in NAT, which does check source IP, for both TCP and UDP connections
Of course it is true. The true thing you wrote is, that Linux is one of the few implementations that do check the source IPs. However, even if many home routers do run Linux, it does not mean that they use Linux's NAT. Many do not have enough CPU power to route/NAT at the speeds needed, so they have hw acceleration for that, and that is a separate implementation.
But hey, why do you think hole punching is a thing? Because it works, relatively large scale.
- beagle3 8y agoHole punching refers to cooperative nat traversal, that is, with help from the inside - in every discussion I have ever seen. Care to point to 3 examples of common home routers that do not check source IP? I’ve verified many TP-Links, Linksys (when they were owned by Cisco) and Netgears, and all used the kernel to NAT (and yes, they couldn’t do the 1Gb while NATting - usually 300-700 or so. And much lower if you use IPSEC)
- vetinari 8y ago> Hole punching refers to cooperative nat traversal, that is, with help from the inside - in every discussion I have ever seen. If by cooperative you mean that there is outcoming connection on the port, then yes, that's cooperative. If by cooperative you mean some sort of port mapping, whether manual or UPnP, then no, you don't need that. For details, see the paper linked in sibling response.
- beagle3 8y agoThat paper does not support your assertion that "most NATs do not check the source address and only check the port", in fact, they only consider "endpoints" which are (ip,port) pairs. Thinking about it, any NAT that ignores the ip part is horribly broken. I still await your examples of routers in actual use that have this behaviour.
- ddalex 8y agoI really don't know a lot about the hole-punching thing, can you please point me to some docs / demos / code / etc. available that would demonstrate this ? Is there any exploit / known technique / program that allows you to explore a network behind a NAT without cooperation from inside ?
- vetinari 8y agoThe concepts are described here: Ford, Bryan; Srisuresh, Pyda; Kegel, Dan (2005), Peer-to-Peer Communication Across Network Address Translators (http://www.brynosaurus.com/pub/net/p2pnat/ http://www.brynosaurus.com/pub/net/p2pnat/) Abstract: Network Address Translation (NAT) causes well-known difficulties for peer-to-peer (P2P) communication, since the peers involved may not be reachable at any globally valid IP address. Several NAT traversal techniques are known, but their documentation is slim, and data about their robustness or relative merits is slimmer. This paper documents and analyzes one of the simplest but most robust and practical NAT traversal techniques, commonly known as “hole punching.” Hole punching is moderately well-understood for UDP communication, but we show how it can be reliably used to set up peer-to-peer TCP streams as well. After gathering data on the reliability of this technique on a wide variety of deployed NATs, we find that about 82% of the NATs tested support hole punching for UDP, and about 64% support hole punching for TCP streams. As NAT vendors become increasingly conscious of the needs of important P2P applications such as Voice over IP and online gaming protocols, support for hole punching is likely to increase in the future. > Is there any exploit / known technique / program that allows you to explore a network behind a NAT without cooperation from inside If you wanted to exploit this, you would have to guess the port, and it would be forwarded to a machine behind the NAT, which "owns" the open port.
- beagle3 8y ago> If you wanted to exploit this, you would have to guess the port, and it would be forwarded to a machine behind the NAT, which "owns" the open port. Only iff you have static nat forwarding that port, which is almost never. With dynamic NAT (99.99% of setups) no machine "owns" the port before it sends a packet out, and once it does, it only "owns" it with respect to the IP it sent the packets to.