CGNAT outbound blocking best practice: what to filter by default, and why

On a public IPv4 address with one subscriber behind it, bad traffic is that subscriber's problem. On CGNAT, it belongs to everyone sharing the address. One infected laptop sending spam can get a public IP blacklisted, and every other household on that IP inherits the result. The helpdesk then sees mail bounces, CAPTCHAs and blocklist complaints from customers who did nothing wrong.

Outbound filtering is the cheapest protection against this. A short, well-chosen block list stops the traffic that does the most damage to a shared address, and costs ordinary subscribers almost nothing. The skill is in keeping it short. Every port you add is a future support ticket, so each entry needs a reason.

This article sets out a sensible baseline for a CGNAT deployment, what to leave alone, and how to apply it using per-group configuration on Netavo CGNAT.

The recommended baseline

For most residential and small business CGNAT pools, this is the set worth blocking outbound:

The common thread is that none of these should be leaving a subscriber's home for the public internet in normal use. Blocking them removes abuse without removing a service.

Why TCP 25 comes first

Port 25 is how mail servers talk to each other. Home devices and ordinary business laptops should not be doing that. Mail clients submit through their provider on port 587 or 465 instead, so a device connecting directly to other people's mail servers on port 25 is usually compromised.

The industry has recommended managing port 25 on residential and dynamic address space for many years, and M3AAWG publishes guidance on it. Many large mail receivers already treat this kind of address space with suspicion, so the block protects your reputation far more than it inconveniences anyone.

What to leave open

Over-blocking is the usual mistake. These are the ones that look tempting and should stay open:

• TCP 587 and 465. These are authenticated mail submission, as used by every mail client. Blocking them breaks email for ordinary customers. Only TCP 25 needs to go.
• UDP 53 and UDP 123. DNS and NTP are used by devices constantly, and many applications and appliances use resolvers or time servers of their own choosing.
• TCP 3389, TCP 22 and database ports. RDP, SSH and SQL all attract brute-force attacks, but small businesses and remote workers use them legitimately. Blocking them produces support calls, and subscribers on CGNAT are outbound clients in these cases.
• Reflection ports such as SSDP, memcached and CLDAP. These are classic DDoS reflectors, but the risk is mainly about devices answering spoofed requests from the internet. A device behind CGNAT has no public address of its own, and source validation stops subscribers spoofing, so a port block adds little.
• GRE and ESP. A typical NAT44 does not translate them at all, so they need no rule. Plan for this separately, since it affects PPTP and any IPsec that is not using NAT traversal.

Treat telnet as a judgement call. TCP 23 and 2323 are how Mirai-style IoT botnets spread, and legitimate use across the public internet is close to zero, but some older business equipment still depends on it. It is a reasonable addition for a residential pool, and easy to add per group.

Block private destinations too

Port filtering gets the attention, but destinations matter just as much. A subscriber sending traffic to RFC 1918 space or to the RFC 6598 shared range (100.64.0.0/10) has no business reaching the public internet. If that traffic is translated, it uses a port and may leave your network with a public source address.

Blocking these ranges also stops subscribers probing each other's inside addresses. The catch is that many networks really do reach internal services over private space through the same path, such as resolvers, portals or provisioning systems. Audit that first. Turning this on without checking can cut subscribers off from something they depend on, which is why it is a separate decision from the port baseline and off by default in Netavo.

Configuring outbound blocks per IP group

In Netavo, the policy belongs to the CGN IP group, so a residential pool and a business pool can have different rules. Everything below applies on commit, with no restart.

The standard baseline is on by default, so a group needs no configuration to get the table above. Everything else is an addition or an exception:

set cgn ip-group resi outbound-block-private true
set cgn ip-group resi outbound-block-ports tcp/23
set cgn ip-group resi outbound-block-ports udp/5000-5010
set cgn ip-group resi outbound-block-prefixes 198.18.0.0/15
set cgn ip-group resi outbound-allow-prefixes 192.0.2.25/32

To turn the standard set off for a group, for example a pool you are testing:

set cgn ip-group resi outbound-block-standard false

The two built-in switches are fixed lists. To keep some standard ports but not others, turn the standard set off and list the ones you want in outbound-block-ports, or exempt the specific destination with an allow prefix.

Exempting your own mail relay

If you run a relay that customers must reach on port 25, don't weaken the block. Exempt only that host:

set cgn ip-group resi outbound-allow-prefixes 192.0.2.25/32

Allow and block prefixes are decided by the longest match, so a /32 allow inside a blocked /24 passes while the rest of the /24 stays refused. An allow prefix also passes every blocked port for that destination.

How the policy behaves

A few details are worth understanding before you roll this out:

• Blocks apply to live connections. A commit takes effect on flows already running, not only on new ones. In lab testing a running flow stopped within tens of milliseconds of the commit, without a restart or any session being dropped.
• Refused traffic costs almost nothing. The check runs before anything is allocated, so a device hammering port 25 does not use up its ports, flows or setup allowance. Established connections skip the check, so there is no per-packet cost on normal traffic.
• Blocks are silent. There is no ICMP error and no TCP reset. To the subscriber the connection simply times out, which is worth telling your support team.
• Replies are judged as well. A flow opened from the internet is checked on the subscriber's first packet back. So a spoofed inbound packet from port 25 of a real mail server cannot be used to open a path through the block.
• Bypass traffic is out of scope. Destinations listed in bypass-prefixes skip NAT, and they skip the policy too, because they never use the shared address. Use that for internal services, and an allow prefix for anything that still needs translating.
• Fragments are covered. The first fragment carries the port and is judged on it, and the remaining fragments of a refused datagram cannot get through.
• Restarts have a short gap. The policy is held in the data plane's own memory, so after a data-plane restart it is replayed by the control plane within about half a second. In testing only a handful of packets got through in that window.

Rolling it out without surprises

Blocking TCP 25 on an existing network will affect someone, however few. A careful rollout avoids most of the pain:

1. Measure first. Look at flow data for outbound port 25 and SMB. The volume tells you how much abuse you have and which business customers might notice.
2. Sort out exceptions. Find customers running real mail servers. They are better served by a dedicated public IPv4 than by a hole in the shared pool.
3. Start with one group. Apply the policy to a small pool, watch the counters and the helpdesk for a week, then widen it.
4. Brief the support team. Give them a short script: outbound port 25 is blocked on shared addresses, mail clients should use 587 or 465, and anyone running a mail server should talk to you about a dedicated address.
5. Publish it. State the policy in your terms or acceptable use documentation, so that it's not a surprise.

Check CGNAT testing practice for how to validate this properly. Test that blocked ports really are refused, that open ports still pass, and that the block survives a restart.

Monitoring the block

A block that nobody looks at is a missed signal. In Netavo, refused packets are counted under their own reason, cgn-blocked:

show dataplane drops all

A low, steady count is normal. A sudden climb usually means an infected device, and it is an early warning that arrives before the blocklist entry does. Because refusals are counted rather than logged per flow, follow up using your normal abuse process. Port-block attribution logging identifies which subscriber held a public address and port when an external abuse report arrives.

The block does not replace that process. Stopping the spam protects the address, but the device is still compromised, and the customer needs to be told.

What about IPv6?

These blocks are for IPv4 on shared addresses, and that is a deliberate scope. A subscriber's IPv6 prefix is theirs alone, so any reputation damage stays with that subscriber rather than spreading across a pool. That is one of the broader arguments for moving traffic to IPv6. You may still choose to filter some IPv6 traffic under your own security policy, but the case for it is different.

Try it on your own traffic

The best way to set a policy is to test it against real subscribers and a real pool. Start a Netavo evaluation, read how the CGNAT platform fits into a deployment, or see the documentation for the full list of configuration keys.

FAQ

Should an ISP block outbound port 25 on CGNAT?

Yes. Port 25 is for mail servers talking to each other, and ordinary subscribers submit mail on port 587 or 465 instead. On a shared address, one infected device sending spam can get the IP blacklisted for everyone using it, so blocking TCP 25 is the most valuable single rule on a CGNAT pool.

Which ports should be blocked on CGNAT by default?

A sensible baseline is TCP 25, TCP and UDP 135, UDP 137 and 138, TCP 139, and TCP and UDP 445. That covers SMTP and the Windows RPC, NetBIOS and SMB ports. Keep the list short, because every extra port is a potential support ticket.

Will blocking port 25 stop customers sending email?

Not for normal mail clients, which submit through their provider on port 587 or 465. It affects devices connecting straight to other mail servers, which is what spam malware does, and customers running their own mail servers, who should move to a dedicated public IPv4.

Should CGNAT subscribers be able to reach private IP addresses?

Generally not through a shared public address, so blocking RFC 1918 and RFC 6598 destinations is good practice. Check first whether subscribers reach internal services such as resolvers or portals that way. Those can be exempted with a bypass or allow prefix.

Do outbound blocks apply to IPv6?

Not normally for this purpose. The reason for blocking is shared reputation, and an IPv6 prefix belongs to one subscriber. You may still filter IPv6 under your wider security policy.

Does blocking ports slow down a CGNAT?

It shouldn't. On Netavo the check runs when a new flow is set up, and established connections skip it, so normal traffic pays no per-packet cost and refused packets use no ports.