Jump to content

Can't connect using VPN even though web browser works


TheShanMan

Recommended Posts

VPNs can be tricky. That's why we have the network options so that you can customize what the local network is considered to be in the event that you need to.

Link to comment
Share on other sites

TheShanMan

But the help text suggests my VPN subnet should be covered by default. It's not doing what it says it does.

Link to comment
Share on other sites

I've asked a couple of times for your specific IPs your using internally because I was going to have you try a couple of things which would shed light on this.

Specifically, running VPN on the router itself might be doing a NAT on the IP before it gets to the Emby Server. Of course it matters if using IP or domain name to connect as well. There are a few different things that could come into play with a setup like this but Emby is flexible enough to adjust if needed.

 

Link to comment
Share on other sites

TheShanMan

 

1 hour ago, Luke said:

The help text does not say anything about a vpn.

No, but it does talk about private subnets, and the vpn is using a private subnet. So from emby's standpoint, the fact that it's a vpn is irrelevant as far as I can tell. It's just not on the same subnet as emby server. When I said the help text suggests my VPN subnet should be covered, another way I could've said it is 10.8.0.0 should be treated as part of the local network according to the help text, yet it isn't. I had to explicitly specify it, in addition to the subnet my server is on: "10.0.0.0/8, 192.168.0.0/16". Furthermore, the help text says "192.168.0.0/24" but it should say "192.168.0.0/16".

 

49 minutes ago, cayars said:

I've asked a couple of times for your specific IPs your using internally because I was going to have you try a couple of things which would shed light on this.

Specifically, running VPN on the router itself might be doing a NAT on the IP before it gets to the Emby Server. Of course it matters if using IP or domain name to connect as well. There are a few different things that could come into play with a setup like this but Emby is flexible enough to adjust if needed.

 

Sorry I guess I didn't quite understand what you were after. My main subnet on which my server is running is 192.168.1.0 and the server is 192.168.1.98. The vpn subnet is 10.8.0.0 (i.e. my router assigns 10.8.0.0 addresses to vpn clients). I've stated all that previously but perhaps not all in one statement. What I haven't stated because I didn't realize what you were seeking is that emby does see the vpn clients as 10.8.0.x. I see it in the log. There isn't any nat. That's why I had to add "10.0.0.0/8"  to that field (even though emby should be doing that automatically). Also, I've been using the IP to connect just to eliminate any issues with name resolution.

 

Edited by TheShanMan
Link to comment
Share on other sites

OK you did just answer a few things I was going to ask as well, so thanks for that.  Just out of curiosity, from a VPN address what do you get when you tracert to 192.168.1.98 ?

Is it one hop between the two IPs?

Link to comment
Share on other sites

Q-Droid
59 minutes ago, TheShanMan said:

 Furthermore, the help text says "192.168.0.0/24" but it should say "192.168.0.0/16".

 

Those are just examples in the text of private subnets and the CIDR notation that can be used. The size of any given subnet is up to the owner, whether /16, /24, etc. Had you used 192.168.1.0/24 and 10.8.0.0/24 it would have also worked, you just shifted to the next octet.

I think the disagreement might be over this part:

"If left blank, only the server's subnet and common private IP subnets (10.0.0.0/8, 192.168.0.0/24, etc.) are considered to be on the local network."

It seems to imply that all private subnets are simultaneously allowed and considered local LAN when it appears to only apply to the current subnet the server is on and listening. So is this what is actually going on? It didn't work for the OP until both subnets were added to the field.

 

Link to comment
Share on other sites

TheShanMan
50 minutes ago, cayars said:

OK you did just answer a few things I was going to ask as well, so thanks for that.  Just out of curiosity, from a VPN address what do you get when you tracert to 192.168.1.98 ?

Is it one hop between the two IPs?

Sorry, I don't have tracert ability on my phone and having returned from my trip, my computer no longer has a convenient means of connecting to the vpn since it's inside my lan. FWIW though, my vpn is running on my dd-wrt router, and is a pretty standard configuration, so I suspect there are plenty of other emby users who have a similar setup. Perhaps you're simply curious about my configuration but again, my issue is better described as a secondary subnet issue than a vpn issue, so in terms of the bug I ran into, the vpn aspect of my setup is a red herring in my view.

17 minutes ago, Q-Droid said:

Those are just examples in the text of private subnets and the CIDR notation that can be used. The size of any given subnet is up to the owner, whether /16, /24, etc. Had you used 192.168.1.0/24 and 10.8.0.0/24 it would have also worked, you just shifted to the next octet.

I think the disagreement might be over this part:

"If left blank, only the server's subnet and common private IP subnets (10.0.0.0/8, 192.168.0.0/24, etc.) are considered to be on the local network."

It seems to imply that all private subnets are simultaneously allowed and considered local LAN when it appears to only apply to the current subnet the server is on and listening. So is this what is actually going on? It didn't work for the OP until both subnets were added to the field.

 

Yeah I know I could've specified the local networks in a more specific manner like that. I figured for the sake of illustrating the bug, I would specify what emby claims to be (or should be) using as a default value for that field.

Yes, that's the disagreement with the help text (in addition to the /16 vs /24 part). 10.8.0.0 is covered by 10.0.0.0/8 so according to that text, I shouldn't have to specify it explicitly. And yes, it appears that what's actually happening is only the server's subnet applies. So yes, you're correct in all of that.

Link to comment
Share on other sites

I'm not sure what's wrong with the text as it does say:
If left blank, only the server's subnet and common private IP subnets (10.0.0.0/8, 192.168.0.0/24, etc.) are considered to be on the local network.

If you can try the tracert the opposite way.  Do a tracert from the server to the phone when it's on VPN.
Once I've got that info I'm going to setup a test with VPN on a dd-wrt router the same way.  Are you using OpenVPN?

Link to comment
Share on other sites

TheShanMan

Yeah, it's OpenVPN. Tracert from the server first hop is to the router/vpn server. Then the requests time out beyond that (stopped it after 16).

What's wrong with the text is twofold:

  1. 192.168.0.0/24 excludes anything but 192.168.0.x. So the implication is that 1.x, 2.x, 3.x, ..., 254.x wouldn't be included. Granted, most people probably won't even notice that (I didn't at first!), and it does also say "etc" so strictly speaking you could say it's not wrong. But why not just change it to 192.168.0.0/16 and drop the "etc" (I think those are the only common private subnets). Then it would be precisely accurate... if #2 below is also fixed.
  2. It says "the server's subnet and common private IP subnets". The 2nd part of that is false. Either it should be dropped from the text or (my preference/opinion) the server needs to be fixed so the 2nd part is true.

Thanks!

Link to comment
Share on other sites

It says if you set this then only what you set is considered local "If set, all other IP addresses will be considered to be on the external network"

If you leave it blank then it will use the current network Emby finds plus the private address spaces:
Class A 10.0.0.0 — 10.255.255.255
Class B 172.16.0.0 — 172.31.255.255 
Class C 192.168.0.0 — 192.168.255.255

Edited by cayars
Link to comment
Share on other sites

Happy2Play
11 minutes ago, cayars said:

Class 😄 192.168.0.0 — 192.168.255.255

But that is not true with /24 that is /16.  Discussed in multiple topics.  So is the note "/24" wrong?  Just like the other topic discussion on 172.58.x.x network being considered as local.

Overall the most of the network quirks are resolved by assigning them in the field provided.

Edited by Happy2Play
  • Like 1
Link to comment
Share on other sites

TheShanMan

Yeah, forgot about 172.16.0.0. Haven't seen a reference to that in many years for some reason.

Link to comment
Share on other sites

1 hour ago, Happy2Play said:

But that is not true with /24 that is /16.  Discussed in multiple topics.  So is the note "/24" wrong?  Just like the other topic discussion on 172.58.x.x network being considered as local.

Overall the most of the network quirks are resolved by assigning them in the field provided.

Yes I'd say the help text is wrong assuming the Server actually supports the full private range as it should be this:

10.0.0.0/8 IP addresses: 10.0.0.0 – 10.255.255.255
172.16.0.0/12 IP addresses: 172.16.0.0 – 172.31.255.255
192.168.0.0/16 IP addresses: 192.168.0.0 – 192.168.255.255

@Luke the help text in the server network settings should be changed and specifically say:
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

Edited by cayars
Link to comment
Share on other sites

TheShanMan

Cool. Looking forward to the results of your testing. I'm assuming you'll also find that secondary subnets aren't being treated as local unless you explicitly specify them. Then that bug can be addressed to. Appreciate you having a look at this!

Link to comment
Share on other sites

So you want your 10.x VPN range to be treated as local devices vs remote correct?
In my normal VPN use I have the VPN clients setup like remote clients so I would not have the 10.x space included.

Link to comment
Share on other sites

TheShanMan

Correct. Otherwise they would be forced to use https, which would mean double encryption. This is a family only VPN so I have no need to create a second barrier.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...