Skip to main content

Bell Giga Hub 2.0 and a UniFi Dream Machine: use PPPoE, not Advanced DMZ

· 10 min read
Aqueeb
Aqueeb
Generalist tech guy, avid motorcyclist, & occasional canoe tripper

If you have Bell fibre through a Giga Hub 2.0 and run your own UniFi gateway behind it, this is the configuration that works: a PPPoE session on the UDM's WAN, and nothing on the hub. The UDM gets a public address of its own, port forwards work, and the WAN stays up. Advanced DMZ, the hub setting Bell offers for this, gets you a public address and then drops the link for a few seconds every ten minutes. The steps come first; the measurements and the reasons are at the end.

The result​

The hub keeps its own PPPoE session to Bell. The UDM opens a second one through a hub LAN port: the hub passes the PPPoE frames through, Bell accepts the second session alongside the first and gives it a different public address. Everything in the house leaves through the UDM's session, so the hub's NAT is out of the path and a port forward on the UDM is all a service like Plex needs.

Before this, the UDM's WAN sat on the hub's LAN at 192.168.2.11 and the public address lived on the hub. Hop 2 of any traceroute was 192.168.2.1, the hub, which is the giveaway for a double NAT.

Addresses in this post are made up: RFC 5737 ranges for the public side, 192.168.10.0/24 for my LAN. The hub's 192.168.2.x and Bell's 10.11.10.25 are real, because they are Bell's and not mine.

What you need​

  • Your Bell PPPoE user ID and password. The user ID starts with b1 and is shown on the Giga Hub's Internet status page. The password is not shown there; it came with the installation, and Bell support will reissue it if you have lost it.
  • The UDM's WAN port wired to a hub LAN port. For a plan above 1 Gbit/s that means the hub's 10 Gbit/s port to a 10 Gbit/s port on the UDM (SFP+ port 10 on my Pro Max).
  • Nothing else. No Advanced DMZ, no MAC cloning, no VLAN ID (VLAN 35 is for a router plugged into the fibre directly, which is a different setup).

Configure the UDM​

  1. Settings, Internet, your WAN. IPv4 Connection: PPPoE. Enter the user ID and password. Leave Use 1500 MTU off; the link comes up at 1492, which is the right size (why, below). Set DNS servers of your choice, 1.1.1.1 and 1.0.0.1 say, otherwise you get Bell's resolvers. Apply.
  2. Wait a minute. The dashboard shows the WAN up with a public address. It will not be the hub's address; Bell hands the second session its own.
  3. Port forward on the UDM for whatever you are exposing. For Plex: TCP 32400 to the Plex host, port 32400, source Any. Plex authenticates every connection itself, and limiting the source to one address only makes the rule stop working when that address changes.
  4. If it is Plex: Settings, Remote Access, Manually specify public port 32400, Retry. Within a minute it shows "Fully accessible outside your network" and the server log says mapping state set to 'Mapped'.

Nothing changes on the hub. If you turned Advanced DMZ on in an earlier attempt, it no longer matters: the hub applies it to a device that takes a DHCP lease from it, and a PPPoE WAN never asks for one. Mine is still on and plays no part.

If you have the two static routes from an earlier Advanced DMZ setup (the 0.0.0.0/1 and 128.0.0.0/1 pair described below), disable them. With PPPoE the kernel installs a plain default route out ppp0 and the pair is not needed.

Check it​

From a PC on the LAN:

tracert -d -h 3 8.8.8.8

Hop 1 is the UDM and hop 2 must be a Bell address, not 192.168.2.1. Then:

curl --interface 192.168.10.51 https://api.ipify.org

returns the WAN address the UDM shows. Pin the source address if the PC has any other way out, a phone tether or a VPN, or you will test the wrong path. Finally, an outside port check (portchecker.io or canyouseeme.org) against that address and port 32400 reports open. For Plex, its own Remote Access check is the last word.

What it costs and what it fixes​

Measured on a UDM Pro Max, UniFi OS 5.1.34 and Network 10.6.109, on a 3 Gbit/s symmetric plan, behind a Giga Hub 2.0 on firmware 3.11.6.4.

Throughput. UniFi's built-in speed test, same server, minutes apart:

WANDownUpLatency
Advanced DMZ, with the two routes below3202 Mbit/s3169 Mbit/s2 ms
PPPoE3028 Mbit/s2945 Mbit/s2 ms

About five percent. PPPoE encapsulation runs on the UDM's CPU: the Pro Max's four cores were 57 percent busy over the test window, a third of that in software interrupts. Owners of the original UDM Pro report PPPoE topping out near 2 Gbit/s on that hardware, so on a smaller gateway the price is higher.

Stability. On Advanced DMZ the WAN went down for one to three seconds every 9 minutes 56 seconds, for as long as I watched (eleven times in two hours), and the dashboard reported 100 percent uptime throughout. On PPPoE, a one-per-second ping from a LAN PC over 15 minutes answered 899 of 900 with no gap longer than a single sample, and the UDM's own monitors agreed.

MTU. The PPPoE link is 1492 bytes, 1500 minus the 8-byte PPPoE header. Through the hub, 1500-byte packets are dropped silently: a don't-fragment ping with a 1472-byte payload (1500 on the wire) never answers, 1464 (1492 on the wire) answers in 3 ms, and no "fragmentation needed" message comes back, so path MTU discovery cannot save you. Leaving Use 1500 MTU off makes the UDM size everything to 1492 and removes the guesswork.

Why not Advanced DMZ​

Advanced DMZ is the hub's intended way to give one device the public address: pick the device by MAC and the hub leases it the public IP instead of a 192.168.2.x address. Two things are wrong with that lease on the Giga Hub 2.0, both captured with tcpdump on the UDM's WAN port.

The gateway is not on the subnet. The hub's offer:

Your-IP 203.0.113.98
Subnet-Mask (1): 255.255.255.0
Default-Gateway (3): 10.11.10.25
Lease-Time (51): 600
Server-ID (54): 192.168.2.1

A /24 around the public address, and a router one subnet away. RFC 2132 section 3.5 requires the router option to be on the client's subnet; the Linux kernel in the UDM refuses a default route through a next hop it cannot ARP for, so the UDM ends up with a public address, an empty gateway in its health report and no internet. The hub answers ARP for every address on the internet (proxy ARP, 350 to 800 ms per reply), which is how the lease works on devices that accept it. The workaround on UniFi is two static routes that declare the whole internet on-link:

NameDestinationTypeInterfaceDistance
Bell-ADMZ-10.0.0.0/1InterfaceWAN1
Bell-ADMZ-2128.0.0.0/1InterfaceWAN1

UniFi will not take an interface route for 0.0.0.0/0, and two halves are more specific than any default route anyway. The internet comes back the moment they are in. Also mind which MAC you give the hub: Advanced DMZ keys on the UDM's WAN port MAC, which is not the base MAC in the console header (on a Pro Max, SFP+ port 10 is the base plus nine). The hub's device list shows it next to the UDM's 192.168.2.x address.

The hub ignores renewals. The lease is 600 seconds. The UDM's DHCP client renews by unicast from the halfway point and by broadcast near the end, and the hub answers none of them, so the lease expires every time: the UDM drops the address, the WAN goes down, a fresh discover is answered in 3 milliseconds with the same lease, and the WAN is back three seconds later. Every 9 minutes 56 seconds. ASUS and SonicWall owners report the same cycle behind a Giga Hub 2.0, with no answer from Bell since November 2025. A static WAN address does not avoid it: Bell's own moderator states that a device that never requests a lease is never in Advanced DMZ, and a user who tried a static /32 had it stop after a few days.

PPPoE has neither problem: no lease, no DMZ state on the hub, a session that renews itself, and a plain default route. It is also what the Bell forum's regulars recommend for this symptom.

Appendix: the API calls​

Everything above can be read and set without the UI. The UDM takes an API key (the Integrations icon in the left rail of the Network app on 10.1 and later) in an X-API-KEY header. With H='X-API-KEY: <your key>' and -k for the self-signed certificate:

# WAN state: address, gateway, nameservers
curl -sk -H "$H" https://192.168.10.1/proxy/network/api/s/default/stat/health

# Port forwards (list; POST the same shape to create one)
curl -sk -H "$H" https://192.168.10.1/proxy/network/api/s/default/rest/portforward

# Static routes (list)
curl -sk -H "$H" https://192.168.10.1/proxy/network/api/s/default/rest/routing

# Create one of the two Advanced DMZ routes
curl -sk -H "$H" -H 'Content-Type: application/json' -X POST https://192.168.10.1/proxy/network/api/s/default/rest/routing -d '{"name":"Bell-ADMZ-1","enabled":true,"type":"static-route","static-route_network":"0.0.0.0/1","static-route_type":"interface-route","static-route_interface":"WAN","static-route_distance":1}'

# The live kernel routing table (the classic stat/routing is empty on UniFi OS)
curl -sk -H "$H" https://192.168.10.1/proxy/network/v2/api/site/default/routes

The official Integration API at /proxy/network/integration/v1/ takes the same key but has no port-forward or static-route endpoints as of Network 11.

Sources​