Brume 2 slow wireguard download

brume · December 25, 2025, 7:29am

I am running a WireGuard server on a Brume 2 in location A which has 910/105 (Mbps down/up) line. When I run iperf3 from the Brume 2 I get the following two results confirming this

[ ID] Interval Transfer Bitrate Retr

[ 5] 0.00-10.03 sec 1000 MBytes 837 Mbits/sec 0 sender

[ 5] 0.00-10.00 sec 989 MBytes 829 Mbits/sec receiver

[ ID] Interval Transfer Bitrate Retr

[ 5] 0.00-10.00 sec 121 MBytes 101 Mbits/sec 41 sender

[ 5] 0.00-10.10 sec 118 MBytes 98.2 Mbits/sec receiver

If I run iperf3 from location B which has 55/5 (Mbps down/up) to the Brume 2 at location A using the public IP address of router it is behind then I get the full speed available at location B.

[ ID] Interval Transfer Bitrate Retr

[ 5] 0.00-11.08 sec 55.9 MBytes 42.3 Mbits/sec 428 sender

[ 5] 0.00-10.00 sec 52.3 MBytes 43.9 Mbits/sec receiver

[ ID] Interval Transfer Bitrate Retr

[ 5] 0.00-10.00 sec 8.45 MBytes 7.09 Mbits/sec 0 sender

[ 5] 0.00-11.16 sec 6.63 MBytes 4.99 Mbits/sec receiver

If instead I connect to the Brume 2 from my Flint 2 (or laptop/phone) then the download speed looks to be capped to around 10Mbps

ID] Interval Transfer Bitrate

[ 5] 0.00-1.00 sec 3.35 MBytes 28.1 Mbits/sec

[ 5] 1.00-2.00 sec 1.27 MBytes 10.6 Mbits/sec

[ 5] 2.00-3.00 sec 1.22 MBytes 10.3 Mbits/sec

[ 5] 3.00-4.00 sec 1.04 MBytes 8.73 Mbits/sec

[ 5] 4.00-5.00 sec 971 KBytes 7.96 Mbits/sec

[ 5] 5.00-6.00 sec 1.30 MBytes 10.9 Mbits/sec

[ 5] 6.00-7.00 sec 1.39 MBytes 11.7 Mbits/sec

[ 5] 7.00-8.00 sec 1.53 MBytes 12.8 Mbits/sec

[ 5] 8.00-9.00 sec 1.10 MBytes 9.20 Mbits/sec

[ 5] 9.00-10.00 sec 1.07 MBytes 8.97 Mbits/sec

- - - - - - - - - - - - - - - - - - - - - - - - -

[ ID] Interval Transfer Bitrate Retr

[ 5] 0.00-10.72 sec 15.9 MBytes 12.5 Mbits/sec 363 sender

[ 5] 0.00-10.00 sec 14.2 MBytes 11.9 Mbits/sec receiver

The upload on this connection is still ~5Mbps but as this is low it doesn't reveal anything.

I have tried:

1. Reducing the MTU as suggested in other threads but this doesn't improve matters.

2. Using tailscale but the result is identical

Additionally, I have tried speed tests from my mobile when I have faster up down speed (results attached). The test without WireGuard was 275/31.6 and with 9.62/39.9 so it looks like the upload speed is unaffected.

Can anyone suggest what could be causing this and how I can fix it?

I've thrown everything the LLM's have to offer at it with no affect. Is this likely to be an issue with the Brume 2?

will.qiu · December 26, 2025, 2:10am

Hi

Could you try the following:

Test UDP throughput with iperf3 (instead of TCP) between the two sites. This helps check whether the ISP/carrier path is treating UDP traffic differently (for example, traffic shaping/QoS that impacts WireGuard/Tailscale).
```
iperf3 -c <iperf3_server> -R -u --udp-counters-64bit  -b 50M
```
(You can also try a few different bandwidth targets with -b, e.g. -b 50M, -b 100M, to see where loss starts.)
Swap the server-side router for comparison: if you temporarily replace the Brume 2 at location A with a Flint 2 (running the same WireGuard server settings), does the VPN download throughput change?

brume · December 26, 2025, 6:36am

Hi,

Thanks for the quick reply. I can’t believe I didn’t test UDP, but it looks like your intuition is correct as point to point UDP and UDP from public test servers consistently starts to degrade at 14M. See below

13M

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 15.5 MBytes 13.0 Mbits/sec 0.000 ms 0/11284 (0%) sender
[ 5] 0.00-10.02 sec 15.5 MBytes 13.0 Mbits/sec 0.075 ms 0/11284 (0%) receiver
14M

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 16.7 MBytes 14.0 Mbits/sec 0.000 ms 0/12152 (0%) sender
[ 5] 0.00-10.02 sec 16.4 MBytes 13.7 Mbits/sec 0.359 ms 204/12152 (1.7%) receiver
20M

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 23.8 MBytes 20.0 Mbits/sec 0.000 ms 0/17360 (0%) sender
[ 5] 0.00-10.02 sec 16.5 MBytes 13.8 Mbits/sec 0.412 ms 5377/17359 (31%) receiver

Location A is using Vodafone UK fibre and I have found a few other posts online describing this issue. They point to the Vodafone power hub applying QOS to avoid UDP egress flooding the network (which I guess makes a bit of sense). Unfortunately there don’t seem to be any settings on the router to change this so I can’t confirm 100% this is the issue. I will need to go to location A with the Flint 2 and if that works try a different router (if I can get my ISP login credentials) to confirm 100% but I am 99% sure it is an ISP issue.

Thank you for you help, if you have any ideas on how I can bypass the QOS to confirm that is the issue then please let me know.

will.qiu · December 26, 2025, 7:45am

If the carrier is actively enforcing QoS or rate limiting on UDP traffic, there is no reliable way to override this behavior on the router itself.

You can try the following options:

Change the WireGuard listening port to UDP 443. Since QUIC (used by many major services) commonly runs over UDP 443, some ISPs treat this port more leniently than other UDP ports. While not guaranteed, it is often worth testing.
If UDP performance remains limited, use OpenVPN in TCP mode instead. TCP-based VPNs are generally less affected by UDP-specific shaping, though this may come at the cost of higher latency and slightly lower efficiency compared to WireGuard under ideal conditions.

These workarounds cannot fully eliminate carrier-side policies, but they are the most practical approaches when UDP throttling is present.

brume · December 27, 2025, 6:14pm

Is this possible on the brume 2? I can’t change the port to 443 or 8443 in the WireGuard GUI.

will.qiu · December 29, 2025, 3:57am

Please go to System - Security and change the Admin Panel or Luci port from 443 / 8443 to another port first.
Then you should be able to change the WireGuard server port.

brume · January 4, 2026, 7:51am

Thanks @will.qiu for all you help that worked perfectly but unfortunately made no difference. I’ve had to fall back to OpenVPN as you suggested, which does not suffer from any throttling. If I manage to resolve the issue with my ISP then I will update the post with details.