Gold Plus severely reducing inbound Tailscale throughput — confirmed with direct bypass A/B test

I am troubleshooting a significant and repeatable Tailscale throughput issue involving my Firewalla Gold Plus. I have now performed a direct A/B test that appears to isolate the Firewalla as the source of the performance degradation.

IMPORTANT NETWORK SPEED CONTEXT

Dublin, Ohio:
AT&T symmetrical 1000/1000 Mbps fiber

Naples, Florida:
Blue Stream symmetrical 500/500 Mbps fiber

Dublin therefore has approximately twice the provisioned Internet bandwidth of Naples.

Despite this, Tailscale traffic entering Dublin through the Firewalla Gold Plus has consistently been much slower than comparable traffic entering Naples, where there is no Firewalla.

KEY FINDING — DIRECT FIREWALLA BYPASS TEST

I connected the exact same Dublin Raspberry Pi 5 directly to the AT&T router, completely bypassing the Firewalla Gold Plus.

Tailscale throughput immediately increased dramatically:

DigitalOcean → Dublin Pi:
Behind Firewalla: ~154 Mbps
Direct to AT&T router: ~820 Mbps

Naples → Dublin Pi:
Behind Firewalla: ~168 Mbps
Direct to AT&T router: ~390 Mbps

This represents approximately:

• 5.3x higher DigitalOcean → Dublin throughput when Firewalla is bypassed.
• 2.3x higher Naples → Dublin throughput when Firewalla is bypassed.

The same Dublin Pi 5, same Tailscale configuration, same AT&T 1000/1000 connection, and same remote endpoints were used.

The material change was removing the Firewalla Gold Plus from the traffic path.

This also demonstrates that the Dublin Pi, Tailscale, and AT&T connection are capable of substantially higher throughput than I see when the Firewalla is in the path.

NETWORK CONFIGURATION

Dublin:
AT&T symmetrical 1000/1000 Mbps fiber
→ Firewalla Gold Plus
→ eero in bridge mode
→ Raspberry Pi 5 via Gigabit Ethernet
→ Tailscale

Naples:
Blue Stream symmetrical 500/500 Mbps fiber
→ Blue Stream gateway
→ eero router
→ Raspberry Pi 5 via Gigabit Ethernet
→ Tailscale

There is no Firewalla at the Naples location.

Cloud:
DigitalOcean droplet in NYC running Tailscale.

NORMAL TAILSCALE RESULTS WITH FIREWALLA IN THE DUBLIN PATH

Recent full uncapped Tailscale/iperf3 benchmarks:

Dublin → Naples: ~387 Mbps
Naples → Dublin: ~168 Mbps
DigitalOcean → Naples: ~241 Mbps
DigitalOcean → Dublin: ~154 Mbps

The consistent pattern is significantly reduced throughput when traffic enters the Dublin network through the Firewalla.

This is especially surprising because Dublin has 1000/1000 Mbps service while Naples has only 500/500 Mbps service.

For example, the same DigitalOcean endpoint reaches:

DigitalOcean → Naples: ~241 Mbps
DigitalOcean → Dublin through Firewalla: ~154 Mbps
DigitalOcean → Dublin bypassing Firewalla: ~820 Mbps

Similarly:

Naples → Dublin through Firewalla: ~168 Mbps
Naples → Dublin bypassing Firewalla: ~390 Mbps

TAILSCALE PATH VERIFICATION

The Tailscale connections are direct WireGuard connections and are not using DERP.

DigitalOcean → Dublin:
Direct endpoint: 108.212.142.234:41641
Idle Tailscale RTT: ~25 ms

DigitalOcean → Naples:
Direct endpoint: 104.203.45.187:1026
Idle Tailscale RTT: ~39-40 ms

Interestingly, Dublin has lower latency to DigitalOcean despite having substantially worse throughput when Firewalla is in the path.

TCP DIAGNOSTICS WITH FIREWALLA IN PATH

I captured TCP statistics during identical five-second single-stream tests.

DigitalOcean → Dublin:

Throughput: ~153.77 Mbps received / ~157.45 Mbps sent
Retransmissions: 156 during the measured five-second interval
Congestion window: approximately 0.95-1.31 MB
TCP RTT under load: approximately 41-60 ms

DigitalOcean → Naples:

Throughput: ~240.61 Mbps received / ~241.53 Mbps sent
Retransmissions: 77 during the measured five-second interval
Congestion window: approximately 1.25-1.73 MB
TCP RTT under load: approximately 41-55 ms

Both tests used:

• CUBIC
• MSS 1228
• Tailscale MTU 1280

Neither connection appeared receive-window limited.

The Dublin flow experienced more sustained retransmissions and maintained a smaller effective congestion window.

ENDPOINT AND HARDWARE CHECKS

Both Dublin and Naples endpoints are Raspberry Pi 5 systems connected via Gigabit Ethernet.

During testing:

DigitalOcean → Dublin:
Sender CPU: ~0.82%
Dublin receiver CPU: ~4.75%

DigitalOcean → Naples:
Sender CPU: ~1.38%
Naples receiver CPU: ~2.49%

I have also verified:

• Both Pis negotiate 1 Gbps/full duplex.
• No meaningful Ethernet errors or drops.
• Tailscale MTU is 1280 on both systems.
• PMTU testing does not show an obvious fragmentation/MTU difference.
• There is no memory pressure.
• CPU is nowhere near being a bottleneck.
• Tailscale connections are direct.
• No DERP relay is involved.

Most importantly, the direct-to-AT&T bypass test demonstrates that the exact same Dublin Pi can receive Tailscale traffic from DigitalOcean at approximately 820 Mbps.

FIREWALLA CONFIGURATION

I have verified directly in the Firewalla app:

• Smart Queue is OFF.
• There is no device-specific bandwidth or rate-limit rule on the Dublin Pi.
• The Pi is monitored normally.
• Normal AT&T WAN performance is healthy and near the expected gigabit service level.

I have not intentionally disabled Active Protect, IDS/IPS, or other Firewalla security functionality.

RELATED FIREWALLA COMMUNITY REPORT

I found the Firewalla community discussion titled:

“Firewalla & Tailscale: Performance Bottleneck”

The behavior described there appears very similar to what I am observing: raw traffic could operate near line rate while Tailscale/WireGuard traffic traversing Firewalla experienced substantially reduced throughput.

That discussion also referenced investigation involving UDP packet acceleration/tuning.

Given my direct bypass results, I am wondering whether the same packet-processing behavior may be occurring on my Gold Plus.

SUMMARY OF THE A/B EVIDENCE

Dublin Internet:
1000/1000 Mbps

Naples Internet:
500/500 Mbps

DigitalOcean → Dublin through Firewalla:
~154 Mbps

DigitalOcean → Dublin with Firewalla bypassed:
~820 Mbps

Naples → Dublin through Firewalla:
~168 Mbps

Naples → Dublin with Firewalla bypassed:
~390 Mbps

DigitalOcean → Naples, where there is no Firewalla:
~241 Mbps

The same hardware, Tailscale configuration, Internet connection, and remote endpoints were used for the Dublin bypass tests. Removing the Firewalla from the path produced the dramatic throughput improvement.

QUESTIONS FOR FIREWALLA SUPPORT / ENGINEERING

1. Is there a known issue involving high-throughput Tailscale/WireGuard UDP traffic traversing a Firewalla Gold Plus?
2. Why would the same DigitalOcean → Dublin Tailscale flow increase from approximately 154 Mbps to approximately 820 Mbps when the Gold Plus is removed from the path?
3. Why would Naples → Dublin increase from approximately 168 Mbps to approximately 390 Mbps when the Gold Plus is removed from the path?
4. Could Firewalla packet acceleration, IDS/IPS, flow inspection, or UDP processing explain the additional retransmissions and smaller congestion window observed when the Gold Plus is in the path?
5. Is the UDP packet-acceleration behavior discussed in the Firewalla community Tailscale performance thread applicable to Gold Plus or current Firewalla software?
6. Are there specific diagnostics I can capture from the Gold Plus while reproducing this issue that would help engineering determine where packets are being delayed or dropped?
7. Is there a supported way to temporarily bypass relevant packet processing for only the Dublin Pi so we can perform additional controlled A/B testing without disabling security globally?
8. Are there any tuning changes, beta releases, or fixes available for this behavior?

I can reproduce the issue on demand and provide additional Tailscale, iperf3, TCP, or Firewalla diagnostics if useful.

The most compelling evidence is the direct A/B comparison:

DigitalOcean → Dublin:
~154 Mbps through Firewalla
~820 Mbps bypassing Firewalla

Naples → Dublin:
~168 Mbps through Firewalla
~390 Mbps bypassing Firewalla

Given that Dublin has 1000/1000 service, Naples has only 500/500 service, and the exact same Dublin Pi reaches ~820 Mbps as soon as Firewalla is removed from the path, I would appreciate having engineering review whether this is consistent with a known Firewalla UDP/WireGuard/Tailscale packet-processing issue.