Split Tunnel Issue

[skidmarks 199]

Don't know when this became an issue, but figured i'd throw it out here and see what information i get back.  Been using PIA as a VPN for many many years.  When i was on the VPN i'd have no problems as i spit tunneled emby traffic around the VPN.  

Now days when i go and use the VPN, with the same spit tunnel rule, emby jumps over to use the VPN WAN IP number instead of my public number.  Making it unable to connect outside on the WAN.

Here is the tunnel:  it used to work.

Is there another file that i need to add to the tunnel now, or is this a PIA issue?  Seems like all the rest of my tunnels still bypass the VPN when its active.

Thanks i advance.....

[Luke 42079]

Hi, does your Emby server dashboard display the correct remote address that you want Emby apps to use?

[skidmarks 199]

Hey Luke!

When i split tunneled emby with my VPN in the past it would continue to use my public IP number.  This was the correct set up for connecting remotely via the WAN.  Now when i use my VPN emby is seeing the WAN IP number change to the one that is handed out to me thru the VPN and switching to that number.  Unfortunately, when that happens remote access is killed until i turn off the VPN.  PIA has very limited port forwarding capabilities. 

So the dashboard is showing the WAN IP of my VPN instead of my static public IP number.  Which is obviously the correct thing to-do if i didnt have tunneling set up for emby to ignore the VPN. The tunnel that i was using for years, from my original post, worked flawlessly.  But not anymore. 

I was just curious if something had changed that i might need to add another file to the tunnel.  I have two other servers running thru the same VPN software and they do not change off of my public IP number, with the tunnels i have set up for them.

I have reached out to PIA (my vpn folks) to see what they have to say as well.  I was just curious if there was another file that i needed to include in my emby tunnel.

Thanks for your time Luke...

Greatly appreciated

 

Edited August 23, 2024 by skidmarks

[Luke 42079]

Hi, nothing has changed, it's that the apps are built to automatically switch between LAN and WAN addresses. What this means is that regardless of whatever address you enter to initially get connected, it will ultimately end up switching to the addresses displayed on your server dashboard.

[skidmarks 199]

I will await any responses from my VPN provider and update this if they have a solution.

I was suggesting here a few years ago that emby users might consider Private Internet Access (PIA) as a VPN service as they provided a reliable tunneling option.  That may or may not be a viable option currently.

Thanks for your time!  

[Statick 15]

I'm also having this issue trying to set Emby up with a VPN on the same system

I've set up split tunneling to make Emby and a few other apps bypass the VPN, and the other apps are all getting the correct public IP i.e the real IP of my internet connection, not the VPN

but Emby still shows the VPN IP despite this, which means it's impossible to reach it remotely. it can only be getting that IP if it's using the VPN, so it's as if the exclusion I've made for 'emby-server.exe' isn't enough and there's another .exe somewhere that needs excluding, but there are no other executable files for Emby so it doesn't make sense. would appreciate any suggestions!

 

 

 

 

 

[Luke 42079]

3 hours ago, Statick said:

I'm also having this issue trying to set Emby up with a VPN on the same system

I've set up split tunneling to make Emby and a few other apps bypass the VPN, and the other apps are all getting the correct public IP i.e the real IP of my internet connection, not the VPN

but Emby still shows the VPN IP despite this, which means it's impossible to reach it remotely. it can only be getting that IP if it's using the VPN, so it's as if the exclusion I've made for 'emby-server.exe' isn't enough and there's another .exe somewhere that needs excluding, but there are no other executable files for Emby so it doesn't make sense. would appreciate any suggestions!

 

 

 

 

 

Hi, does your split tunnel exception apply to both ipv4 and ipv6? That could be the reason why you still see the vpn ip address on your server dashboard.

Worst case scenario, you can always set your remote address in Emby Server network settings. Just be aware that when you do that, you will have to make sure to keep it up to date when it changes or else you'll have connection difficulty.

[Statick 15]

thanks that sounds like it could be the issue!

[Statick 15]

okay I've experimented with enabling/disabling ipv6 on the VPN and it doesn't seem to make a difference, each time I change a setting I reconnect the VPN and restart Emby and it still shows the same (VPN) address every time

setting the remote address in Emby doesn't work either, I've got DDNS and even with that it's not working (and this works fine to other apps). it's apparently still inside the VPN tunnel despite being excluded, not just showing the VPN address but is still connecting from inside it, which will definitely stop any incoming connections. guessing this is an issue with my VPN if there's no other exes that need excluding besides emby-server.exe?

 

Edited September 12, 2024 by Statick

[Statick 15]

just to clarify, if I disconnect the VPN I can connect remotely to Emby just fine, so the port forwarding on my router is all working as it should, and the issue is definitely with the VPN. for some reason excluding Emby in the split tunnel isn't working

 

 

[Statick 15]

I found this thread with mention of my VPN (Mullvad) and some similar issues

adding the specified line to the config file has made a difference - the emby dashboard now shows the correct remote IP and not the VPN IP. so that's some sort of progress and does make it look like IPv6 is the root of the issue

but despite this, I still cannot connect remotely with the VPN active

[Luke 42079]

Yea I think a lot of vpn software implement their exception rules for ipv4 only. Then when Emby Server makes outgoing requests, the dotnet runtime internally chooses to use ipv6 (sometimes).

[Statick 15]

sorted it - adding the above line in the config did actually resolve the problem, only for my software firewall to then start blocking it, apparently running it in a split tunnel caused the firewall to see the incoming traffic as a threat when running it with the vpn disabled was fine. all working now!

 

 

Edited September 12, 2024 by Statick