Carrier Grade NAT (CGNAT to CGNAT) Testing #383
Labels
development
Standard development
r&d:polykey:core activity 4
End to End Networking behind Consumer NAT Devices
Specification
Existing issues #159 and PR #381 address testing the NAT busting through hole-punching and centralised signalling via
testnet.polykey.io
. We know that certain NAT situations won't be traversable until relaying via #182 is possible. We're parking #182 until #365 is first solved, since the architectures would be similar.This issue is about augmenting our NAT tests to also simulate a carrier grade NAT situation. This is important for mobile device deployment.
To give you an example, our office has a wireless router connected to the ISP. The router provides a LAN for the office computers. However the external IP assigned to the router is not the real IP on the internet, it's also within a LAN with respect to the ISP. The ISP adds their own NAT on top of our router's NAT.
This means there's a "double NAT".
Therefore we may want to test:
The hardest would be double NAT to double NAT.
When I attempted to use wireguard/tailscale to connect my home laptop to my phone's hotspot to the office router to the windows/mac systems in office, I noticed that it had to use the DERP relays, a direct connection was not possible. This implies hole-punching and signalling is not enough in theses situations. But we can simumlate this using our NAT simulation harness.
The CGNAT is likely to be a port-restricted or symmetric NAT. And as we saw in #381, we don't need to test address-restricted or full-cone as long as port-restricted and symmetric works.
Additional context
testnet.polykey.io
#487 - demonstrates that CGNAT to NAT and NAT to CGNAT works.Tasks
The text was updated successfully, but these errors were encountered: