Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Netflix Issues over WireGuard

    Scheduled Pinned Locked Moved WireGuard
    50 Posts 7 Posters 13.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • demD
      dem
      last edited by

      Netflix tries to block traffic from VPNs. It has nothing to do with WireGuard or your pfSense configuration.

      johnpozJ arrmoA 2 Replies Last reply Reply Quote 1
      • johnpozJ
        johnpoz LAYER 8 Global Moderator @dem
        last edited by

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

        vpn.png

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.7.2, 24.11

        1 Reply Last reply Reply Quote 1
        • arrmoA
          arrmo @AB5G
          last edited by

          @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!

          1. LAN device on the OW LAN to Netflix and YouTube
            https://paste.ubuntu.com/p/KFbf4kWn7j/

          2. 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/

          3. 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!

          johnpozJ 1 Reply Last reply Reply Quote 0
          • arrmoA
            arrmo @dem
            last edited by

            @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!

            NogBadTheBadN 1 Reply Last reply Reply Quote 0
            • NogBadTheBadN
              NogBadTheBad @arrmo
              last edited by NogBadTheBad

              This post is deleted!
              1 Reply Last reply Reply Quote 0
              • johnpozJ
                johnpoz LAYER 8 Global Moderator @arrmo
                last edited by

                @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.

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                arrmoA 1 Reply Last reply Reply Quote 1
                • arrmoA
                  arrmo @johnpoz
                  last edited by

                  @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!

                  G 1 Reply Last reply Reply Quote 0
                  • arrmoA
                    arrmo
                    last edited by

                    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!

                    arrmoA 1 Reply Last reply Reply Quote 0
                    • arrmoA
                      arrmo @arrmo
                      last edited by

                      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!

                      1 Reply Last reply Reply Quote 0
                      • arrmoA
                        arrmo
                        last edited by

                        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!

                        A 1 Reply Last reply Reply Quote 0
                        • A
                          AB5G @arrmo
                          last edited by

                          @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
                          arrmoA 1 Reply Last reply Reply Quote 1
                          • arrmoA
                            arrmo @AB5G
                            last edited by

                            @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,

                            1. 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!
                            2. I don't think so 🤣. No packages installed that block any traffic (that I can see at least).
                            3. 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.

                            1 Reply Last reply Reply Quote 0
                            • arrmoA
                              arrmo
                              last edited by

                              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?
                              a59a8a1c-79c3-44a0-859a-351143f4092e-image.png

                              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!!!

                              1 Reply Last reply Reply Quote 0
                              • arrmoA
                                arrmo
                                last edited by 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?

                                johnpozJ 1 Reply Last reply Reply Quote 0
                                • johnpozJ
                                  johnpoz LAYER 8 Global Moderator @arrmo
                                  last edited by 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.

                                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                                  If you get confused: Listen to the Music Play
                                  Please don't Chat/PM me for help, unless mod related
                                  SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                                  arrmoA 1 Reply Last reply Reply Quote 1
                                  • arrmoA
                                    arrmo @johnpoz
                                    last edited by

                                    @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!

                                    1 Reply Last reply Reply Quote 0
                                    • arrmoA
                                      arrmo
                                      last edited by

                                      Hi,

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

                                      1. 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?
                                        36d78e42-d52a-4b5f-9e30-5b58126ad3c8-image.png

                                      2. 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?
                                        6a542144-efec-4e40-be2c-3711cca24a4c-image.png

                                      3. 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!

                                      johnpozJ 1 Reply Last reply Reply Quote 0
                                      • johnpozJ
                                        johnpoz LAYER 8 Global Moderator @arrmo
                                        last edited by johnpoz

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

                                        rule.png

                                        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.

                                        An intelligent man is sometimes forced to be drunk to spend time with his fools
                                        If you get confused: Listen to the Music Play
                                        Please don't Chat/PM me for help, unless mod related
                                        SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                                        arrmoA 1 Reply Last reply Reply Quote 1
                                        • arrmoA
                                          arrmo @johnpoz
                                          last edited by

                                          @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!

                                          johnpozJ 1 Reply Last reply Reply Quote 0
                                          • johnpozJ
                                            johnpoz LAYER 8 Global Moderator @arrmo
                                            last edited by

                                            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..

                                            An intelligent man is sometimes forced to be drunk to spend time with his fools
                                            If you get confused: Listen to the Music Play
                                            Please don't Chat/PM me for help, unless mod related
                                            SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                                            arrmoA 1 Reply Last reply Reply Quote 1
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.