4 ms·

I'm unaware of any NAT setup that allows double NAT'd clients to directly communicate with each other. Quite happy to learn different if you'll point me toward

I'm unaware of any NAT setup that allows double NAT'd clients to directly communicate with each other. Quite happy to learn different if you'll point me toward a specific NAT setup that'd allow this. Just off the top of my head, the only way I could see this working is if the NATs themselves aren't transparent, and offer an API to manually map address/port pairs.

saurik 6y ago
I don't understand how double NAT would cause a problem: you send a UDP packet out to someone on the public Internet (maybe STUN) and it will punch two holes; assuming you don't have low quality symmetric NAT, packets sent to the outer NAT on the egress port will be translated to the egress port on the inner NAT which will translate back to the original port on the client. Why do you think this would fail?
iforgotpassword 6y ago
Why would it not allow this? Read the article I linked, it explains why double Nat is not really different. A specific Nat setup would be my home connection, or pretty much anyone using the same ISP. It's CGN and then another Nat at home. Stun works fine with that.
- deleted 6y ago
  [deleted]
mlyle 6y ago
Friendly NATs map, for UDP, e.g. (source address, source port) to (one of our outside addresses, port). Anyone who sends packets back to that outside address gets packets to you. So, you bind 192.168.100.55:5555 and send a packet to a STUN server 1.2.3.4:3478. This creates a mapping between, 192.168.100.55:5555 and an outside port, we'll call it 81.82.83.84:12345. And the STUN server tells you back, in a reply, "you're 81.82.83.84:12345". Then your friend sends a packet from his private address to 81.82.83.84:12345. It reaches your NAT, and is translated to 192.168.100.55:5555 and you receive it. Replying to this packet lets you send packets to him.
- Benjamin_Dobell 6y ago
  Yeah, my apologies. You're indeed correct. I was incorrectly assuming that all NATs dynamically assign a new external port per destination IP-port tuple. As this is what I've observed in practice. However, it looks as though many believe this only occurs for Symmetric NATs, and never Cone NATs. It seems the common terminology just isn't nuanced enough to explain what's really going on. Wikipedia[1] actually has an interesting paragraph regarding terminology: > Many NAT implementations combine these types, and it is, therefore, better to refer to specific individual NAT behaviors instead of using the Cone/Symmetric terminology. RFC 4787 attempts to alleviate confusion by introducing standardized terminology for observed behaviors. [...] Specifically, most NATs combine symmetric NAT for outgoing connections with static port mapping, where incoming packets addressed to the external address and port are redirected to a specific internal address and port. The CGNATs I've encountered, which perhaps aren't representative, are mobile network CGNATs. By observation they were behaving like Restricted (either Address or Port) Cone NATs for inbound packets, but like Symmetric NATs for outbound packets. Hence, the source of my confusion in believing all Cone NATs exhibited this behaviour. EDIT: I'm admittedly poor with the terminology as it's been years since I read the RFCs. I was only now able to express the above after doing a lot of refresher reading. I was coming at this based on experience implementing custom UDP P2P protocols, where I mostly just care about the worst case scenario; and had evidently assumed it more common than it is. [1] https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation https://en.wikipedia.org/wiki/Network_address_translation#Me...

saurik 6y ago

I don't understand how double NAT would cause a problem: you send a UDP packet out to someone on the public Internet (maybe STUN) and it will punch two holes; assuming you don't have low quality symmetric NAT, packets sent to the outer NAT on the egress port will be translated to the egress port on the inner NAT which will translate back to the original port on the client. Why do you think this would fail?

iforgotpassword 6y ago

Why would it not allow this? Read the article I linked, it explains why double Nat is not really different. A specific Nat setup would be my home connection, or pretty much anyone using the same ISP. It's CGN and then another Nat at home. Stun works fine with that.

deleted 6y ago
[deleted]

mlyle 6y ago

Friendly NATs map, for UDP, e.g. (source address, source port) to (one of our outside addresses, port). Anyone who sends packets back to that outside address gets packets to you. So, you bind 192.168.100.55:5555 and send a packet to a STUN server 1.2.3.4:3478. This creates a mapping between, 192.168.100.55:5555 and an outside port, we'll call it 81.82.83.84:12345. And the STUN server tells you back, in a reply, "you're 81.82.83.84:12345". Then your friend sends a packet from his private address to 81.82.83.84:12345. It reaches your NAT, and is translated to 192.168.100.55:5555 and you receive it. Replying to this packet lets you send packets to him.

Benjamin_Dobell 6y ago
Yeah, my apologies. You're indeed correct. I was incorrectly assuming that all NATs dynamically assign a new external port per destination IP-port tuple. As this is what I've observed in practice. However, it looks as though many believe this only occurs for Symmetric NATs, and never Cone NATs. It seems the common terminology just isn't nuanced enough to explain what's really going on. Wikipedia[1] actually has an interesting paragraph regarding terminology: > Many NAT implementations combine these types, and it is, therefore, better to refer to specific individual NAT behaviors instead of using the Cone/Symmetric terminology. RFC 4787 attempts to alleviate confusion by introducing standardized terminology for observed behaviors. [...] Specifically, most NATs combine symmetric NAT for outgoing connections with static port mapping, where incoming packets addressed to the external address and port are redirected to a specific internal address and port. The CGNATs I've encountered, which perhaps aren't representative, are mobile network CGNATs. By observation they were behaving like Restricted (either Address or Port) Cone NATs for inbound packets, but like Symmetric NATs for outbound packets. Hence, the source of my confusion in believing all Cone NATs exhibited this behaviour. EDIT: I'm admittedly poor with the terminology as it's been years since I read the RFCs. I was only now able to express the above after doing a lot of refresher reading. I was coming at this based on experience implementing custom UDP P2P protocols, where I mostly just care about the worst case scenario; and had evidently assumed it more common than it is. [1] https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation https://en.wikipedia.org/wiki/Network_address_translation#Me...