Jump to content

Bind a local IP


pgriffith

Recommended Posts

pgriffith

Is there a way to bind Emby Server to use a particular local IP ?

 

I have recently setup a VPN service on my Emby Server/Download/Torrent box to become a bit more anonymous.

 

When the VPN is active (24/7) on a Virtual NIC, Emby wants to use this IP instead of the IP of the physical network card.

 

Clients setup to search for the server fail to connect on this new IP. I can still connect on the original local IP, I just want to stop Emby from advertising the new VPN address.

 

Cheers

Link to comment
Share on other sites

AgileHumor

If you have Windows 8 Pro, you can host a small virtual machine (VM) that can have it's own gateway as a child of that VM..

 

I have Emby Server on my HTPC, and then a Virtual Machine with NZBGet, Utorrent, CP, and Sonarr running on it.   In my setup, I actually route all that VPN traffic to a cheap internet connection from cable company...separate from my main internet on another vendor...something you can't do unless it's on isolated machine.   I've locked it down the routing table to only allowing local LAN access and only 4 external IP addresses (VPN and Newshost)...unless it's connected to the VPN.

 

This allows me to connect on the local LAN to the VM's the web interfaces to control...and the virtual machine "lockbox" just exports the files to my HTPC where Emby will discover it. 

Edited by AgileHumor
Link to comment
Share on other sites

  • 3 months later...
Scott Kemp

I run mine in a VMware environment and have the same issues with IP/Adapter binding, the only way I can get the MB Server to work correctly is to order the bindings with a metric and then configure UT to use the specific IP address on a higher cost binding with the VPN connection. I might say that this is a real pain as the IP changes ever time I log into the VPN. Sure would be nice if there was a option like in IIS on Windows with a dropdown box of all active IP's and allow all or a specific IP to bind to.

Link to comment
Share on other sites

  • 4 months later...
rhodges

Is this a feature that can be added sometime in the future? I have a couple IP addresses assigned to my server, for various reasons. I would like to have Emby to only bind to one of them. Even if I have to hand edit a config file, that would be fine with me.

Link to comment
Share on other sites

shorty1483

You guys can change the priority of adapters , Emby will choose the one with highest.

 

Gesendet von meinem HTC One M8 mit Tapatalk

Link to comment
Share on other sites

  • 2 months later...

Hey pgriffith (OP),

 

Similar to what AgileHumor mentioned, I used rules on my firewalls (Netgear Router and Windows Firewall) to direct traffic to the specific IP address I wanted Emby to respond on.

 

Please let me know if you'd like more details on my setup!

Link to comment
Share on other sites

carlbme

Binding to all IPs makes sense. Using your media server as a seedbox doesn't make sense. If you're limited by the number of computers then I'd suggest to do as AgileHumor states. HyperV is built into most versions of Windows and will allow you to run a VM from within your main box. So just go in, check the box in Features to install HyperV, reboot, setup a new VM. Once done, login to that VM and then set that up with the VPN connection using the virtual adapter in HyperV.

 

I haven't tried it, but I believe it should work fairly easily as your network will see the two IP addresses as two separate machines.

Link to comment
Share on other sites

kingy444

@@carlbme

Why does linking to all IPs make sense so much that we couldn't have the option to bind to a single

 

We already have the option to alter ports etc. Why not just add a tick box on that page that says "bind to all local IPs" and unticking it would allow you to bind to a single specified IP?

 

I wouldnt think it would be that hard of a change with the rest of the network communicaion freedom we have.

Every other media server i have used has let me choose this?

  • Like 2
Link to comment
Share on other sites

carlbme

@@kingy444

 

I agree, I see no issue with having this option. Except maybe that it would only be used by a few people, could possibly cause more issues than not for users who don't understand it. And with a limited number of users who might have the need for it, then the resources needed to develop this might be best put to use elsewhere.

 

That said, my post was more of a statement that using the one logical machine to do everything was unwise, and having the NEED to set a specific network interface for that reason was not much of a valid reason as a whole.

Link to comment
Share on other sites

rhodges

@@carlbme

 

I could say the same about other features of the application. I don't begrudge features that I don't need. I think spinning up a VM and allocating the resources needed for that VM as unwise. We each have our own opinions of unwise.

 

I don't have a second nic on my computer. I assigned it another IP address. I use that IP address exclusively for another application and that makes QoS a lot easier to manage. Because Emby binds on both addresses. I don't want that. For me, does it hurt anything? Nothing but my OCD. I am a .NET developer myself. It would take fewer lines of code in the server to implement than 1/3 of this conversation. It would be even less if you didn't want to expose it thru the UI, and wanted to leave it in a config file, or something out of the way like that.

Link to comment
Share on other sites

  • 3 weeks later...
kingy444

@Luke do you think we could have something like this included on the feature requests list. Wouldnt expect many lines of code to accommodate?

Link to comment
Share on other sites

  • 1 month later...
mcberry22

I have the same issue.  I have to have my server as duel purpose and I find that port 8096 is binding to all my virtual ip addresses making connectivity to the server through the web browser almost impossible.  I have to bounce the service most times to get it to connect.  I seem to have issues with reliable recording also... not sure if this would affect that too as I would think it is not related.

 

Now that I finally know what is going on, this program is completely useless to me util you can implement a fix to bind to a particular ip address.  I think you WAY under estimate how many people need this feature and although I am no programmer, it does seem like it should be an easy fix.  Are there any plans to add this feature?  I just paid for lifetime membership and now I cant use it.

 

Regards,

Link to comment
Share on other sites

dcook

I agree it would be nice to define which IP address the EMBY service is using if required, however your statement that the program is completely useless in its current state is rather harsh, I have 3 physical nics in my server, and yes EMBY is listening on all 3 of them and I have not had any issues.

 

I actually found it could be useful as I have some clients in my house configured to use 1 ip and some others using the 2nd ip (3rd ip is used for internet access) this allows me to split the load for streaming, I don't know if it is really necessary as they are all 1GB Nics but its all working well so far.

Link to comment
Share on other sites

mcberry22

You are correct in that it was a "little" harsh and I apologize to all.  I am just frustrated because when I want to connect to the web client I am unable to as it just sits there and spins. This happens numerous times throughout the day.  I have to bounce the service in order to get connectivity to it and if I am in the middle of recording, it kills it.  So far, (only tried it yesterday for first time) I found that if I kill my virtual box services so the other 3 sockets that were created by the 0.0.0.0:8096 statement are not established, everything seems to work ok.  (I have 3 NIC's in my server) I dont know why I did not think of this sooner.  

 

It seems like the port is in use by another service, but I would think that none of those other sockets should be communicating on that port as there is nothing to call that port.  The only one using it should be the one with my server address on eth0.  I have nothing configured on the other 2 and I am just using them for Virtual box.

 

mcberry22@MLAB:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 40:8d:5c:5a:40:e6 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 68:05:ca:3e:de:84 brd ff:ff:ff:ff:ff:ff
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether 68:05:ca:3e:e1:b8 brd ff:ff:ff:ff:ff:ff
5: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
6: vboxnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 0a:00:27:00:00:01 brd ff:ff:ff:ff:ff:ff
7: vboxnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 0a:00:27:00:00:02 brd ff:ff:ff:ff:ff:ff
 
 
mcberry22@MLAB:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 40:8d:5c:5a:40:e6  
          inet addr:192.168.1.118  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fd00::428d:5cff:fe5a:40e6/64 Scope:Global
          inet6 addr: fe80::428d:5cff:fe5a:40e6/64 Scope:Link
          inet6 addr: 2601:282:880:667:428d:5cff:fe5a:40e6/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:167906 errors:0 dropped:0 overruns:0 frame:0
          TX packets:97323 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:157077019 (157.0 MB)  TX bytes:25753105 (25.7 MB)
 
eth1      Link encap:Ethernet  HWaddr 68:05:ca:3e:de:84  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:18 Memory:fe6c0000-fe6e0000 
 
eth2      Link encap:Ethernet  HWaddr 68:05:ca:3e:e1:b8  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:19 Memory:fe5c0000-fe5e0000 
 
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:68250 errors:0 dropped:0 overruns:0 frame:0
          TX packets:68250 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:41707604 (41.7 MB)  TX bytes:41707604 (41.7 MB)
 
vboxnet0  Link encap:Ethernet  HWaddr 0a:00:27:00:00:00  
          inet addr:192.168.56.1  Bcast:192.168.56.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:224 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:33198 (33.1 KB)
 
vboxnet1  Link encap:Ethernet  HWaddr 0a:00:27:00:00:01  
          inet addr:192.168.57.1  Bcast:192.168.57.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:200 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:31692 (31.6 KB)
 
vboxnet2  Link encap:Ethernet  HWaddr 0a:00:27:00:00:02  
          inet addr:192.168.58.1  Bcast:192.168.58.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:121 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:19335 (19.3 KB)
 
 
 
This is how it starts out looking when I just bring up Emby web client:
 
mcberry22@MLAB:~$ netstat -na | grep 8096
tcp        0      0 0.0.0.0:8096            0.0.0.0:*               LISTEN     
tcp        0      0 192.168.1.118:58248     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58244     ESTABLISHED
tcp        0      0 192.168.1.118:58242     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58248     ESTABLISHED
tcp        0      0 192.168.1.118:58256     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:58250     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58242     ESTABLISHED
tcp        0      0 192.168.1.118:58244     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:58246     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58246     ESTABLISHED
tcp        0      0 192.168.1.118:58252     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58256     ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58252     ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58250     ESTABLISHED
 
 
Then it shows like this:
 
mcberry22@MLAB:~$ netstat -na | grep 8096
tcp        0      0 0.0.0.0:8096            0.0.0.0:*               LISTEN     
tcp        0      0 192.168.56.1:8096       192.168.56.1:43470      ESTABLISHED
tcp        0      0 192.168.1.118:58248     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58244     ESTABLISHED
tcp        0      0 192.168.1.118:58242     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58248     ESTABLISHED
tcp        0      0 192.168.57.1:8096       192.168.57.1:60724      ESTABLISHED
tcp        0      0 192.168.1.118:58272     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.57.1:60724      192.168.57.1:8096       ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58272     ESTABLISHED
tcp        0      0 192.168.58.1:8096       192.168.58.1:56326      ESTABLISHED
tcp        0      0 192.168.1.118:58250     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58242     ESTABLISHED
tcp        0      0 192.168.1.118:58244     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:58246     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:58260     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.58.1:56326      192.168.58.1:8096       ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58246     ESTABLISHED
tcp        0      0 192.168.1.118:58252     192.168.1.118:8096      ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58256     TIME_WAIT  
tcp        0      0 192.168.56.1:43470      192.168.56.1:8096       ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58260     ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58252     ESTABLISHED
tcp        0      0 192.168.1.118:8096      192.168.1.118:58250     ESTABLISHED
 
 
 
Link to comment
Share on other sites

  • 4 weeks later...

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