Shortcomings of CGNAT and Potential Workarounds

It would be appreciated if you could help me continue to provide valuable network engineering content by supporting my non-profit solitary efforts. Your donation will help me conduct valuable experiments. Click here to donate now.

This article will mostly focus on the cons of deploying CGNAT and how it ultimately affects the end-user and what are some of the methods that we can use to improve it.

A quick recap on CGNAT, CGNAT is just a fancy name for NAT whereby an ISP will NAT or map multiple internal IPs (usually the ISP will incorrectly use RFC1918, but ideally should use RFC6598) to a single external public IP, i.e., enabling a single public IP to be shared among n number of internal IPs, where each internal IP is assigned to an end-user. Methods used can vary from ISP to ISP, some would just use single source NATs, some would use deterministic NAT etc.

Shortcomings

1. Breaks P2P traffic.
2. Increases latency.
3. It leads to NAT-keep alive traffic (such as NAT punching, NAT traversal mechanisms etc) on end-users’ local network as well as on the CGNAT device itself.
   1. Which in theory could affect battery life on end-user devices.
   2. Increased link utilisation/CPU cycles on the CGNAT device.
4. Some end-user applications will simply refuse to work or fail miserably like Xbox Networking (P2P Gaming services), Torrent clients etc.
5. Lacks NAT traversal mechanisms/port forwarding (by default).

Now the IETF published RFC 7021 in 2013 which details how CGNAT impacts networking performance and end-user experience, if you want technically backed data and testing methodologies please check that out.

Workarounds

There are two broad ways to workaround CGNAT cons:

At ISP Level

1. Do the obvious and deploy IPv6.
   • Once IPv6 is deployed, I recommend you remove CGNAT from the network and migrate to MAP-T in conjunction with point number 2 below.
2. Ensure your CGNAT vendor/configuration is complying with both Full-Cone NAT method and Endpoint Independent Mapping/Endpoint Independent Filtering (EIM-NAT). By doing so, you are ensuring that P2P (end-to-end) IPv4 traffic for your customers behind CGNAT will still work, this is the best solution short of migrating 100% to IPv6.
   • For MikroTik follow the CGNAT section(s) here—Though MikroTik added support for EIM-NAT since RouterOS v7.10, in my testing, it is broken and not up to the mark, hence the original netmap method is still relevant in the article.
3. Deploy Port Control Protocol [PCP (RFC 6887)].
   • PCP would allow port forwarding to work for end-users behind a CGNAT and hence improve their experience and reduce the visibility of the shortcomings.
   • Needs a Server/Client model, so a client would need to run on end-user’s router/CPE.
     • Can use OpenWRT with minimalist-pcproxy to enable PCP client and PCP connectivity from end-users’ side for a cheap solution.
   • Many vendors like MikroTik (most widely used as a CGNAT device among Indian ISPs) do not support PCP.
   • Lack of awareness among ISPs and network engineers.
   • You can also have a web dashboard for PCP to permit users to assign their own ports.

At End User Level

1. Ask your ISP to read this article, tell them to deploy Full-Cone NAT and EIM-NAT configuration on their CGNAT box.
2. Get a public IP from your ISP (most optimal solution).
3. VPN based solution where you route all traffic over the tunnel including multicast traffic (UPnP).
   • Many third party platforms exist such as Tailscale, ZeroTier etc.
   • Set up your own VPN/VPS on a Cloud instance with public IP and then run a VPN client on your home router/client device.

Conclusion

Even if you properly configured CGNAT with full cone + EIM-NAT, it is still only a band-aid solution. The proper solution is to migrate 100% to IPv6, and ensure IPv6 best practices are followed to the letter.

Additionally, for both ISPs and end-users, you can test the quality of your NAT44 (NAT) or NAT444 (CGNAT) configuration using this tool. If you see EIM-NAT and Full-Cone, then your IPv4 P2P networking will work fine, until you migrate fully to IPv6.