Jump to content

Emby on dedicated server in datacenter: no connection


Recommended Posts

Posted

Hi folks,

 

I have a dedicated server running in a datacenter with some media on it. I installed the emby server on this debian 7 machine. My plan is to stream from this to my devices wherever I am (because I´m very often away on travel).

There is also a Windows VM running on this machine and I´m able to connect to the web interface via this Windows VM. But the emby server and the web interface is not available "externally" - even not with emby.connect.

My local address and my external address on are displayed the same: XXX.125.XX.64:8096

I also addet port 8096 to my iptables with:
iptables -A INPUT -d XXX.125.XX.64/32 -i eth0 -p tcp -m tcp --dport 8096 -j ACCEPT
Other services with web interface are in the iptables list the same way (like ZNC bouncer).

Do you have any idea, what I can do, to get external access to the emby server?

Again: It´s not like portforwarding the internal IP with a home based router because the server has a static IP and is directly connected to the internet.

Any ideas?

Posted

I would start simpler with your iptables, There really is no reason to define the nic or the destionition ip or subnet. And check addiational check add another check which leads to a higher even if unnotiable latency.(I've had to write few linux firewalls (bridges) each having a little over 1000 rules). So those extra checks can accutally add up.

iptables -A INPUT -p tcp  -m multiport --dports 8096,8920 -j ACCEPT

or

iptables -A INPUT -p tcp --dport 8096 -j ACCEPT
iptables -A INPUT -p tcp --dport 8920 -j ACCEPT  

Can you telnet from the localhost (aka Debian box) into those ports ?

 

What VM software are you running (XEN) ?

Posted (edited)

I tried your iptables entries without success. 

 

netstat -tna shows open port and my connection from windows vm:

tcp        0      0 0.0.0.0:8096            0.0.0.0:*               LISTEN
tcp        0      0 XXX.125.XX.64:8096      192.168.22.2:64679      TIME_WAIT

telnet shows this:

telnet localhost 8096
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

The Windows VM is a KVM Windows Server 2008 R2. It seems to be connected via internal IP 192.168.22.2 to the linux machine which has 192.168.22.1.

Edited by Tumba
Posted

If that's the case is there any chance the data-center has a first level "firewall" ? Meaning by default they only have open or route standard ports. And that you need to notify / Request them to have any others open (uncommon, but not unheard of) ? 

 

If your using kvm, then it assign (like you posted) internal ipaddress to all machines (the host + any virtual  machines). Which means at some point you will need to treat it like both like "just opening a port" and "port forwarding". You'll need to this to allow & separate the same port being used by host vs virtual(s).

 

Example : 

(opens 80 to the windows box)
iptables -t nat -A PREROUTING -d XXX.124.xxx.64 -p tcp --dport 80 -j DNAT --to-destination  192.168.22.2:80

or 

(opens 8096 to the linux box)
iptables -t nat -A PREROUTING -d XXX.124.xxx.64 -p tcp --dport 8096 -j DNAT --to-destination  192.168.22.1:8096

At first it'll appear like don't need the above as the bridge "can" be set to just forward any connections to all hosts. But this is not ideal as you'll be "internally" (meaning KVM will be) duplicating a lot of data to each guest + host that will need to ignored if they don't have open the defined port. 

 

Can you list your current iptables rule set  ?

iptables -L -n
iptables -t -nat -L -n 

Also if possble can you post the results from (fell free to mangle / obscure the real external ipaddress) 

cat /etc/network/interfaces
Posted

The Windows VM has additionally also an own external IP XXX.125.XX.66 and the internal IP 192.168.22.2 .

 

iptables -L -n

Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 0
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 8
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0            icmptype 3
ACCEPT     tcp  --  0.0.0.0/0            XXX.125.XX.64        tcp dpt:57229
ACCEPT     tcp  --  0.0.0.0/0            XXX.125.XX.64        tcp dpt:52314
ACCEPT     tcp  --  0.0.0.0/0            XXX.125.XX.64        tcp dpt:7394
ACCEPT     tcp  --  0.0.0.0/0            XXX.125.XX.64        tcp dpt:123
ACCEPT     tcp  --  0.0.0.0/0            XXX.125.XX.64        tcp dpt:55183
ACCEPT     tcp  --  0.0.0.0/0            XXX.125.XX.64        tcp dpts:30000:33000
ACCEPT     all  --  192.168.21.0/24      0.0.0.0/0
ACCEPT     all  --  192.168.22.0/24      0.0.0.0/0
REJECT     tcp  --  0.0.0.0/0            0.0.0.0/0            reject-with tcp-reset
REJECT     all  --  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

iptables -t -nat -L

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       udp  --  anywhere             XXX.125.XX.66        udp dpt:48563 to:192.168.22.2:48563
DNAT       tcp  --  anywhere             XXX.125.XX.66        tcp dpt:3389 to:192.168.22.2:3389
DNAT       tcp  --  anywhere             XXX.125.XX.64        tcp dpt:22022 to:192.168.21.2:22
DNAT       tcp  --  anywhere             XXX.125.XX.64        tcp dpt:8096 to:192.168.22.1:8096

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       all  --  192.168.21.2         anywhere             to:XXX.125.XX.64
SNAT       all  --  192.168.22.2         anywhere             to:XXX.125.XX.66

cat /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
  address XXX.125.XX.64
  netmask 255.255.255.0
  gateway XXX.125.XX.1
  broadcast XXX.125.XX.255
  network XXX.125.XX.0

auto eth0:0
iface eth0:0 inet static
  address XXX.125.XX.66
  netmask 255.255.255.0
  gateway XXX.125.XX.1
  broadcast XXX.125.XX.255
  network XXX.125.XX.0

Posted

If I'm reading this right

DNAT       tcp  --  anywhere             XXX.125.XX.64        tcp dpt:8096 to:192.168.22.1:8096

Your directing the emby traffic to your windows box, but you said 

 

 

I installed the emby server on this debian 7 machine

 

So is "installed" emby on Linux or the windows ?

Posted

Emby server is installed on Linux.

 

Linux dedicated server: XXX.125.XX.64 / 192.168.22.1

Windows VM: XXX.125.XX.66/ 192.168.22.2

 

But there seems to be a third internal IP: 192.168.21.2 seen in iptables --nat -L. A possible reason?

 

I´ll additionally ask my hoster regarding the port/firewall.

Posted

I checked telnet from external:

 

Emby server port:

telnet XXX.125.XX.64 8096
Trying XXX.125.XX.64...
telnet: Unable to connect to remote host: Connection refused
 
SSH port: 
telnet XXX.125.XX.64 22
Trying XXX.125.XX.64...
Connected to XXX.125.XX.64.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u3
 
I also changed the emby port from 8096 to 9096 (only in webinterface) but again no connection from external :-(
 
Answer from hoster: We can inform you that no ports at all are filtered in our network. This issue must be related to server level configuration.
Posted

I still think your iptables are wrong

 

you have 

DNAT       tcp  --  anywhere             XXX.125.XX.64        tcp dpt:8096 to:192.168.22.1:8096

but it should read 

DNAT       tcp  --  anywhere             XXX.125.XX.64        tcp dpt:22022 to:192.168.21.2:8096

I'm basing this off the fact that you can successfully secure shell into your linux box and RDP into your windows box. To that end see this as your setup

Linux => XXX.125.XX.64 =>192.168.21.2
Windows => XXX.125.XX.66 => 192.168.22.2
Posted

I changed to: 

DNAT       tcp  --  anywhere             XXX.125.XX.64        tcp dpt:22022 to:192.168.21.2:8096

I´m still able connect from windows VM via: XXX.125.XX.64:8096 and via 192.168.22.2:8096

But I´m no table to connect from windows VM via 192.168.21.2:8096

And I´m still not able connect from outside via XXX.125.XX.64:8096 :(

 

Is there maybe a rule/chain which exclude each other?

 

This server was set up from a friend which is admin. Is there maybe another firewall, which I don´t know? I already asked him without an answer so far...

Is there a possibility to check this?

Posted (edited)

OK NomadCF: I think I got a bit closer to a solution. My admin gave me two commands which I have to execute to run the KVM after a reboot.

/mnt/virtual/fw.sh/mnt/virtual/KVM_vm2.sh

Please find attached the fw.sh which seems to define some iptables rules!

Edited by Tumba
Posted

I changed to: 

DNAT       tcp  --  anywhere             XXX.125.XX.64        tcp dpt:22022 to:192.168.21.2:8096

I´m still able connect from windows VM via: XXX.125.XX.64:8096 and via 192.168.22.2:8096

But I´m no table to connect from windows VM via 192.168.21.2:8096

And I´m still not able connect from outside via XXX.125.XX.64:8096 :(

 

Is there maybe a rule/chain which exclude each other?

 

This server was set up from a friend which is admin. Is there maybe another firewall, which I don´t know? I already asked him without an answer so far...

Is there a possibility to check this?

 

 

No I goofed when i was copy & pasting  

 

 

My line saying  

DNAT tcp -- anywhere XXX.125.XX.64 tcp dpt:22022 to:192.168.21.2:8096

should have have been 

DNAT tcp -- anywhere XXX.125.XX.64 tcp dpt:8096 to:192.168.21.2:8096

But you should be able to still test this, from an external machine try to telnet or connecting to Emby via port 22022 on ipaddress XXX.125.XX.64

 

 

 

These commands *should* put it back for you and fix the emby port forwarding, You'll need to replace the filtered out ip with the real ones

#remove the bad rule
iptables -t nat -D PREROUTING -p tcp -d XXX.125.XX.64 --dport 22022  -j DNAT --to 192.168.21.2:8096

#establish connecting to port 22 via 22022
iptables -t nat -I PREROUTING -p tcp -d XXX.125.XX.64 --dport 22022  -j DNAT --to 192.168.21.2:22

#forward the outside port 8096 to the linux box on the same port (We really shouldn't need to though) 
#But this will fallow the way your fw.sh script flows
iptables -t nat -I PREROUTING -p tcp -d XXX.125.XX.64 --dport 8096  -j DNAT --to 192.168.21.2:8096

** Side note**

You could to just allow access in on the port 8096 in with a blanket statement below. And do away with and not have to worry about nat'ing rules above.

iptables -I INPUT -p tcp --dport 8096 -j ACCEPT

This would allow connecting to the emby server using any external IP that you have. As emby should be binding to all the available ip addresses.

Posted

I can follow what you want to set up but unfortunately this all brings no success. I will bother my admin a bit more to get him on the machine. I´ll report the progress :-)

Thanks anyway!

Posted (edited)

@NomadCF:

 

I checked "netstat -tapn" and I see a difference to other webservices which are working fine:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

tcp        0      0 0.0.0.0:8096            0.0.0.0:*               LISTEN      13516/mono-sgen
tcp        0      0 0.0.0.0:8920            0.0.0.0:*               LISTEN      13516/mono-sgen
tcp        0      0 XXX.125.XX.64:8096      192.168.22.2:60895      ESTABLISHED 13516/mono-sgen

tcp        0      0 XXX.125.XX.64:8897      0.0.0.0:*               LISTEN      5319/znc
tcp        0      0 XXX.125.XX.64:54269     0.0.0.0:*               LISTEN      5319/znc
​tcp        0      0 XXX.125.XX.64:54269     81.XX.XXX.26:7000       ESTABLISHED 5319/znc

Here I see that Emby is listening but without a local address. You can also see that an internal connection from my Windows VM to the webinterface is established.

 

Other services are like ZNC are listening with the external IP. First line is the webinterface, second line is the external ZNC port to connect to the service.

 

What do you think about this? 

Edited by Tumba
Posted

0.0.0.0 is a wildcard address, n this case it means emby is bound to any/all addressees. Where as znc is bound only to the ipaddress XXX.125.XX.64. Which mean it will only answer on that ip

 

Emby on the hand being bound to all addresses will (should) answer on all ipaddress (provided the ports are open).

 

 

Side note: Personally I think any application should allow you to define which ip addres(es) you would like it to bind to instead of assuming you want to bind it to all addresses (emby does not allow for this).    

  • 4 months later...
Posted

After weeks of doing nothing in this topic I found a solution for me:

 

I just changed both ports to something above 20.000. For whatever reason this works now and I´m able to stream my content directly from the linux machine to my raspi at home.

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