Joined: 22 May 2020 Posts: 4 Location: Rome, Italy
Posted: Mon Feb 08, 2021 10:56 Post subject: [SOLVED] Wireguard streaming media problem (lower MTU)
I am having a problem with dd-wrt used as a Wireguard client where everything works *except* I can't stream video from he Apple services (Apple TV on AppleTV device, Apple TV app on iPhone, Apple TV app on Mac, etc.) Non Apple services on Apple devices work just fine (so, I can watch Hulu on AppleTV with no problem).
Let me start by describing my setup:
1. I have a Raspberry Pi sitting in 'Home 1' where it acts as a Wireguard server. It works great and I can connect to it directly using Wireguard client applications on Mac, Windows, and IOS devices. *everything* works when I use it this way.
2. In 'Home 2' I configured a dd-wrt router (Linksys WRT3200ACM, using DD-WRT v3.0-r44048 std [08/02/20]) to act as a client to the Raspberry Pi with a tunnel. I route all traffic through the tunnel to the Raspberry Pi, then it goes to the internet through 'Home 1'.
I had to change the MTU a few times to get all websites to load, I'm currently at 1412 on the tunnel MTU and on the bridge MTU.
I can now reach all websites I've tried. I can now use all apps on the AppleTV to stream with success -- except one: the native Apple stream. In other words, I can't stream videos I purchased through the Apple store (either legacy iTunes stuff, or the more modern Apple TV service). The same is true if I try to stream movies from my iPhone connected to the router, although the iPhone will stream just fine if I connect to a different network and establish the Wireguard tunnel using the Wireguard IOS app. Same thing on my Mac.
I tried reducing the MTU down to 1300, it didn't make a difference, so I bumped it back up to 1412.
The speed is outstanding -- I'm getting darned close to wire-speed down (130Mbps on a 180Mbps line) and full wire-speed up (19Mbps on a 20Mbps line).
Joined: 22 May 2020 Posts: 4 Location: Rome, Italy
Posted: Mon Feb 08, 2021 11:55 Post subject:
egc wrote:
Problems with streaming media are often due to MTU.
If you are not using ipv6 lower MTU to 1200 or even lower.
I am not using ipv6, but this doesn't seem to be the issue. I tried pushing MTU way down (I got down to 1000) and no joy (other than a bit of an impact on downstream throughput).
This is really weird. All other streaming and all other services work fine.
Joined: 18 Mar 2014 Posts: 12915 Location: Netherlands
Posted: Mon Feb 08, 2021 12:03 Post subject:
When using an app you often fill in the DNS server to use in the WG client settings.
Use the same DNS for the DDWRT client.
(It should not matter as you are routing all traffic through the tunnel including the DNS server but you never know)
Joined: 22 May 2020 Posts: 4 Location: Rome, Italy
Posted: Mon Feb 08, 2021 14:19 Post subject:
egc wrote:
When using an app you often fill in the DNS server to use in the WG client settings.
Use the same DNS for the DDWRT client.
(It should not matter as you are routing all traffic through the tunnel including the DNS server but you never know)
Use the kill switch so that you know that nothing can escape (it should not matter as you are routing all traffic through the tunnel but you never know, maybe the Apple TV already is connected before the tunnel goes up)
It turns out it WAS an MTU issue.
I just hadn't applied the changes and rebooted the router
It's running fine on MTU 1000. If I get enterprising I'll try to see how high I can go. Or maybe not -- the performance is perfectly good.
I do have a kill switch, and I also use Google DNS everywhere. Works well.
Joined: 14 Sep 2021 Posts: 21 Location: Western Hemisphere
Posted: Sat Feb 18, 2023 20:18 Post subject:
After several iterations and tests, finally landed on MTU 1200 for all my WG Server/Clients, higher MTUs would cause a hang on some media intensive web pages. Did not seem to effect speed much compared to higher MTUs. _________________ ASUS 7xAC68U
Linksys 3200ACM, 1900ACSv2, 3x1900AC, E3000, 5xE2500
Netgear 3xR7000, R6700, R6400
If able, give more than you take. Make the world better.
It turns out it WAS an MTU issue.
