Netflix Issues over WireGuard

johnpoz

RF you say ;) guess what I did in the Navy.. HF comms, most specific the SRC-16, but also URT-23s and some crypto..

That was back before computers were really even thing..

arrmo

@johnpoz Nice! Sounds very cool. And yes, computers were real boat anchors back then . I started in optical fiber amplifiers. Man, takes me back!

AB5G

@arrmo Your issue may be related to this - https://www.reddit.com/r/WireGuard/comments/ef1hhj/mturelated_problems_when_using_a_lan_gateway_to/

I'm taking a guess here but only Netflix not working points to the MTU issues.

arrmo

@ab5g said in Netflix Issues over WireGuard:

I'm taking a guess here but only Netflix not working points to the MTU issues.

It may be! I had other issues before, that may have been "hiding" this. Hmmm ... let me read this one over a couple times - wondering where I need to set the MTU (i.e. just on OpenWrt "client"). It's funny, but two different DHCP clients hanging off that OW router - one works, the other doesn't ... LOL.

Thanks!

Griffo

@ab5g Given your prompt I just went and did the old ping test to determine MTU on some of my WG tunnels. The highest i could get was 1392 without a fragmentation error, which given the 28 byte ICMP & TCP header aligns to 1420.

I then checked ifconfig, and it looks like pfsense already sets all WG interfaces to 1420:

e.g

wg0: flags=8080c1<UP,RUNNING,NOARP,MULTICAST> metric 0 mtu 1420

What I can't find is why 1420 is the magic number.. I thought WG had only 32 bytes of overhead

I can confirm however that Netflix works fine on my WG tunnels to a commercial VPN provider.

AB5G

@griffo 1420 is the default MTU for WG (1500-80) - comes from here - https://lists.zx2c4.com/pipermail/wireguard/2017-December/002201.html

If you are running WG over a PPPoE instead of Ethernet then instead of 1500-80 you'd have 1492 (MTU for PPPoE) - 80 = 1412.

P:S : For me I have no issues on WG - except for some missing packets that I strongly believe is a bug. I have a separate thread on it.

arrmo

@griffo said in Netflix Issues over WireGuard:

The highest i could get was 1392 without a fragmentation error

Hi,

Sorry for the delay - having a bit of "fun" today, with rolling power outages thanks to crazy winter weather. Trying to get to this, between outages .

@Griffo , to your comment above, about "The highest i could get was 1392 without a fragmentation error" ... are you just adjusting the size of ping (packets), to see where it breaks? Will try to duplicate here, but want to first understand how you are doing it .

I do see here the same 1420 MTU on pfSense, but perhaps on the remote end (OW) it's not following / abiding by this? I do also see some notes in the links from @AB5G (thanks!) about messing with iptables - is this on the OW side (I assume, but may be wrong).

Thanks again!

arrmo

OK, an update - and this is VERY odd . There are two clients behind the OW router, both getting DHCP from the router, and both on the same subnet and WG link of course. But ... one of them, Netflix is fine. The other - nope! One is a Windows laptop, the other a Roku TV. I did change the MTU setting on the router, but that made no difference, and I actually captured the traffic coming out from the tunnel on the pfSense side (tcpdump) - both seem to show a maximum packet size of 1424 (to and from Netflix) ... not sure if that is an issue or not, as this is on the pfSense side, not OW (where I reduced the size ... perhaps not enough though?).

But ... as both clients are on the same subnet - seems like it's not routing, nor packet size? Or am I just confused?

Thanks!

Dhiru

I suspect that TCP MSS clamping is not enabled for wireguard interfaces. I am facing similar issues with not just Netflix but several other websites on 2.5 when wireguard is enabled to route all traffic through VPN.

I was able to fix this by adding a clamping rule on my VPN server. Ideally I would like pfSense to add the rule on the interface by default.

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

arrmo

@dhiru Yes, agreed - and similar to the link above from @AB5G. There is a way to do this in the webConfigurator as well (you can set MSS inside the interface). I tried it, and it works ... and also fixes my issue, thanks!

What's very odd, I can see the MSS webConfigurator setting works (based on tcpdump captures). But when I upgraded from 2.5-RC to 2.5 => it no longer seems to be needed. Huh?

Thanks!