Solving UniFi Gateway PPPoE Performance Bottlenecks with PPPoE Half-Bridge

UniFi gateways often suffer from severe throughput degradation on PPPoE connections because their CPUs lack hardware acceleration for PPPoE and NAT. By offloading the PPPoE dialing process to a separate OpenWrt-based device—a technique called PPPoE Half-Bridge—users can restore full line speed to their UniFi gateways by delivering a public IPv4 address via DHCP instead of requiring the gateway to handle the PPPoE session itself.

The Root Cause of UniFi PPPoE Performance Issues

Most UniFi gateways, including the UDM Pro, UDM SE, UDM Pro Max, UXG Pro, and EFG, utilize OEM platforms that do not support PPPoE hardware acceleration. This creates a significant performance bottleneck because the PPPoE protocol requires the router to encapsulate and decapsulate every packet, a process that is typically single-threaded in Linux and pfSense implementations.

Because the processing is pinned to a single CPU core, throughput is limited regardless of the total number of cores available on the device. Observed performance benchmarks highlight this gap:

  • UDM Pro/SE: Typically 1200 Mbps to 1500 Mbps on PPPoE.
  • UDM Pro Max: Typically 1400 Mbps to 1800 Mbps on PPPoE.
  • EFG: Typically 1400 Mbps to 2400 Mbps on PPPoE.
  • UCG Fiber: Can exceed 5000 Mbps because it uses the MediaTek Filogic 880 SoC, which includes native PPPoE hardware acceleration.

How PPPoE Half-Bridge Acceleration Works

PPPoE Half-Bridge (also known as Zero IP Bridge) moves the computationally expensive task of PPPoE dialing and session management to a dedicated offload device. Instead of the UniFi gateway dialing the ISP, the offload device handles the PPPoE session, obtains the public IPv4 address, and then "hands" that address to the UniFi gateway via a local DHCP server.

In this architecture, the offload device does not hold the public IP for itself; it simply acts as a transparent pass-through for the IP address. The UniFi gateway receives the public IPv4 via DHCP, allowing it to focus its CPU resources on routing, NAT, and IDS/IPS without the overhead of PPPoE encapsulation.

While some ISP-provided ONT/ONU devices offer similar functionality through features like "Advanced DMZ" or "IP Passthrough," many do not, necessitating a custom implementation.

Implementing the Solution with OpenWrt

ArcBox Labs implemented this solution using OpenWrt and a Banana Pi BPI-R4 Pro. The implementation relies on the hotplug.d mechanism to automate the bridge configuration whenever a PPPoE session is established.

The Technical Workflow

The process is managed by two primary files: 99-half-bridge (the trigger) and start-half-bridge.sh (the logic). The execution flow is as follows:

  1. Firewall Adjustment: NAT/MASQUERADE is disabled on the WAN side of the OpenWrt firewall.
  2. IP Extraction: The script reads the dialed public IPv4 address from the PPPoE virtual interface (e.g., ppp0).
  3. DHCP Configuration: The script computes the /24 subnet of the public IP and configures the OpenWrt DHCP server to hand that specific public IPv4 to the downstream UniFi gateway.
  4. Source-Based Routing: Policy-based routing is implemented so that packets are sent out via the PPPoE virtual interface only if they match the source IP assigned to the downstream router. This allows the system to support multiple PPPoE connections simultaneously.
  5. Interface Reset: The physical interface is restarted to trigger the UniFi gateway to request a new IP via DHCP.
  6. ARP Fix: Due to issues with UniFi's ARP implementation, static ARP entries (ip neigh replace) are added to OpenWrt to ensure stable communication.

Using this method, ArcBox Labs reported breaking past 5000 Mbps of PPPoE throughput.

Community Insights and Counterpoints

Technical discussions regarding this implementation highlight several points of contention and alternative perspectives:

Hardware vs. Protocol Overhead

Some users argue that the performance drop is strictly a hardware gap rather than an inherent flaw in PPPoE. As one user noted:

The UCG Fiber numbers make the case: this is a SoC acceleration gap, not a PPPoE overhead problem. Half-bridge is a workaround for hardware Ubiquiti shipped.

ISP Prevalence and Accuracy

There is significant debate regarding the current prevalence of PPPoE. While the author claims it is still widely used by major US providers like AT&T Fiber and Xfinity, community members corrected these assertions, stating that Xfinity (DOCSIS) and AT&T Fiber (XGSPON) do not use PPPoE at the data link layer.

Alternative Solutions

Some users suggested that if a user is already deploying a capable OpenWrt box to handle the PPPoE session, it may be more efficient to replace the UniFi gateway entirely rather than bridging to it. Others mentioned using specific hardware like the WAS-110 to achieve full speed PPPoE with certain providers (e.g., Bell Canada).

Sources