Why does Afrihost’s default CGNAT profile break Metrofibre lines? (And why is front-line support blind to it?)

A

Assasin_Zer0

Senior Member
Joined
Jun 28, 2010
Messages
572
Reaction score
140
Location
The Void
Hi everyone,


I am looking for feedback from the community, network engineers, or an Afrihost network representative regarding a highly specific technical issue I experience on my Metrofibre (MFN) line, alongside the absolute nightmare it takes to get it resolved through standard support channels.
Every time the WAN MAC address on my primary router (a UniFi Cloud Gateway Ultra) changes—which happens when I rotate MAC addresses for security—my connection gets placed back onto Afrihost's default IP assignment profile. When this happens, a predictable set of severe network issues occurs:
  • The connection begins to flap and drop randomly (ranging from a few seconds to a few minutes). This happens non-stop over a full 24-hour period until manual changes from Afrihost are made.
  • Download speeds completely tank, dropping my 1Gbps line down to sub-50 Mbps.
  • The line experiences severe packet loss, massive latency spikes, and horrible streaming performance with constant buffering.
  • The line remains completely unstable until an Afrihost rep manually "maps" the line on the backend and forces it onto a dedicated Public IP profile.
Ticket Reference for Afrihost Reps: ZSO-176-38142

The Definitive Proof:
I have benchmarked this repeatedly and have conclusive evidence that my local hardware is not the problem:
  • On the 102.X.X.X range (Public IP Profile): I am currently sitting on this profile, and the line has been 100% perfect for several days straight. I get full, glorious Gigabit speeds, low latency, zero packet loss, and flawless streaming.
  • On the 100.X.X.X range (Default CGNAT Profile): The moment my MAC changes and I drop into this pool, the connection starts flapping non-stop, latency spikes, packets drop, and the speed immediately chokes down to under 50 Mbps within the first 30 minutes.
No hardware changes, no cable adjustments—just a pure IP profile change completely breaks or fixes the line.

The Support Nightmare: Trapped in First-Line Scripts
Dealing with first-line or basic support to get this resolved is an incredibly horrible experience:
  • The 6-Hour Loop: Just going through their mandatory, generic troubleshooting steps takes anywhere from 3 to 6 hours before an agent will even consider logging a ticket.
  • The Blame Game: Front-line agents completely fail to understand the issue. Because the drops are intermittent, their basic tests usually result in them claiming it is a "client hardware fault." [1]
  • The R800 Threat: Instead of escalating the issue, they try to push a Metrofibre technician site visit on you, which comes with a threatened R600 to R800 call-out fee—even though I know for a fact that my hardware is perfect and a simple backend mapping will fix it instantly.
  • The Escalation Wall: It is impossible to get through to the NOC (Network Operations Centre) or a senior engineer from the call centre or standard chatbots.
The only reason this has ever been resolved is by bypassing standard support entirely and reaching out directly to the Afrihost forum rep, Afrigirl. She is the only one who understands the issue and manages to get the NOC team to make the changes. But because her inbox is completely flooded, a fix that takes two minutes on the backend can take anywhere from a few hours to several days of waiting.

The Core Technical Questions:
I want to understand the exact root cause behind this infrastructure behavior:
  1. CGNAT Gateway Overload: On the default profile, I am assigned an IP in the CGNAT 100.X.X.X range. Are these shared gateways in the Centurion/Gauteng region suffering from severe oversubscription? Moving from 1000 Mbps to 50 Mbps with massive packet loss strongly suggests the gateway hardware chokes entirely during peak processing.
  2. NAT Session Table Exhaustion: Advanced gateways like UniFi create thousands of concurrent connection states. When my MAC changes, the aggressive port-allocation limits on the CGNAT box seem to cause random drops, as the upstream gateway kills active sessions to free up space.
  3. State Sync Failures: After a local Metrofibre OLT reset, the sudden flood of re-authentications breaks the sticky routing state for any newly rotated MAC addresses, trapping the line in a broken loop until a manual profile mapping is pushed.

My Questions to the Community & Afrihost Techs:
  • Why is the default shared pool environment so unstable that a standard line becomes unusable without a dedicated Public IP profile workaround?
  • Since the network handles authentication via DHCP, why can't Afrihost permanently lock a service domain ([email protected]) to a Public IP profile so that it persists regardless of a WAN MAC change?
  • How do other advanced users bypass the 6-hour front-line script wall to get an obvious routing/mapping request straight to the NOC?
I would love to hear if other users with custom routing setups face this same performance drop on the default pool, and how you deal with the support barrier.


Looking forward to some advice here .

@Afrigirl @AfriGuy @AfriNatic
 
Last edited:
Hi.
Afrihost Fibre on DHCP authenticates clients by mapping the router's WAN MAC address to the username linked to the Fibre service on our RADIUS platform. When the WAN MAC changes, our systems recognise it as a different device until the new MAC address is mapped. This is expected behaviour on our DHCP platform.

Since the Fibre service is already provisioned on the FNO's network, any device connected to the ONT can obtain an IP address via DHCP. We use the MAC mapping process to associate that device with your Afrihost account, allowing us to identify the correct service, apply the appropriate profile, and provide features such as usage reporting.
By default, clients may be assigned a CGNAT IP address. If a public IP is required for services such as CCTV, VPNs, gaming, self-hosted services, or due to compatibility issues, we can remove the CGNAT assignment upon request.

Regarding the technical theories you've raised, we cannot confirm that the behavior is caused by overloaded CGNAT gateways or state synchronisation issues. Likewise, we cannot conclude that the 100.x.x.x CGNAT range is inherently slower than the public IP range, as many clients use CGNAT without experiencing throughput or stability issues.

Our CGNAT infrastructure is also monitored and maintained regularly. We receive alerts when capacity thresholds are reached, allowing our teams to investigate and resolve any capacity-related issues as quickly as possible to maintain a stable experience for clients.

Based on how our platform operates, changing the router's WAN MAC address may require the new device to be mapped before the service functions as expected, as the mapping is tied to the WAN MAC rather than the IP address.
 
Hi @Afrigirl,


Thanks for the clear explanation of how your RADIUS setup works! It makes sense that a rotated WAN MAC address looks like a brand-new device on your backend and automatically pulls down the default profile.

The problem I am facing is that I rotate my WAN MAC for security reasons on my UniFi gateway, and every time I do, the line completely falls apart on that default pool. I really want to find a way to stop this from happening, so I’m looking for some help and advice from you or the technical team on how I can resolve this.

1. Is there anything I can change or configure on my side to make the standard pool (100.x.x.x) stable?

On my side dropping into that default pool causes an immediate drop in performance. My 1Gbps line chokes down to under 50 Mbps, packets start dropping, and the connection flaps non-stop.
The second you move me to a public 102.x.x.x IP, it goes back to being 100% perfect. Either way, the long and short of it—and I'm honestly not sure why—is that getting a 100.x.x.x IP breaks my setup, and getting a 102.x.x.x IP seems to work flawlessly.

I want to know if there is a workaround or setting I can apply on my own hardware to fix this. Please note that I have already tried tweaking some of these settings on my side, but none of them worked—unless I am using the incorrect values. I would appreciate your guidance on the specifics:
  • Do I need to change my MTU or MSS clamping settings on my UniFi WAN port so it plays nice with your CGNAT routing? If so, what are the exact values I should use?
  • Are there any specific DHCP options I should be sending when the router authenticates?
2. If I can't fix it on my end, what is the best way to get back onto a public IP without the support nightmare?

Since rotating my MAC resets my profile on your RADIUS server, I get stuck in the default pool. Trying to get this sorted through standard support or the WhatsApp chatbot is incredibly frustrating. I always get trapped in a 3 - 4 hour loop of generic troubleshooting scripts and get threatened with an R800 MetroFibre call-out fee for a problem we both know is just a RADIUS mapping profile issue.

Is there a quicker, less painful escalation channel I can use to ask for the profile swap without having to jump through first-line support scripts or spamming your forum inbox?

Any tips or technical advice on what I can do to fix this would be massively appreciated!

 
Afrigirl said:
If a public IP is required for services such as CCTV, VPNs, gaming, self-hosted services, or due to compatibility issues, we can remove the CGNAT assignment upon request.
Click to expand...
Is it possible to get a static public IP on MFN with Afrihost?
 
Assasin_Zer0 said:
Hi @Afrigirl,


Thanks for the clear explanation of how your RADIUS setup works! It makes sense that a rotated WAN MAC address looks like a brand-new device on your backend and automatically pulls down the default profile.

The problem I am facing is that I rotate my WAN MAC for security reasons on my UniFi gateway, and every time I do, the line completely falls apart on that default pool. I really want to find a way to stop this from happening, so I’m looking for some help and advice from you or the technical team on how I can resolve this.

1. Is there anything I can change or configure on my side to make the standard pool (100.x.x.x) stable?

On my side dropping into that default pool causes an immediate drop in performance. My 1Gbps line chokes down to under 50 Mbps, packets start dropping, and the connection flaps non-stop.
The second you move me to a public 102.x.x.x IP, it goes back to being 100% perfect. Either way, the long and short of it—and I'm honestly not sure why—is that getting a 100.x.x.x IP breaks my setup, and getting a 102.x.x.x IP seems to work flawlessly.

I want to know if there is a workaround or setting I can apply on my own hardware to fix this. Please note that I have already tried tweaking some of these settings on my side, but none of them worked—unless I am using the incorrect values. I would appreciate your guidance on the specifics:
  • Do I need to change my MTU or MSS clamping settings on my UniFi WAN port so it plays nice with your CGNAT routing? If so, what are the exact values I should use?
  • Are there any specific DHCP options I should be sending when the router authenticates?
2. If I can't fix it on my end, what is the best way to get back onto a public IP without the support nightmare?

Since rotating my MAC resets my profile on your RADIUS server, I get stuck in the default pool. Trying to get this sorted through standard support or the WhatsApp chatbot is incredibly frustrating. I always get trapped in a 3 - 4 hour loop of generic troubleshooting scripts and get threatened with an R800 MetroFibre call-out fee for a problem we both know is just a RADIUS mapping profile issue.

Is there a quicker, less painful escalation channel I can use to ask for the profile swap without having to jump through first-line support scripts or spamming your forum inbox?

Any tips or technical advice on what I can do to fix this would be massively appreciated!

Click to expand...

Our DHCP platform doesn't require any specific MTU, MSS, or DHCP settings, so there aren't any router configuration changes I would recommend making.

We also don't currently offer static IP addresses on MetroFibre services.
Considering the extensive testing you've already done, I'd like to explore an alternative connection method with you as part of our troubleshooting. While this isn't an officially supported option or one that's generally available, it may help us isolate the issue you're experiencing.

I'll send you a private message with a few more details.
 
Afrigirl said:
Our DHCP platform doesn't require any specific MTU, MSS, or DHCP settings, so there aren't any router configuration changes I would recommend making.

We also don't currently offer static IP addresses on MetroFibre services.
Considering the extensive testing you've already done, I'd like to explore an alternative connection method with you as part of our troubleshooting. While this isn't an officially supported option or one that's generally available, it may help us isolate the issue you're experiencing.

I'll send you a private message with a few more details.
Click to expand...
Thank you !
 
Assasin_Zer0 said:
Hi everyone,


I am looking for feedback from the community, network engineers, or an Afrihost network representative regarding a highly specific technical issue I experience on my Metrofibre (MFN) line, alongside the absolute nightmare it takes to get it resolved through standard support channels.
Every time the WAN MAC address on my primary router (a UniFi Cloud Gateway Ultra) changes—which happens when I rotate MAC addresses for security—my connection gets placed back onto Afrihost's default IP assignment profile. When this happens, a predictable set of severe network issues occurs:
  • The connection begins to flap and drop randomly (ranging from a few seconds to a few minutes). This happens non-stop over a full 24-hour period until manual changes from Afrihost are made.
  • Download speeds completely tank, dropping my 1Gbps line down to sub-50 Mbps.
  • The line experiences severe packet loss, massive latency spikes, and horrible streaming performance with constant buffering.
  • The line remains completely unstable until an Afrihost rep manually "maps" the line on the backend and forces it onto a dedicated Public IP profile.
Ticket Reference for Afrihost Reps: ZSO-176-38142

The Definitive Proof:
I have benchmarked this repeatedly and have conclusive evidence that my local hardware is not the problem:
  • On the 102.X.X.X range (Public IP Profile): I am currently sitting on this profile, and the line has been 100% perfect for several days straight. I get full, glorious Gigabit speeds, low latency, zero packet loss, and flawless streaming.
  • On the 100.X.X.X range (Default CGNAT Profile): The moment my MAC changes and I drop into this pool, the connection starts flapping non-stop, latency spikes, packets drop, and the speed immediately chokes down to under 50 Mbps within the first 30 minutes.
No hardware changes, no cable adjustments—just a pure IP profile change completely breaks or fixes the line.

The Support Nightmare: Trapped in First-Line Scripts
Dealing with first-line or basic support to get this resolved is an incredibly horrible experience:
  • The 6-Hour Loop: Just going through their mandatory, generic troubleshooting steps takes anywhere from 3 to 6 hours before an agent will even consider logging a ticket.
  • The Blame Game: Front-line agents completely fail to understand the issue. Because the drops are intermittent, their basic tests usually result in them claiming it is a "client hardware fault." [1]
  • The R800 Threat: Instead of escalating the issue, they try to push a Metrofibre technician site visit on you, which comes with a threatened R600 to R800 call-out fee—even though I know for a fact that my hardware is perfect and a simple backend mapping will fix it instantly.
  • The Escalation Wall: It is impossible to get through to the NOC (Network Operations Centre) or a senior engineer from the call centre or standard chatbots.
The only reason this has ever been resolved is by bypassing standard support entirely and reaching out directly to the Afrihost forum rep, Afrigirl. She is the only one who understands the issue and manages to get the NOC team to make the changes. But because her inbox is completely flooded, a fix that takes two minutes on the backend can take anywhere from a few hours to several days of waiting.

The Core Technical Questions:
I want to understand the exact root cause behind this infrastructure behavior:
  1. CGNAT Gateway Overload: On the default profile, I am assigned an IP in the CGNAT 100.X.X.X range. Are these shared gateways in the Centurion/Gauteng region suffering from severe oversubscription? Moving from 1000 Mbps to 50 Mbps with massive packet loss strongly suggests the gateway hardware chokes entirely during peak processing.
  2. NAT Session Table Exhaustion: Advanced gateways like UniFi create thousands of concurrent connection states. When my MAC changes, the aggressive port-allocation limits on the CGNAT box seem to cause random drops, as the upstream gateway kills active sessions to free up space.
  3. State Sync Failures: After a local Metrofibre OLT reset, the sudden flood of re-authentications breaks the sticky routing state for any newly rotated MAC addresses, trapping the line in a broken loop until a manual profile mapping is pushed.

My Questions to the Community & Afrihost Techs:
  • Why is the default shared pool environment so unstable that a standard line becomes unusable without a dedicated Public IP profile workaround?
  • Since the network handles authentication via DHCP, why can't Afrihost permanently lock a service domain ([email protected]) to a Public IP profile so that it persists regardless of a WAN MAC change?
  • How do other advanced users bypass the 6-hour front-line script wall to get an obvious routing/mapping request straight to the NOC?
I would love to hear if other users with custom routing setups face this same performance drop on the default pool, and how you deal with the support barrier.


Looking forward to some advice here .

@Afrigirl @AfriGuy @AfriNatic
Click to expand...
When I had Afrihost on MetroFibre, I used PPPoE authentication instead of DHCP. Think that should fix the issue you are having?
 
Assasin_Zer0 said:
Had a Similar thought,

Will need to check if the Vlan is PPPoE Enabled .
Click to expand...
Cool, on my line I could switch what I wanted to use, DHCP or PPPOE. When I wanted to use PPPOE, I logged into my client zone & used the [email protected] as the username & reset the password under access details & used that as the password, & the line would dial using the PPPOE setting in the router.

If that makes sense :ROFL:
 
Chris_Auc said:
Cool, on my line I could switch what I wanted to use, DHCP or PPPOE. When I wanted to use PPPOE, I logged into my client zone & used the [email protected] as the username & reset the password under access details & used that as the password, & the line would dial using the PPPOE setting in the router.

If that makes sense :ROFL:
Click to expand...
Makes 100% Sense ,

I did try , but not getting an Ip , i think this is not something that is enabled by default . Hence id need to check with them if that vlan or my account allows for it .
 
Assasin_Zer0 said:
Hi everyone,


I am looking for feedback from the community, network engineers, or an Afrihost network representative regarding a highly specific technical issue I experience on my Metrofibre (MFN) line, alongside the absolute nightmare it takes to get it resolved through standard support channels.
Every time the WAN MAC address on my primary router (a UniFi Cloud Gateway Ultra) changes—which happens when I rotate MAC addresses for security—my connection gets placed back onto Afrihost's default IP assignment profile. When this happens, a predictable set of severe network issues occurs:
  • The connection begins to flap and drop randomly (ranging from a few seconds to a few minutes). This happens non-stop over a full 24-hour period until manual changes from Afrihost are made.
  • Download speeds completely tank, dropping my 1Gbps line down to sub-50 Mbps.
  • The line experiences severe packet loss, massive latency spikes, and horrible streaming performance with constant buffering.
  • The line remains completely unstable until an Afrihost rep manually "maps" the line on the backend and forces it onto a dedicated Public IP profile.
Ticket Reference for Afrihost Reps: ZSO-176-38142

The Definitive Proof:
I have benchmarked this repeatedly and have conclusive evidence that my local hardware is not the problem:
  • On the 102.X.X.X range (Public IP Profile): I am currently sitting on this profile, and the line has been 100% perfect for several days straight. I get full, glorious Gigabit speeds, low latency, zero packet loss, and flawless streaming.
  • On the 100.X.X.X range (Default CGNAT Profile): The moment my MAC changes and I drop into this pool, the connection starts flapping non-stop, latency spikes, packets drop, and the speed immediately chokes down to under 50 Mbps within the first 30 minutes.
No hardware changes, no cable adjustments—just a pure IP profile change completely breaks or fixes the line.

The Support Nightmare: Trapped in First-Line Scripts
Dealing with first-line or basic support to get this resolved is an incredibly horrible experience:
  • The 6-Hour Loop: Just going through their mandatory, generic troubleshooting steps takes anywhere from 3 to 6 hours before an agent will even consider logging a ticket.
  • The Blame Game: Front-line agents completely fail to understand the issue. Because the drops are intermittent, their basic tests usually result in them claiming it is a "client hardware fault." [1]
  • The R800 Threat: Instead of escalating the issue, they try to push a Metrofibre technician site visit on you, which comes with a threatened R600 to R800 call-out fee—even though I know for a fact that my hardware is perfect and a simple backend mapping will fix it instantly.
  • The Escalation Wall: It is impossible to get through to the NOC (Network Operations Centre) or a senior engineer from the call centre or standard chatbots.
The only reason this has ever been resolved is by bypassing standard support entirely and reaching out directly to the Afrihost forum rep, Afrigirl. She is the only one who understands the issue and manages to get the NOC team to make the changes. But because her inbox is completely flooded, a fix that takes two minutes on the backend can take anywhere from a few hours to several days of waiting.

The Core Technical Questions:
I want to understand the exact root cause behind this infrastructure behavior:
  1. CGNAT Gateway Overload: On the default profile, I am assigned an IP in the CGNAT 100.X.X.X range. Are these shared gateways in the Centurion/Gauteng region suffering from severe oversubscription? Moving from 1000 Mbps to 50 Mbps with massive packet loss strongly suggests the gateway hardware chokes entirely during peak processing.
  2. NAT Session Table Exhaustion: Advanced gateways like UniFi create thousands of concurrent connection states. When my MAC changes, the aggressive port-allocation limits on the CGNAT box seem to cause random drops, as the upstream gateway kills active sessions to free up space.
  3. State Sync Failures: After a local Metrofibre OLT reset, the sudden flood of re-authentications breaks the sticky routing state for any newly rotated MAC addresses, trapping the line in a broken loop until a manual profile mapping is pushed.

My Questions to the Community & Afrihost Techs:
  • Why is the default shared pool environment so unstable that a standard line becomes unusable without a dedicated Public IP profile workaround?
  • Since the network handles authentication via DHCP, why can't Afrihost permanently lock a service domain ([email protected]) to a Public IP profile so that it persists regardless of a WAN MAC change?
  • How do other advanced users bypass the 6-hour front-line script wall to get an obvious routing/mapping request straight to the NOC?
I would love to hear if other users with custom routing setups face this same performance drop on the default pool, and how you deal with the support barrier.


Looking forward to some advice here .

@Afrigirl @AfriGuy @AfriNatic
Click to expand...
Is this written by Gemini?
 
Afrigirl said:
Hi.
Afrihost Fibre on DHCP authenticates clients by mapping the router's WAN MAC address to the username linked to the Fibre service on our RADIUS platform. When the WAN MAC changes, our systems recognise it as a different device until the new MAC address is mapped. This is expected behaviour on our DHCP platform.

Since the Fibre service is already provisioned on the FNO's network, any device connected to the ONT can obtain an IP address via DHCP. We use the MAC mapping process to associate that device with your Afrihost account, allowing us to identify the correct service, apply the appropriate profile, and provide features such as usage reporting.
By default, clients may be assigned a CGNAT IP address. If a public IP is required for services such as CCTV, VPNs, gaming, self-hosted services, or due to compatibility issues, we can remove the CGNAT assignment upon request.

Regarding the technical theories you've raised, we cannot confirm that the behavior is caused by overloaded CGNAT gateways or state synchronisation issues. Likewise, we cannot conclude that the 100.x.x.x CGNAT range is inherently slower than the public IP range, as many clients use CGNAT without experiencing throughput or stability issues.

Our CGNAT infrastructure is also monitored and maintained regularly. We receive alerts when capacity thresholds are reached, allowing our teams to investigate and resolve any capacity-related issues as quickly as possible to maintain a stable experience for clients.

Based on how our platform operates, changing the router's WAN MAC address may require the new device to be mapped before the service functions as expected, as the mapping is tied to the WAN MAC rather than the IP address.
Click to expand...
Wait we can just...ask you to give us a fixed IP.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X