Public IP but inbound traffic blocked - carrier-side firewall on Three 5G (GreenPacket Y5-210MU)

[Overlord]

I am hoping someone from Three’s technical team can clarify what is actually being provided on 5G broadband. After detailed testing, it is clear that although Three does issue public IPv4 addresses, unsolicited inbound connectivity is still blocked upstream in a way that behaves like CGNAT.

I hope to confirm and validate if others see the same behaviour while on the "3internet" APN.

My setup

• Three 5G Broadband
• GreenPacket Y5-210MU (Outdoor CPE)
• IP Passthrough enabled
• My own router is connected behind it (GL-iNet Flint 2 w/ OpenWrt 24.10.4)
• Local firewall disabled / DMZ tested / no local port blocking

**NOTE: This was also tested using Eero to rule out misconfigurations. However, this behaviour is persistent across all devices and should be reproducible.

IP details assigned by Three

IP Address:  92.40.102.[REDACTED]
Gateway:     92.40.102.13
Netmask:     255.255.255.0
DNS:         92.40.102.13, 192.168.0.1

• This is not classic CGNAT (per RFC 6598, 100.64.0.0/10)
• It is a public IPv4 within a shared /24

Problem: Inbound connectivity does not work

• Port forwarding does nothing
• DMZ does nothing
• UPnP does nothing
• IP Passthrough does nothing
• Disabling the router firewall does nothing

Unsolicited inbound packets never reach my equipment.

Diagnostics performed

1) Nmap scan of my assigned IP 

The following nmap commands were executed from another network (Outside Three's network):

nmap -Pn 92.40.102.[REDACTED]

Why Nmap? It is a simple standard tool to determine port state: open, closed, or filtered (RFC 793, TCP).

Host is up.
PORT     STATE     SERVICE
22/tcp   filtered  ssh
23/tcp   filtered  telnet
25/tcp   filtered  smtp
139/tcp  filtered  netbios-ssn
445/tcp  filtered  microsoft-ds
1900/tcp filtered  upnp
2869/tcp filtered  icslap

• "Filtered" indicates packets are dropped before reaching my router
• Confirms the issue is upstream, not local

2) Nmap scan of a random IP in the same /24

nmap -Pn 92.40.102.99

Host is up.
PORT     STATE     SERVICE
25/tcp   filtered  smtp
139/tcp  filtered  netbios-ssn
445/tcp  filtered  microsoft-ds
1900/tcp filtered  upnp
2869/tcp filtered  icslap

• Same filtered pattern
• Which confirms that filtering does occur at the carrier level across the entire subnet

3) Nmap scan of the assigned gateway

nmap -Pn 92.40.102.13

PORT     STATE    SERVICE
53/tcp   open      domain
22/tcp   filtered  ssh
25/tcp   filtered  smtp
80/tcp   filtered  http
443/tcp  filtered  https
445/tcp  filtered  microsoft-ds

• Port 53 (DNS) open --> the gateway is a service endpoint, not a simple router
• All other ports are filtered --> stateful firewall actively blocks inbound connections

This explains why port forwarding, DMZ, IP Passthrough, and UPnP have no effect...  Basically, all packets are filtered before they even reach your home equipment.

Technical analysis/references

• So, we are assigned a Public IPv4, but inbound is blocked, i.e., using a carrier-side firewall / shared subnet
• This behaviour aligns with:
  1. RFC 6092 - Stateful firewall considerations
  2. RFC 4787 - NAT endpoint filtering
  3. RFC 793 - TCP handshake semantics
• This functionality is equivalent to CGNAT from an end-user's perspective.

Why does this matter, and what does it affect?

• "Public IP" usually implies inbound routability, but here it does not
• IP Passthrough suggests direct reachability, but it is still blocked upstream
• It affects:
  • Home VPN Servers
  • Game Servers / Open NAT
  • Self-hosted services
  • CCTV / remote access

Questions for Three

1. Is Three intentionally deploying a carrier-side stateful firewall on public IPv4 pools for 5G broadband?
2. If not, can this be officially confirmed so we as customers know what to expect?

I just want clarity on what level of connectivity is provided.

TL;DR

Three 5G provides a public IPv4 address, but inbound traffic is blocked by a carrier-side stateful firewall applied to a shared /24 subnet, making it functionally equivalent to CGNAT. Verified via Nmap scans of my IP, a random IP in the same subnet, and the gateway.

[MymsMan]

I use Tailscale to allow inbound connectivity to my home network from remote locations and it works well.

There is no need to open ports or use the external IP address which changes every time the hub reconnects.

See https://community.three.co.uk/t5/Broadband/Remotely-connecting-to-Three-home-network-with-VPN/td-p/5...

[Overlord]

Hey @MymsMan,

I completely agree! Tailscale, ZeroTier, and NetBird are excellent solutions for secure remote access to a home network. They work really well without needing to open ports, without relying on changing public IPs, or deal with NAT issues. I personally use all three myself depending on the setup, and they are reliable and safe for most scenarios.

That said, I don’t think there’s any reason for Three to deploy restrictive firewalls on public IPv4 addresses.

For example, I run a personal web server that requires ports 80 and 443 to be open for HTTP/HTTPS traffic, including obtaining Let’s Encrypt certificates and reverse proxying. I also self-host my own Nextcloud instance (friends and family only) and occasionally a Minecraft server or two.

However, blocking all inbound traffic seems overly restrictive for users like me who are just trying to use their connections fairly.

While VPN overlays and mesh networks are fantastic for many scenarios, there are still legitimate cases where having true inbound connectivity makes things simpler, more reliable, and compatible with standard internet protocols.