Giga Hub 2.0: PPPoE passthrough/2nd PPPoE session capped (average 330 Mbps) on 3 Gbps plan

[Velaris]

Hello,

I'm on a 3 Gbps plan and I'm seeing a repeatable/hard throughput cap only when using PPPoE on a downstream device (PPPoE passthrough / second session).

My setup:

- Bell Giga Hub 2.0
- Downstream router: UniFi Cloud Gateway Fiber (UCG-Fiber) connected to the Giga Hub 10G port

What works:

- If the UCG-Fiber WAN is set to DHCP (e.g. behind the Giga Hub 2.0/double NAT), I can reach full speed (~3 Gbps).
- If my PC is behind the Giga Hub 2.0 on DHCP, my PC (1GbE NIC) reaches the expected ~1 Gbps.

The problem (reproducible):

When I establish a PPPoE session from a device behind the Giga Hub, throughput is capped around ~300–330 Mbps.

Repro 1: PPPoE from UCG-Fiber

- UCG-Fiber WAN set to PPPoE using my b1 credentials
- Result: ~300–330 Mbps (repeatable), despite 3 Gbps plan

Repro 2: PPPoE from a Windows PC (bypassing UCG-Fiber)

- PC connected by Ethernet to the Giga Hub 2.0
- PC NIC: 1GbE, cable: Cat6A
- Created a Windows "Broadband (PPPoE)" connection using the same b1 credentials
- Result: same cap at ~300–330 Mbps (repeatable)

Because the same cap occurs even when PPPoE is established directly from a PC (*no* UniFi router involved), it points to the Giga Hub 2.0 PPPoE passthrough / secondary PPPoE session path rather than my router.

Can you confirm:

- Is this a known issue on the Giga Hub 2.0 (firmware-related)?
- Is there a firmware update or hardware replacement option to resolve PPPoE passthrough speed caps?

Thanks

[ScratchMang]

Has anyone seen this Firmware updated? Bell support is completely unaware of it and of course you cannot get past the first line of tech support people to talk to anyone who may actually know what's a firmware update is.

[dg6464]

Not yet, still 3.11.6.2... I've swapped to Advanced DMZ and have not had any issues with it thus far... but will still be switching back to normal once 3.11.6.3 is updated on my modem.

[ScratchMang]

That's interesting information indeed. How long have you been using the Advanced DMZ? Have you setup anything special to keep it stable or just let it do it's thing?

[dg6464]

Yeah, scratch that... ADMZ is not stable and completely broke today.

I'm still on 3.11.6.2 firmware and am experiencing the disconnects every 600 seconds using ADMZ, which is happening regardless what I try.

I got no call back from Bell Level 2 Support and am getting frustrated with this issue.

Really in need of my modem being upgraded to 3.11.6.3 firmware... I didn't notice the 600 second DHCP renewal outages until I got back to work and was on Zoom calls having them freeze every 10 minutes and have VPN constantly disconnecting/reconnecting.

Also, as an FYI to the Bell folks monitoring this thread... when the modem is put into Advanced DMZ mode... the leases just don't refresh properly at the half-way mark. There's something wrong with the Gigahub's DHCP implementation where it doesn't answer to provide a refresh before the DHCP expires... causing a 2-3 second tear down and bring-up of the connection.

ADMZ DHCP behavior appears to be severely broken/opaque: the downstream router receives a public WAN IP with a private 10.x gateway, a /1 subnet mask, and an extremely short 600-second lease, while DHCP renew/rebind behavior is inconsistent or non-responsive. The Bell gateway also appears to retain stale internal configuration (for example advertising itself as 192.168.2.1 after being changed to 192.168.3.1), suggesting the ADMZ implementation is not a true bridge and may leave stale routing/DHCP state in the firmware.

Double-NAT via DHCP to the Bell modem works, but breaks gaming and isn't a proper workaround.

Fix this now please, it's getting ridiculous... or maybe... communicate what the timeline is to your frustrated customers.

[Vanadiel]

You could try a static IP on the downstream router and use the downstream DHCP server for the LAN side. You should not need DHCP to establish PPPOE connectivity.

[dg6464]

That is a good call — I did try the static IP approach during the ADMZ troubleshooting. I agree DHCP should not be required for PPPoE connectivity, and I tested various static WAN configurations while keeping DHCP on the LAN side, but the ADMZ 600-second renewal issue remained.

I also tried adjusting lease behaviour/lifetimes and several other ADMZ workarounds. The behaviour itself was very strange: the downstream router would receive a public IP with a private 10.x gateway and a /1 mask, but DHCP renewals would not consistently respond before expiry, causing brief 2–3 second disconnects every 10 minutes. The Bell gateway also continued advertising itself as its factory DHCP address (192.168.2.1) even after changing the LAN IP to 192.168.3.1 and rebooting.

I then attempted moving back to PPPoE. The session authenticates correctly and OPNsense receives a public IP, so PPPoE negotiation appears successful. However, traffic afterwards is very odd — DNS and ping work, some TCP connections establish, but normal web browsing/payload traffic stalls. I factory reset both the Bell Hub and OPNsense and restored a known-good configuration with the same result.

For context, PPPoE had been working for years until recently. The original issue was degraded speeds, which led me to try ADMZ. ADMZ initially appeared better, but the DHCP renewal issue made it unusable. Moving back to PPPoE now results in a different failure mode where clients cannot reliably establish normal web sessions.

I have temporarily moved to straight DHCP behind the Bell Hub, with OPNsense reserved as a DHCP device and configured as the DMZ host using Standard DMZ (not Advanced DMZ and not individual port forwards). External services are working again, and Xbox/Nintendo connectivity is also functioning correctly.

This will be my temporary setup until I move to my planned long-term solution.

[vscenic]

I’ve been using ADMZ for ever without any problems until on July 4th 2026 my GigaHub was updated to firmware 3.11.6.2.

From that moment on, Teams calls and VPN connections to work started disconnecting, latency and jitter went through the roof.

I tried connecting through PPPoE to see if that would make a difference. It did, latency and jitter came back to normal, Teams and VPN stopped disconnecting. But the throughput of my 3Gb plan came down to 300Mb down and 450Mb up, not good.

Hopefully I will receive the new firmware update soon. Accepting a service downgrade, for the full price, to be able to work from home is not a long-term solution.

[yokushka]

3.11.6.2 - still the same issue:
- PPPoE is capped to about 400Mbps - more or less stable
- DMZ/Double NAT modes - packages dropped ocasionaly

[MrCaspan]

This is because of a DHCP "bug" when using aDMZ. What happens is the Giga Hub gives your first device the public IP address that bell would have given the hub and then acts almost like a proxy after that. The hub provides this information to your first device VIA DHCP and it acts as a DHCP server. This then turns the hub into an ONT with no public IP address its just a PPPoE endpoint. The lease given by the hub is set to 10 minutes (very short for some reason) halfway through that lease your hardware IS SUPPOSED TO ask to renew this lease and will ask 192.168.2.1 as this is who gave it the DHCP lease. This is the way DHCP works but the "bug" in the hub firmware is that it does hear the request from your hardware that it wants to renew it BUT the request is never answered. but the hub thinks it did answer it. As the lease continues to expire your device continues to ask for a renewal over and over as the lease starts to expire until it's so close to expiring your hardware starts shouting (Broadcasting) that it needs a renewal to any device that will listen but the Hub still never responds. Your lease ends and your hardware releases the IP address (as it should) and broadcasts that it's looking for an new lease again. The Bell hub answers and gives out normally the same IP address again with a 10 minute lease. the cycle repeats every 10 minutes exactly and your internet goes down for about ~10 seconds every time this dance happens. 

Also please note that the Giga Hub in aDMZ modes will still keep its internal network which by default is 192.168.2.0/24 and the hub uses 192.168.2.1 so make sure NOTHING in your network overlaps this network range or else the wrong device will receive the renewal requests...

Talking to a Level 3 Tech that was talking to a networking engineer yesterday. There is a firmware fix being pushed out to fix this DHCP bug that will allow you to use aDMZ properly and stop using PPPoE pass through 

I did a whole write up here https://forum.bell.ca/t5/internet/running-a-bell-giga-hub-with-your-own-hardware-behind-it-fix/td-p/...

I hope this helps others!

[vscenic]

Thank you for the reply MrCaspan.

By the way, not using the 192.168.2.0/24 subnet.

Hopefully, the fix will be pushed soon.

[ScratchMang]

It took a while to figure out, but it is possible to make ADMZ work properly, at full speed, without network drops or re-connections. But you need a higher level of router than what you can purchase off the shelf at Best Buy. 

No special hardware required, but a deep understanding of network topology and routing is an asset.

[MrCaspan]

Show how did you do this did you just overwrite Lease times because this is a know bug in V1 & V2 of the hub? or did you just set a static IP address? I have deep understanding of networking just FYI do this for a living so feel free to be detailed 🙂

[ScratchMang]

As do I 🙂

PM Sent, let's take this offline.

[dks]

---

@ScratchMang wrote:

It took a while to figure out, but it is possible to make ADMZ work properly, at full speed, without network drops or re-connections. But you need a higher level of router than what you can purchase off the shelf at Best Buy. 

No special hardware required, but a deep understanding of network topology and routing is an asset.

---

This is a core truth. 99% of Bell's customers do not have a deep understanding of network topology, routing and other networking issues. They want a plug and play solution. To expect a different level of service and concomitant support is not realistic in Bell's service model. There have been such services offered in the past, but they are known mostly by word of mouth, if they even still exist. The closest might be eBox, which is owned by Bell. 

[ScratchMang]

I agree that 99% of Bell customers want a plug-and-play solution and have no interest in advanced networking. I am not suggesting that front-line support should walk every customer through custom routing configurations.

The fact remains that working solutions exist for power users who want to use Bell’s service with their own networking hardware while maintaining full control and privacy over their internal networks.

Bell provides Advanced DMZ as a feature, yet offers very little technical documentation explaining how it operates. Even basic information about its unconventional WAN address, gateway and DHCP topology would save knowledgeable customers countless hours of troubleshooting.

Power users are not asking Bell to configure our equipment. We are asking Bell to document its own implementation so that those with the prerequisite knowledge can configure their equipment correctly. These configurations understandably fall outside the scope and technical beyond the level of knowledge of standard consumer support and the Community All-Stars.

In the absence of documentation, the power-user community has had to determine how Bell’s implementation works, why certain routers repeatedly lose connectivity and which routing changes are required to make the connection stable.

These are not hacks. They are proper networking solutions using established routing methods. Through considerable testing and collaboration, working configurations have been developed for platforms including OPNsense, pfSense, Linux and UniFi.

I have now had Advanced DMZ operating at full speed without drops or reconnections for several weeks. If anyone else is trying to accomplish the same thing, feel free to reach out and I will gladly share what I have learned.

Please understand that these solutions generally require a capable router or firewall. Most consumer routers sold off the shelf at Best Buy or Staples do not expose the necessary options. Unless you are comfortable administering a platform such as OPNsense, pfSense, Linux or UniFi, I may not be able to provide meaningful assistance.