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

[Maddjik]

3 Gbps

[Maddjik]

This is my setup and it works just fine. OPNsense firewall using PPPoE creds.

[Vanadiel]

The forum Community Guidelines are accessible from the top side section on the right of the forum under "getting started".

Here's a direct link. 

[Vanadiel]

You might want to check for firmware version 3.11.6.3. That is new firmware being rolled out that according to user feedback resolved their PPPOE connectivity issues.

[dg6464]

No, only having a Level 2 Advanced Tech Support person manually add you to the early rollout group, or push it to your modem likely at this point unless your modem happens to be in the first rollout group lot of 3.11.6.3.

I called Bell last night and am waiting on a Level 2 Tech to call me back as "none were available at this time" (fair, it was between 10-11pm).

This has been the timing on my modem of previous firmware updates, which are NOT OFTEN, so I am hoping Bell rolls this out quicker than most previous updates in the past (happening ~1 time per year, around November-December), except this last 3.11.6.2 in May (based on Gigahub 1.0 Logs):

• May 20, 2026 04:25:13 → Bell ACS/TR-069 pushed firmware 3.11.6.2.
• 2025-11-04 04:24:44–04:25:17 firmware update
• 2024-12-13 02:43:39 firmware update
• 2023-12-07 02:50:55–02:51:25 firmware update

Here's hoping Level 2 calls me back today, as Level 1 just doesn't know much about the networking world and is trained not to go off script for that reason. I was told "your modem is running the latest 3.11.6.2 firmware and is in a working state, there is no 3.11.6.3 firmware version that I can see available".

I ran a "Reset Bell Settings" from the modem to no avail.

I ran a "Factory Reset" from the GUI to no avail (it set the modem admin password to something other than what I had set and something other than the modem Serial# on the back).

I ran a "Factory Reset" by holding the button on the side of the Gigahub 1.0 for longer than the period that the screen says it's going to reset... (I held it until the screen turned off and it fully rebooted). Then the admin password was set back to the Serial# of the modem... however the issue still persisted and no 3.11.6.3 firmware was pushed, so my modem clearly isn't in the queue for rollout.

However, the Factory Resets fixed some issues of other services not showing as available on the modem (I don't use Phone or TV anyway, but they showed as working after resetting). Also... the "Speedtest" function both on the modem main panel and in the Bell Gigahub GUI was also not functioning previously... but now is working properly.

So I am hoping the Factory Reset will allow for more stable usege of Advanced DMZ than I have experience in the past (used to be "Flaky").

Will report of any major issues as I've now swapped OPNsense from PPPoE passthrough (being limited to 300-450Mbps) to Advanced DMZ (seeing full speeds).

I also verified the Double-NAT scenario (essentially just getting DHCP from the Bell modem on your Router/Firewalls WAN) provides full speeds. 

Both Double-NAT and Advanced DMZ are the same configuration on your Router/Firewall (WAN DHCP), but Advanced DMZ shares the Public IP that the modem gets directly with the Router/Firewall's WAN DHCP. You just need to get it configured properly and probably benefit from a Factory Reset beforehand to clear any other long-term modem quirks after years of firmware updates importing and re-importing older config files.

On Advanced DMZ; experiences differ based on your chosen Router/Firewall platform... because many implement DHCP leasing, Spanning Tree (STP/RSTP), Flow Control, other discovery protocols (LLDP, etc) very differently and will interact with the Advanced DMZ function in their own way (poor, mediocre or fine).

Two things I noticed after Factory Reset as well... the GUI speed was much better, as well as IPv6 showing as a toggle on the Gighub "Advanced tools and settings" under "Networking". I'm not sure if it was there before or functioning; I have not verified if it's actually being used in practice on the WAN, or just offering IPv6 leases internally to clients.

[dg6464]

It is worth noting... that I got here after days of troubleshooting OPNsense (using multiple hardware platforms, different 10G NIC's, tunable settings, etc), Ubiquiti/UniFi etc just to find out it was a Bell issue.

I didn't consider the Bell modem being an issue as it's been rock solid the whole time I have had the service for 3+ years.

That started with HH3000 on GPON; both with the modem using PPPoE Passthrough, as well as bypassing it using the removable Nokia SFP in my Ubiquiti 10G switch. Both rock solid.

As well as after being migrated to the Gigahub 1.0 as part of being upgraded to the 3Gbps Symmetrical service with XGS-PON (no bypass available until more recently, but no real requirement for it because PPPoE passthrough has been rock solid up until this point).

I'll be using Advanced DMZ until I get the 3.11.6.3 firmware pushed... and will report back here and other forums describing this issue as I perform testing afterwards.

Happy to anwser any questions I can or help Bell with testing new firmware revisions.

[dg6464]

Will do, it's been fine all night. I had to manually enter the physical WAN interface MAC from my OPNsense Intel X520-DA2 NIC into the Bell modem's Advanced DMZ spot... as it didn't report the proper interface MAC.

Also, I am connecting the GigaHub 1.0 10Gbps Ethernet port into my Ubiquiti Switch on a dedicated WAN VLAN, as well as the OPNsense WAN port connection to the Ubiquiti switch on the WAN VLAN with that port profile.

That WAN VLAN is tied to a Port-Profile which is set to Port Mode "Infrastructure" and has everything disabled on it for:

Precision Time Protocol (PTP)

Storm Control

Egress Rate Limit

Flow Control

STP

Non-STP Loop Protection

Energy Efficient Ethernet (EEE)

LLDP-MED

Happy to answer any configuration questions, etc... but seems ok so far.

You experience may vary if connecting directly from OPNsense NIC into the Gigahub 10G ethernet port, as I've always used a switch in between for both WAN and LAN.

I'll report back if I see any instability or drops though.

[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.

[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.