4 ms·
The article (like many others) distinguish between easy NAT (endpoint-independent) and hard NAT (endpoint-dependent symmetric NAT), but does not discuss how rea
by zajio1am 6y ago
The article (like many others) distinguish between easy NAT (endpoint-independent) and hard NAT (endpoint-dependent symmetric NAT), but does not discuss how real-world NAT devices behave (whether they are predominantly easy NATs or hard NATs).
In reality, home routers are generally Linux-based and share netfilter NAT implementation. And how this implementation behaves? Well, it is a symmetric NAT masquerading as a port-restricted cone NAT. While it is symmetric NAT, it tries to reuse internal port as external port, and therefore often ends with the same port on different NAT mappings to different external machines.
Therefore, NAT traversal often works by accident in simple cases, but suddenly stops to work when it becames more complicated (e.g. when two clients behind a NAT try to connect to the same server).
Linux netfilter has an option to randomize ports in NAT mappings to avoid this appearance of working, but it is unlikely that home routers allow to configure this.
- dave_universetf 6y agoThe article makes the distinction, because it's a useful empirical distinction to draw :). While you're correct that linux is, strictly-speaking, an endpoint-dependent implementation, it goes to sufficient effort to reuse mappings in an endpoint-independent way that you can do useful things against it by treating it as an EIM NAT. Similarly, commercial systems like JunOS try to stick to EIM behavior for as long as they can, and only shift to EDM behavior when load makes it infeasible to do otherwise. There again, strictly speaking that means you should abandon all hope... But in practice, NAT traversal still works much more often than not, and we can use that to build useful systems while we wait for IPv6 adoption to continue.