Netflix Issues over WireGuard

johnpoz

Welcome to the never ending game of wack-a-mole

arrmo

@ab5g said in Netflix Issues over WireGuard:

from a LAN device on the OW LAN to Netflix and YouTube
from a LAN device on the OW LAN to a site that works
from a LAN device on the OW LAN to WG LAN

OK, data below. And what's interesting - I can't even just get to the netflix.com web page (i.e. never mind running an app for video). Here are the traceroute results (arrgh, having issues with this being flagged as spam?!?!). Edited a bit, to get it to post (and added Pastebin links to avoid that). Sorry!

LAN device on the OW LAN to Netflix and YouTube
https://paste.ubuntu.com/p/KFbf4kWn7j/
LAN device on the OW LAN to a site that works - tv.youtube above works. But also, google.com (or almost any site except Netflix ... LOL!),
https://paste.ubuntu.com/p/hqgfPSrX35/
LAN device on the OW LAN to WG LAN - two here, also adding the cable modem, just "outside" pfSense (i.e. WAN side),
https://paste.ubuntu.com/p/jy9nFmt2XZ/

And BTW, if I just disable WG, re-enable OpenVPN (what I had before, it's between the same two endpoints) ... Netflix is fine. But trying to move away from OpenVPN - it's not real stable (hangs a lot), and slower.

Thanks!

arrmo

@dem said in Netflix Issues over WireGuard:

It has nothing to do with WireGuard or your pfSense configuration

I was wondering that ... but if I just "trade" WG for OpenVPN, exactly the same endpoints - all is good. Thoughts?

Thanks!

NogBadTheBad

This post is deleted!

johnpoz

@arrmo said in Netflix Issues over WireGuard:

it's between the same two endpoints

What is your exit IP from the vpn.. Do a whats my ip when your using openvpn (that works for netflix) and then with wg (doesn't work with netflix), do the same thing.

I would "guess" that your IP your presenting to netflix is different.. Just because your connecting to the same IP for your vpn connection, doesn't mean your going to use the same exit IP leaving the vpn service.

arrmo

@johnpoz said in Netflix Issues over WireGuard:

What is your exit IP from the vpn.. Do a whats my ip when your using openvpn (that works for netflix) and then with wg (doesn't work with netflix), do the same thing.

Yep, I had done that before - which is part of my confusion . It's always the same IP, and also matching to my local internet IP (i.e. WAN side of pfSense). I also checked whois for that IP, and it's correct. FYI, thanks to @AB5G, I have Outbound NAT set up for my pfSense box, so the external traffic should look the same ... agreed? Oh, and YouTube TV is happy, it's also checking IP address - right?

BTW, I am using http://ip4.me/api/ for (internet) IP, works quite nicely (even with curl).

Thanks!

arrmo

And FYI, I just tried a traceroute to netflix.com sitting on the same subnet as pfSense (i.e. right behind the firewall), and it looks very much like above. So not sure traceroute is really telling the whole story? I am able to get to the web site

Thanks!

arrmo

And one more thing - digging in to this, it may be nothing, but in case it means something to someone else (i.e. more than me ... LOL!). The error I see in Chrome is ERR_HTTP2_PING_FAILED.

Not sure yet what HTTP2 is, and if this is for some reason not getting across the WG link (or through routing).

Thanks!

arrmo

FYI, I did also check the routing tables (on OpenWrt / the client side), using WG or OVPN - they are a bit different. OVPN uses two "sub entries", to be more specific for preference reasons (more info here) => so I changed 0.0.0.0/0 on the client side to 0.0.0.0/1 and 128.0.0.0/1 ... no difference (assuming I don't need to restart WG on pfSense for this). Dang it!

Just to keep you in the loop.

Thanks!

AB5G

@arrmo
Your trace is ok - remote OW LAN is able to route to pfsense 192.168.253.1 for Netflix access. We also see that pf is routing is correctly to the WAN_DHCP. Now the only few things preventing Netflix (assuming that your IP is not detected as a VPN by Netflix) is

Set a lower MTU on the WG tunnel. Google how to do that - start with 1400 or 1380
Check to make sure you are not blocking anything in pfBlocker NG or other packages
Check to make sure OW LAN is using the same DNS servers as the pfLAN

arrmo

@ab5g said in Netflix Issues over WireGuard:

assuming that your IP is not detected as a VPN by Netflix

I don't think so, could be wrong, but internet IP check seems clean.

@ab5g said in Netflix Issues over WireGuard:

Set a lower MTU on the WG tunnel. Google how to do that - start with 1400 or 1380
Check to make sure you are not blocking anything in pfBlocker NG or other packages
Check to make sure OW LAN is using the same DNS servers as the pfLAN

Will try those, thanks! On them,

Changed MTU, but had to reboot OW - and as it's remote, I need someone to reconnect to the router to check. Will be tomorrow to confirm that one, sorry!
I don't think so . No packages installed that block any traffic (that I can see at least).
Yes, pretty sure that's clean also - nslookup to machines on the pfSense subnet resolves / returns, so thinking that is good as well.

I'll get back to you on #1, once I can check it. Thanks again.

arrmo

A bit more data ... and a "fix" (not really, but a data point ). Let me explain.

To the questions above, I did check the MTU - no change. Packages ... don't think that's it, will explain below.

So I did some poking on pfSense, noticed one difference (OpenVPN vs. WG) - I did not have an interface assigned for OpenVPN (mistake perhaps, but that's for another day ... LOL!). But I did have a "pass all" rule for OpenVPN (group). So just for giggles, I put back the old rule I had for WG (group) ... voila! Now Netflix works. I don't think this is a real fix (@ab5g, I agree with you, this should go through the interface!). So I think this means that the interface rule is not quite right ... agreed?

So I checked the interface rule, and it looks right to me (I think) - meaning I think followed the recommendations, but I may have something broken. Pic below ... is the source for OW really right? Wondering about back to OW ... could that be the issue?

OK, really funny - but enabling the WG Group (for Netflix) breaks another web site ... LMAO! But let's get the WG Group rule out of there, that may take care of this also.

Thanks!!!

arrmo

And a bit more debugging - pulling my hair out though! LOL. I turned off the group rule (pass-all), and yep ... Netflix blocked. So, I added an interface rule ... like above, but with source = all (for testing). Nope, still no go. So is this about return traffic? I admit, a bit confused.

Oh, and FYI - to capture it for others. I changed the rule back (i.e. re-enabled the group rule). Did not need to restart WG, and it all started working again (i.e. Netflix gets through).

Thanks!

PS, just noticed, poking around ... but WG_WGV4 is set to 192.168.253.2, one of the (other) clients. This doesn't seem right, but I also can't seem to change it?

johnpoz

I don't have any WG to play with as of yet.. But as soon as 2.5 drops I will be moving to it. And will be sure to fire up WG on one of vps to play with. Like I have openvpn access server setup now to play with when users have questions.

Wish I could be of more help.. Maybe your having problems with states? If traffic goes out way X and creates a state, even if you bring up another way to go out the wan, be it openvpn or wg, or just policy routing out another gateway.. That existing state can send traffic out way X, even when you have a new policy that should send it out Y.

arrmo

@johnpoz said in Netflix Issues over WireGuard:

Like I have openvpn access server setup now to play with when users have questions.

Sounds great. And some of my notes above are to try to share findings with others. I know this is new, so whatever we can help each other with is all positive. To be honest, I'm really happy overall with how WG is working, just some fine tuning / details to work out.

@johnpoz said in Netflix Issues over WireGuard:

Wish I could be of more help..

No worries at all - your pointers are very helpful, even if they fall on "deaf ears" here some. Only because I'm still figuring this all out

@johnpoz said in Netflix Issues over WireGuard:

Maybe your having problems with states?

It is possible! Let me try to look deeper there. I'm also a bit confused about the WG gateway, wondering if that is part of it. I do notice that even wide open WG rules aren't getting "hit" (i.e. no states / traffic), so thinking this is a return issue? But I can't seem to set the WG IP, it's "locked" to default.

Thanks!

arrmo

Hi,

Perhaps on to something - sharing some thoughts here, by all means comment if I'm out to lunch .

I re-ordered the LAN rules, thinking the more selective one (192.168.0.0/24) needs to be above the general one, or traffic to that subnet won't get to the correct gateway. Agreed?
But, it seems that my WG gateway IP is not correct? As above, I can't change it, it shows "dynamic" ... but seems to be getting set to a different client address (i.e. my mobile phone!). Huh?
I may have stated incorrectly above about changing firewall rules, and not having to restart WG. It almost seems like there is a lag, which may be fooling me. Perhaps because current states don't get erased, and until they expire it seems like all is working?

Thanks!

johnpoz

I have no idea what you think this rule would do?

When would your clients ever being going to 192.168.0 IP.. netflix sure isn't on that network. Your clients don't try and go to your WG ip ever..

When a client wants to go to say 8.8.8.8, they send the traffic with that as a destination to the mac address of their gateway (pfsense).. Pfsense says oh you want to go to 8.8.8.8 let me look in my routing table were to send that.. either my default gateway, or something other gateway based upon a policy route..

That rule has no place ever.. And would only cause you grief trying to get to other vlans you have?? If you have them.. Also would cause problems just trying to talk to pfsense for say dns, etc.

arrmo

@johnpoz said in Netflix Issues over WireGuard:

I have no idea what you think this rule would do?

LOL - NP! It was recommended that I add this one, to allow routing from the pfSense subnet, back to the OpenWrt subnet. And I realized it would never get hit as it is currently (below the pass-all rule, but with no gateway for the other subnet). Thoughts? I can see this needed to get between subnets, right? I do agree, this isn't the Netflix fix .

That said, I'm still quite concerned about the (incorrect?) WG gateway IP. But it may just be me!

Thanks!

johnpoz

Your client has no clue about some openwrt network.. You have this

internet -- wrt -- 192.168.x/24 -- pfsense - 192.168.y/24 - client

When would the client need to talk to 192.168.x? And if it did - how would forcing traffic out your wg tunnel get you there?

Do you have stuff on this transit network between wrt and pfsense? If so that is asymmetrical problem for sure, especially if not natting at pfsense to this network.

I think maybe your misunderstanding something about policy routing and need to have rules that allow traffic above your policy route rule to get to other networks, but those would not be also policy routes, and they sure wouldn't go out some vpn connection.

There should be no reason for clients behind pfsense to have a care or need to get to some transit network between pfsense and your internet gateway.. If there is - your really doing it wrong... When you have to double nat, there should really be nothing on the network between the edge device and pfsense..

arrmo

@johnpoz That (mostly) makes sense ... LOL! Not saying it's not right, I think it likely is - just my brain still trying to understand it, sorry!

I can disable that rule, NP at all. If I do ... the routing table gets updated "automatically" by WG, via the Allowed IP's - right? So then traffic does head back over the tunnel, correct?

Sorry for the dumb questions, just trying to understand how this all fits together (and play with the right "blocks" on the interface and group / tunnel, to get it all working).

Thanks for the pointers - very much appreciated!