CCTV

When Three’s 3internet APN stops giving you a public IP: what CCTV installers need to know in the Vodafone–Three era

16th October 2025 · 11 min read
CCTV installer troubleshooting public IP loss with 3internet APN.

CCTV installers have leaned on Three’s cheap unlimited SIMs for years using the 3internet APN to get a public IP address so they could use DynDNS. The trick was simple: pop in a £10 consumer SIM, set the APN to 3internet, get a public IPv4, point your DDNS at it, and forward ports on the router. Job done.

That trick is failing more often. Even where nothing changed on the router or DDNS, sites that used to be reachable from the outside are now stuck behind CGNAT. This is showing up most strongly as Vodafone and Three begin large scale MOCN network sharing, which moves devices between masts and backhaul that do not behave the same way for IP addressing. The result: previously public IPv4 on 3internet becomes shared NAT in some areas, and inbound access breaks. Vodafone+2VodafoneThree+2

This article explains what changed, how to confirm it, why your cloud app still works while P2P or direct access does not, and the practical options to restore reliable remote access. Examples assume a Teltonika RUT901 since it is the common box we see in these installs. teltonika-networks.com

The moving parts: Vodafone–Three sharing and CGNAT

Network sharing is live and expanding. VodafoneThree say MOCN has already been enabled at hundreds of masts and will roll to thousands more through 2026. Your SIM stays “on Three”, but radio access can be delivered via a shared site. That can change which core or IP policy you hit. ISPreview UK+3Vodafone+3VodafoneThree+3

CGNAT is increasingly used. Carrier-grade NAT means your router gets a private address on the mobile side and shares a public IPv4 with many others. It saves scarce IPv4 addresses, but it breaks inbound connections and makes classic DDNS workflows ineffective. Reports in 2024–25 show 3internet no longer consistently delivers public IPv4 everywhere. Sometimes it does, sometimes it flips to CGNAT by cell or time of day.

Why DDNS “looks fine” but remote access fails. DDNS only tracks an outward-facing IP. Under CGNAT the outward IP belongs to the carrier’s NAT, not to your router. You cannot port-forward a shared carrier IP, so inbound connections have nowhere to land. Many vendors and ISPs explain this plainly: CGNAT blocks inbound and makes DDNS unsuitable for remote hosting.

Quick diagnostic: am I behind CGNAT even though I’m using 3internet APN?

On a Teltonika:

  1. Check the mobile WAN address in WebUI: Status → Network → Mobile. If you see 10.x.x.x, 100.64.x.x, 172.16–31.x, or 192.168.x.x on the cellular interface, that is private space and you are behind CGNAT.
  2. Compare with an external IP checker from the router’s Diagnostics. If WAN shows private, but the test shows some unrelated public IP, you are behind CGNAT even if the public IP looks stable.
  3. CLI: ip addr show wwan0 or gsmctl -A 'AT+CGPADDR' for the PDP address.

Tip: Some users have found that switching the PDP type from IPv4v6 to IPv4 only on 3internet can return a public IPv4 in specific areas, though this is not guaranteed and is increasingly rare. Three Community

Why the cloud app still connects but P2P/direct fails

Installers often ask: “Why does the NVR still report to the vendor cloud but my P2P app or direct login does not work?”

  • Outbound to the vendor works because CGNAT does not block outbound client sessions. The NVR or camera opens a session to a cloud broker and keeps it alive. Your phone then talks to that cloud service, which relays traffic back down the existing session. That model survives CGNAT.
  • Direct inbound to the site fails because port forwarding is impossible on a shared carrier IP you do not control. P2P systems that rely on NAT hole punching can also fail or degrade under CGNAT, especially if both ends are behind symmetric NAT or relay quotas get hit. Practical guides and community threads are blunt about this: no inbound under CGNAT unless you add a tunnel or buy a reachable IP service.

The bottom line: cloud heartbeat looks healthy, but installer-style remote admin that expects a reachable public socket will not work without redesign.

The router we see most: Teltonika RUT901

The RUT901 is a rugged dual-SIM LTE router with Wi-Fi AP, VPN clients and server, and good tooling for industrial deployments. It is well supported with step-by-step OpenVPN guides and RMS integration for fleets. It is a solid base for all of the options below.

Your options when 3internet stops being public

There are five practical approaches. Pick based on how much control and security you want, and whether you are willing to move away from consumer SIMs.

Option A: Try to coax a public IPv4 on Three

  • Set APN 3internet, PDP type IPv4 only. Reconnect and recheck the WAN IP.
  • If you suspect a specific mast is CGNAT-only, you can try forcing PLMN to Three and band locking to prefer alternate sectors. This is diagnostic and often temporary.
  • Be aware this is a best-effort hack, not a strategy. Reports show 3internet can be public in one place and CGNAT two streets away, then flip next week as rollouts progress. Three Community+1

Option B: Move to an IoT SIM that guarantees a reachable IP

  • Private IP with managed VPN handoff or public static IP is the cleanest drop-in replacement for the old port-forwarding model. Your SIM provider hands you either a public static or a fixed private address and a tunnel to reach it.
  • For CCTV this means predictable addressing and access that does not change when masts or policies change. Many providers sell private IP APNs and VPN termination specifically for M2M fleets. The general industry guidance is clear: if you need inbound, CGNAT means buy a product that supports it.

Option C: Keep any SIM, but make the router call out to your head-end VPN

  • Turn the model inside out. Do not try to reach the site from the Internet. Make the site join your network by establishing a persistent outbound tunnel from the RUT901 to your server.
  • Tools: OpenVPN or WireGuard to your own VPS or data centre, or Teltonika RMS VPN if you prefer a managed hub. Once the tunnel is up, you reach the LAN devices over the VPN address space.

Option D: Use the vendor’s cloud relay for viewing only, and add a secure admin path

  • Many NVRs offer cloud view that is fine for live and playback, but painful for admin. Pair it with a narrow VPN path for maintenance. You get the convenience for customers and a reliable secure route for engineers.
  • If you must keep consumer SIMs due to budget, this hybrid is often the least disruptive compromise. The key is that the admin path is outbound VPN from site, not inbound to a CGNAT address. Channels Community

Option E: IPv6 if your vendor stack supports it

  • Some carriers deliver public IPv6 even while IPv4 is CGNAT. If your NVR, app, and security tools handle IPv6 well, you can publish services over IPv6 and call it a day. In practice, CCTV vendor support is still patchy, so treat this as an advanced case.

Step-by-step: resilient access with a RUT901

Below are field-tested patterns that avoid surprises when cells switch policy or when the Vodafone–Three integration shuffles your sites around.

1) Quick shot: test for a remaining public IPv4

  1. WebUI → Network → Mobile → SIM settings.
    APN 3internet, set PDP type to IPv4 and disable IPv6. Save and reconnect.
  2. Status → Network → Mobile. If WAN is public and reachable, you have a reprieve. If it returns private space or inbound still fails, move on. Three Community

2) Robust pattern: outbound OpenVPN client from the router

  1. On your server or cloud VPN (OpenVPN Access Server or CloudConnexa are fine), create a client profile for the site.
  2. RUT901 WebUI → Services → VPN → OpenVPN → Add new instance → Role: Client.
  3. Upload or paste the profile, set it to start at boot, and restrict routes to your management subnets.
  4. Verify that the NVR and cameras are reachable over the VPN. Lock down any old port forwards.
    Teltonika’s docs and OpenVPN’s own guides cover this workflow in detail.

3) Managed fleet: Teltonika RMS VPN hub

If you manage dozens or hundreds of sites, RMS VPN is faster than rolling your own for every project.

  1. Enrol the RUT901 in RMS.
  2. Create an RMS VPN Hub, add the device and your user, add routes for the camera and NVR subnets, and start the hub.
  3. Engineers connect to the hub client and browse to devices across sites without any public exposure.
    The official RMS docs and community threads walk through it step by step.

Frequently asked questions from CCTV customers

Q: My NVR shows “online” in the cloud app. Why can I not log in directly with P2P or via my DDNS hostname?
Because the cloud app uses an outbound session from the NVR to its vendor servers, which works behind CGNAT. DDNS and direct P2P that expect inbound reachability fail because the carrier is not giving your router a public IPv4 to forward to.

Q: Port forwarding used to work. Can you re-do it on the router?
No. With CGNAT the public IP belongs to the carrier’s NAT, not to your router. There is nothing to forward from the Internet to your site. The fix is a reachable IP service or a tunnel. This is not a router misconfiguration. CCTVForum.com+1

Q: Why did this start happening now if nothing changed on site?
Because your SIM is landing on network elements that now enforce CGNAT more aggressively. The Vodafone–Three integration is moving devices around shared masts. IP policy can differ by site and can change over time. Vodafone+1

Q: Can we ask Three to turn off CGNAT?
On consumer plans, almost never. Some business products still offer static public IPv4 on request, but do not assume it. The sustainable path for CCTV is either a private IP SIM with provider VPN handoff or a site-initiated VPN from the router.

Q: Will IPv6 help?
It can, if your cameras, NVR, and client apps support it end to end. Many do not. Most installers standardise on IPv4 with VPN because it works across mixed vendors.

Q: Is sticking with the vendor’s cloud enough?
For viewing, often yes. For maintenance, bulk downloads, or advanced integrations, vendor cloud relays can be slow or limited. A VPN path gives you predictable throughput and tools like SSH, RTSP, ONVIF probing, and firmware push without exposing the site to the public Internet. wiki.teltonika-networks.com

Q: Does the recent Vodafone outage have anything to do with my problem?
Not directly. It is a reminder that core networks change and sometimes fail, so designing for resilience matters. If your access relies on a specific public IPv4 being present on a consumer APN, you have a fragile design. The Guardian+1

Security notes for CCTV over cellular

  • Treat public IPv4 with port forwarding as a liability. Many recorders ship with weak defaults and unpatched services. If you must publish anything, put it behind a VPN and MFA.
  • Prefer site-initiated VPN. Nothing is listening on the cellular interface, which vastly reduces attack surface.
  • Consider moving admin off the customer’s viewing app. Keep customer viewing on the vendor cloud and engineer access on your VPN.

Migration playbook for installers

  1. Identify CGNAT sites using the checks above. Document which ones still get public IPv4 today and which do not. Expect the “public today” list to shrink.
  2. Decide your model: private IP SIM with provider VPN handoff, or your own OpenVPN/WireGuard head-end, or RMS VPN for fleets.
  3. Standardise your RUT901 template:
    • VPN client enabled on boot
    • No inbound services on WAN
    • LAN ACLs for cameras and NVR
    • RMS enrolment for inventory and health
  4. Educate customers: explain why DDNS plus port forwarding on consumer SIMs is no longer dependable. Position the change as a security and reliability upgrade, not a downgrade.
  5. Phase out dependence on the 3internet public IP trick. Keep it as a short-term diagnostic only.

Conclusion

The CCTV market grew up on the assumption that a cheap SIM and 3internet would always expose a public IPv4 you could forward to. In 2025 that assumption no longer holds. CGNAT is normal, Vodafone–Three network sharing is expanding, and the only reliable way to maintain remote access is to stop depending on inbound IPv4 and move to a design that you control.

For most projects on a RUT901, the quickest, robust fix is a site-initiated VPN or an IoT SIM with a guaranteed reachable IP. Both approaches survive CGNAT, tower sharing, and future policy changes, and both reduce your exposure to the Internet at large.

If you want a ready-to-paste RUT901 template and OpenVPN profile checklist for your engineers, say the word and I will include it.

Sources:
VodafoneThree MOCN rollout updates; Vodafone UK and industry coverage; ISPreview user reports; Three UK community; Teltonika RUT901 documentation and VPN guides; Teltonika RMS VPN docs; vendor explanations of CGNAT and why it breaks inbound and DDNS.