4 ms·
Nope, 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.
by dfawcus 2y ago
Nope, 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.