5 ms·
No, Hole Punching is a thing precisely because it (the blocking method) works reliably. A NAT router drops all inbound connections by default because it doesn't
by indigo945 2y ago
No, Hole Punching is a thing precisely because it (the blocking method) works reliably. A NAT router drops all inbound connections by default because it doesn't know where to route them. This reliably protects devices on your network, because no inbound connections ever reach them.
If those applications want to be reached over the network, they can use Hole Punching to turn what would otherwise be an inbound connection into an outbound one. But that requires an effort on both ends of the conversation: if I want a remote client with IP 1.2.3.4 to connect to my server that's behind a NAT, then my server first needs to send a packet to 1.2.3.4. (That's the hole that's punched.) But that doesn't change anything about the reliability of the NAT's protection, because other clients on the internet still can't reach my server. If 1.2.3.4 is not malicious, then nothing bad can happen here. If 1.2.3.4 is malicious, then I was already in trouble when I punched the hole in the NAT, before an inbound connection from 1.2.3.4 even arrives - simply because I created an outgoing connection to 1.2.3.4, over which they could have sent me exploits anyway.
I know you know all of this, but I wanted to add some context to your misleading and pedantic comment for other readers of this thread.
- blueflow 2y ago"Applications" including malicious javascript in your browser.
- dfawcus 2y agoNope, the hole created in the NAT is generally endpoint independent. It does not matter what the target is, anyone can now send packets to that mapping. i.e. assume 192.168.0.1:4567 sends a packet to 12.13.14.15:25, creating a mapping, and keeping that mapping session active. Assume the public translation for that client is 5.6.7.8:7777 Now anyone, e.g. 23.24.25.26:7654 can send a packet to 5.6.7.8:7777 and it will be received by 192.168.0.1:4567. That behaviour is what is relied upon in order to make the NAT hole punching work. It is only 5-tuple stateful firewall punching (of ADPF NAT - which are uncommon) which require that the return packets come from a target punched first. Hence needing the coordinated punching from both sides to the public address:port mapping of the peer.
- citrin_ru 2y agoIt depends on a NAT implication but usually both src port+ip and dst port+ip should match for a reply to be sent back to an internal IP.
- dfawcus 2y agoGo and find the academic survey papers of NAT behaviours. They list what I stated, the common case is EIM+EIF. However, continue with your belief...
- citrin_ru 2y agoI know how NAT works under FreeBSD and it doesn’t ignore remote IP/port. Would be surprised if Linux differs in this regard and most home router are based on Linux. I know little about CGNAT but one shouldn’t trust ISP with protection from unwanted connection and there is almost always a home router with one more NAT even if ISP uses CGNAT.
- throw0101a 2y ago> EIM+EIF This is a new and unfamiliar term/acronym to me. It seems to be from RFC 7857, "Updates to Network Address Translation (NAT) Behavioral Requirements": * https://datatracker.ietf.org/doc/html/rfc7857 https://datatracker.ietf.org/doc/html/rfc7857 People may be more familiar with the various "cone" NAT variation definitions: * https://datatracker.ietf.org/doc/html/rfc3489#section-5 https://datatracker.ietf.org/doc/html/rfc3489#section-5
- dfawcus 2y agoDespite working in the industry, I always found the "cone" terms for NAT confusing, and difficult to remember. So once the BEHAVE terms came out, I adopted them, as they were (at least to me) more obvious. They're also more flexible in that they can describe real behaviours which can not be mapped to "cone" terms.
- throw0101a 2y ago> No, Hole Punching is a thing precisely because it (the blocking method) works reliably. A NAT router drops all inbound connections by default because it doesn't know where to route them. This reliably protects devices on your network, because no inbound connections ever reach them. It is the state tracking that does the protection, which you do not need NAT to do: * https://en.wikipedia.org/wiki/Firewall_(computing)#Connection_tracking https://en.wikipedia.org/wiki/Firewall_(computing)#Connectio... * https://en.wikipedia.org/wiki/Stateful_firewall https://en.wikipedia.org/wiki/Stateful_firewall And by getting rid of NAT, you also remove the need for the convoluted bullshit of STUN/TURN/ICE, and all you're left with is PCP: * https://en.wikipedia.org/wiki/Port_Control_Protocol https://en.wikipedia.org/wiki/Port_Control_Protocol * https://en.wikipedia.org/wiki/Hole_punching_(networking) https://en.wikipedia.org/wiki/Hole_punching_(networking)