Netflix Issues over WireGuard
-
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!!!
-
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?
-
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.
-
@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!
-
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!
-
-
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.
-
@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!
-
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..
-
@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!
-
What do you wan to do with your wg connection? Do you want to route all traffic out it, just some traffic?
Unless the upstream vpn provider knows about all your networks (which would for sure conflict with the other clients using the vpn service) You would need an outbound nat your networks to vpn network IP.
Just like you do in any other vpn connection. Just like you do on your normal wan connection. Pfsense nats your networks IPs to the IP of the connection.
If you setup wg to be your default route, then you wouldn't need to policy route, other than stuff you don't want to go down the vpn. If you don't have wg setup as your default route, then you would need to route traffic you want to go out that connection.. Your going to need an outbound nat in there somewhere..
Policy routing depends on what you want to do, and how your doing it. The protocols and methods used in wg doesn't really matter. When it comes to routing.
Not sure what guide you followed, or what service your using that provides wg as a method of connecting. But when it comes to routing and firewall rules - what you use for the tunnel.. What needs to be understood are you going to send all traffic down this tunnel or not?
My "guess" to your netflix issues or any other issues some other sites would be you messing with rules and having states, and then changing new connections to take a different route, etc.
You mention a phone? Not sure how that comes into play at all.. Why don't you draw up your network with this wrt, where your wifi comes in... And exactly your wanting to use wg.. I could see all kinds of issues if your wifi is of your wrt, and pfsense is downstream of that and your connecting to this wifi trying to connect to wg running on pfsense, and then send it down another wg connect to some vpn service to get to the internet?
-
@johnpoz said in Netflix Issues over WireGuard:
What do you wan to do with your wg connection? Do you want to route all traffic out it, just some traffic?
Thanks for taking the time to explain this, it does help! Let me try to clarify. FYI, this is a bit of a follow-on, to getting the basic setup working (first) ... captured here. But not expecting you to go through that, let me try to summarize!
Yes, I am trying to route all traffic over the WG connection. I know that WG relies on peer connections, but to make explaining easier, let me use the server and client terms. Hopefully why will become clear in a minute .
I have a pfSense machine ("server") here beside me, and a remote OpenWrt (OW) "client" (child away at university - LOL!). So trying to route all the remote (client) traffic through my local pfSense firewall. I have WG up and running, and basically working pretty well - in fact, if I ssh in to the OW box itself, I can get to the internet, everything seems to work. Where I have been having issues is with the subnet (DHCP clients) hanging off of the OW router. Clear so far?
A bit more detail to help - the local subnet (behind pfSense) is 192.168.2.x (and the cable modem, WAN side of pfSense, is 192.168.1.x). The remote OW subnet is 192.168.0.x. For WG, pfSense is 192.168.253.1, OW is 192.168.253.3 (and another WG client, my mobile, is 192.168.253.2 ... odd that this is the WG GW address that pfSense shows - hence the comment above, but that may be a red herring).
Hopefully still clear. Now, I have assigned wg0 on pfSense to an interface (WG), so in the pfSense Rules I do see WG (interface), and WireGuard (application / group). If I pass all traffic on WireGuard, Netflix works just fine. But if I don't, and instead do it through WG (the interface) ... nope, issues then. Here are the rules I was recommended to add to pfSense (WG interface),
As you mention, I also have Outbound (Hybrid) NAT set up for the OW subnet, as it's not NAT'ing on the OW side. Here is that setup (and of course, on top of this I have the Automatic Rules) - BTW, I did ask, and I was told that the"Interface" here is supposed to be WAN, not WG (right?),
Still with me? Hopefully I'm explaining this OK. I agree with the recommendation that was mentioned in the other thread ... use the WG interface to ensure reply-to is enabled, but it seems to be part of my issue (as setting pass-all instead on WireGuard (group) allows Netflix to work).
Thoughts? Something here I have all messed up / misunderstood.
Thanks for the patience! And sorry for the long-winded summary .
-
So you have a remote device using wrt running WG that you want to connect to pfsense, and get to stuff on your network, like a nas or plex server?
Not sure why you want to route traffic from this remote wrt box through your internet connection.. Why would you not just let them use their own internet, and only route through the wg vpn for access to your local stuff?
You want to route your internet through wg to this remote wrt box? Why?
Still at a loss to what your wanting to accomplish
you have
child - wrt --- internet (wg vpn) --- pfsense -- your network
Why would child not just use their internet, and pfsense use its internet. The wg is for you to talk to stuff on child network, and for child to talk to your network.
Why would you route netflix through wg or anything other than your 2 networks??
-
@johnpoz Two reasons actually ,
- There have been a lot of security related issues with the university residence network - so I'd feel safer if all of her traffic comes back through here. Ya, it may just make me feel better ... LOL!
- The residence network does seem to have issues with a lot of things - almost any streaming video and audio is broken (even though they say it's fine, and the service is 100 Mb/s!). She can't even stream music to her Google Home Mini, and forget about Netflix (but I pay for 4 Netflix users ... arrgh!).
-
Not sure how you think streaming through your internet would make that faster? If they have a shared internet of 100mbps shared among how many students? Yeah its prob going to suck, routing through that internet to you isn't going to make it faster.. If anything slower..
The only reason to route their stuff through your internet would be circumvention.. She is behind a router, she is just as safe there as she is routing traffic through you.
-
@johnpoz Ya, I'm not sure it's speed - I tested, and she gets ~ 40 Mb/s back to here. Their DNS is really messed up, that I have seen / checked.
If this isn't going to work I guess I can go back to OpenVPN. That was working, it just requires a router reboot every couple of days (not sure why ... it's solid when running, just burps at times). And I admit, WG seemed like a challenge, so now it's more about proving I can get it working. Ya, I'm stubborn ... LMAO!
Thanks!
-
@arrmo said in Netflix Issues over WireGuard:
. 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!
also
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).
It's always the Same IP? You didn't have an interface for OpenVPN ?
Are you sure you were actually sending any traffic down either VPN? THose comments plus the firewall rules you posted.. not sure it could ever have worked.BTW - when Netflix blocks you for VPN / Proxy, it tells you. It doesn't just not work.
-
@griffo said in Netflix Issues over WireGuard:
You didn't have an interface for OpenVPN ?
Correct. I didn't know better . I did have firewall rules though, for the group ... so that way traffic was not blocked (over VPN).
@griffo said in Netflix Issues over WireGuard:
Are you sure you were actually sending any traffic down either VPN?
Pretty sure ... LOL! I say that because,
- what is my IP => gives me the pfSense internet IP
- I do see traffic in the Rules (states) of OpenVPN (group)
- traceroute to google.com, from OW => goes over the OpenVPN N/W
@griffo said in Netflix Issues over WireGuard:
BTW - when Netflix blocks you for VPN / Proxy, it tells you. It doesn't just not work.
Yes, it's just plain timing out. And it's not only Netflix ... she can't even get to some local sites there (that don't need anything special).
Thanks!
-
And what is odd ... if I just add a rule on the group (not interface), then it works ... Netflix that is, still some sites don't. That makes my head hurt .
-
You mention local sites - at the school? Yeah those would prob be broken if your going to send traffic down the vpn.. You would have all those not to go through the vpn..
This gets complicated very quickly - I personally do not see what the point would be other than access to local stuff on your network.
Netflix could also have issues with dns.. I don't know if netflix has started doing this - but a method to prevent geoip circumvent could be to not prevent access to IPs from different regions..
So with how dns can work with CDNs - like netflix, is your query comes from region A of the world.. It points to IPs in Region A.. If your query comes from region B, you get handed Region B IPs.. But if your trying to talk to Region B ip from Region A you could be blocked.
So with what your trying to do - you could have all kinds of issues going on, where are you pointing the wrt clients to for dns? Where is your vpn exit point, etc.
How you route traffic down the wg vpn from the client to you, would be different than how its done in openvpn.
Before you go playing with your wrt end, I would just set it up to test with your phone using your cell connection.. As you test client.
-
@johnpoz said in Netflix Issues over WireGuard:
You mention local sites - at the school?
Agreed! I was thinking that, but they are public sites - I can get to them from here (i.e. sitting on the pfSense subnet). Of course that may just be confusing me.
@johnpoz said in Netflix Issues over WireGuard:
Before you go playing with your wrt end, I would just set it up to test with your phone using your cell connection.. As you test client.
Agreed! I have my phone doing that, routing all traffic ... and it works like a champ (of course ... LOL). It's also the case that the router itself works fine - but I think it directly accesses WG on that end. It's just DHCP clients on the OW subnet, they are the only ones having issues.
Part of my confusion is that Netflix (my test site, as I know it breaks sometimes) works fine if the rule is applied to the tunnel, but not the interface. So I can make it work, but now it's just annoying me, and I don't like things I don't understand ... LMAO! So not a huge issue, as I say - an annoyance. But I'd also like to figure it out, so others can learn from it, avoid the pain in the future. Paying back for the help folks have given me. So part of me doesn't want to stop, but part of me also knows it may not be worth the fight .
Thanks!