Jump to content

Emby Server over IPv6


Guest hirny199
Go to solution Solved by Guest hirny199,

Recommended Posts

Guest hirny199

Hello,

My ISP changed my IPv4 to a CGNAT, now i try to change Emby to listen to IPv6.

I testet the IPv6 Configuration with my Wiki Server, i can Ping and access the Wiki Server, i doing the same for my Emby Server it is only Pingable but not accessable not over the IPv6 and not over the DNS Name.

Is there a option in Emby that i have to change or something ?

 

Sorry for eventually bad English im from Germany.

Link to comment
Share on other sites

HI, did you figure this out? It should work out of the box. Are you sure you have the right ipv6 address? Is this a LAN address?

Link to comment
Share on other sites

Guest hirny199

hello,

the problem still exists.

the ipv6 address looks good, it is in addressrange of my fritzbox and not the fe80 link local address.

port 80 and 443 are opened on the fritzbox for the server over ipv6, use emby other ports?

Link to comment
Share on other sites

Guest hirny199

UPDATE:

I checked my opened Ports in the Fritzbox, I opened Port 8096 and 8920 because thats the Default Ports now I can connect with my Smartphone from Outside but only to the [IPv6]:8096 Address not to the [IPv6]:8920 and not over the DNS entry.

Is there the need to give Emby a Certificate File to connect to the 8920 Port? 

 

 

Link to comment
Share on other sites

9 minutes ago, hirny199 said:

UPDATE:

I checked my opened Ports in the Fritzbox, I opened Port 8096 and 8920 because thats the Default Ports now I can connect with my Smartphone from Outside but only to the [IPv6]:8096 Address not to the [IPv6]:8920 and not over the DNS entry.

Is there the need to give Emby a Certificate File to connect to the 8920 Port? 

 

 

Who is handling the ssl, emby, or a reverse proxy? If Emby, then yes, you'll need to configure an SSL certificate.

Link to comment
Share on other sites

Guest hirny199

I own a Domain with SSL ordered by Geotrust.

I dont use my Reverseproxy for Emby so i think Emby handle this but Emby wants a PKCS12 Certfile but I only can download a .pem Certfile.

Can Emby handle this Format too? 

Link to comment
Share on other sites

Hi, you can try it. We just feed it into the .net runtime. You may end up having to convert to pfx though.

Link to comment
Share on other sites

Guest hirny199

I converted my .pem File in a .pfx File because with the .pem File Emby says "not found".

With the .pfx File this Error Message dont comes up so i think Emby is fine with it.

Over DNS Emby is still unavailable and over [IPv6]:8096 available.

I can enter [IPv6]:8920 and see:

[IPv6] hat keine Daten gesendet.

ERR_EMPTY_RESPONSE

Link to comment
Share on other sites

Guest hirny199

If you can say me the log Path of Emby i can post some Logfiles.

Searching the Error Message in the Internet dont helped me because i dont find exactly my Problem case.

Link to comment
Share on other sites

Guest hirny199

the Server Machine is a Ubuntu Server VM i dont know if i can access the web interface via commandline but i think not.

But i can access the Web Interface over port 8096 over the ipv6 from everywhere and over the private IPv4 with port 8096.

With the private IPv4 and port 8920 i receive the same response as posted before.

Link to comment
Share on other sites

Guest hirny199

hi @Luke,

no at the moment thevproblem still exists.

At the Weekend i try a LetsEncrypt Certificate and see if my Certificate was the Problem.

 

Link to comment
Share on other sites

  • 2 weeks later...
On 8/3/2022 at 2:29 PM, hirny199 said:

hi @Luke,

no at the moment thevproblem still exists.

At the Weekend i try a LetsEncrypt Certificate and see if my Certificate was the Problem.

 

Hi, how did this go?

Link to comment
Share on other sites

Guest hirny199

hello,

sorry for the late response 😕

i created a .pfx certfile from letsencrypt, emby accept this cert but the error message is the same as before.

 

 

Link to comment
Share on other sites

  • 3 weeks later...
Guest hirny199

the cert is mapped to a domain name, if i nslookup the domain name the ipv6 is the same as the ipv6 of the server so i think the dns itself works.

Link to comment
Share on other sites

@hirny199 I see you can get to other services you're running on IPv6 so it appears your CGNAT issue is gone now.

On Emby Console for local and remote URLs is the remote showing as the domain name?
Depending there are a few things you can do to test.  One would be to remove the cert and cert password as well as set it back to allow unencrypted traffic.

The console after a restart should show the IPV6 address for remote. Give that a test remotely using port 8096.  This will help with the first steps of making sure you can get to the Emby Server.  If the console is still showing an IPV4 address then the next step would be to assign the IP you Want Emby to Use.

If that doesn't work or it still seems "locked" on IPv4 the next thing I would try is removing IPv4 from the server machine using only IPv6 and try again.

Let us know how this goes.

Carlo

 

Link to comment
Share on other sites

Guest hirny199

thanks for your reply, the emby server shows up if i use the ipv6 with port 8069 but this is the unsafe way , my problem is that i recive the error above when i try to connect via 8920

 

i will try to host the emby instace on a new server that is only connectet via ipv6 i will answer when i tried it

 

thank you very much @cayars

Link to comment
Share on other sites

Guest hirny199

Hello,

I Removed the Cert and the IPv4 Address from my existing Server.

After a Restart the Emby URLs show my IPv6 Address in LAN and my Domainname in WAN.

I can Connect with the IPv6 Address from my Home Wifi and from a Hotspot Wifi over my Smartphone both over Port 8096.

 

Link to comment
Share on other sites

Great, so port 8096 is working as expected with IPv4 removed.

Multiple paths you could go in, but if it were me I would next add IPv4 back to the machine, reboot and verify 8096 is still working. An easy/quick way to test is using a mobile phone that has WIFI turned off so you are using a cell network.  You don't need to burn data just try to connect.

If my thinking is correct IPv4 will be added back and not cause an issue as most OS give priority to IPv6 over IPv4 by default.
Right now we know using IP not domain that IPv6 is working for you in Emby remotely over port 8096.

What I would try next is using your domain name and port 8096 remotely to remove the domain name itself as the problem. http://emby.yourdomain.ext:8096 or http://yourdomain.ext:8096 depending on if you have a sub domain setup.

If it works were down to secured port or cert setup as the problem. If that test doesn't work, then the domain is likely pointing to the wrong IP so you will need to check/fix it.

Assuming that works, we need to pick a port to use for SSL and the Emby default is 8920 but you can use 443 almost as easy (what I use). It really doesn't matter the port used BUT you need to configure the firewall to forward CHOSEN port to Emby Server port 8920.  If you used 8920 it's WAN/8920->Emby/8920 but if you use 443 like me it will be WAN/443->Emby/8920.
In network settings the public port for SSL will be the same port your WAN is looking for (8920 or 443 in these examples).  That might sound a bit tricky but think of it this way.

Emby will use the port specified in network settings for SSL public to mark the outgoing traffic.  That will make the remote client answer back on that port.  That will be the port your router will see on the WAN side.  Regardless of port it still forwards to 8096 for Emby Server because it will listen there.

With that noted, review your router setup for port forwarding of the SSL port to make sure it's listening to the correct port on the WAN side and make sure it forwards to the IP of the Emby Server inside your network to port 8096 (won't change regardless).  Just to be clear without the use of a reverse proxy server inside your network doing redirection each port used must be unique. So in order to use 443 make sure nothing else is defined in port forwarding with that port. 8920 will be the safe bet and it's almost always available.  I use 443 for one reason only. Browsers by default use port 80 for non SSL traffic and 443 for encrypted traffic. Using either of those two ports allows the URL to not have to include the port number https://emby.domain.ext vs https://emby.domain.ext:8920.  No other reason than that.  If using an Emby app (not browser) you will enter the port regardless.

The only big items left that could cause a problem is the cert itself and password.  You will almost certainly need to convert the cert from the format given to you to a PK#12 format that uses a password (don't leave the password blank).  The password used during the conversion needs to be enter in Emby as well (network menu).  You can try setting "Secure connection mode:" to Preferred, but not required to allow fallback, but once the cert & password are working, I would make the setting use the "Required for all remote connections" setting as well as remove the non SSL/secured port (8096) from forwarding on the router.

If you think you might have had an issue trying to convert the cert properly send me a private message and I'll have you send me the info needed and I'll convert it to PK#12 format for you (if that would help).

You're close and really shouldn't have anything stopping you from getting remote working. Let us know how far you make it on the above and if needed we can always do a TeamViewer session to help you finish this off.

Carlo

Link to comment
Share on other sites

Guest hirny199

Hello,

I tryed to connect via the Domainname sub.mydomain.de and sub.mydomain.de:8096 and it shows "dns probe finished nxdomain".

On my Domain the AAAA Record is set to the right IPv6 Address, if i use nslookup over Mobiile Wifi or specify Googles 8.8.8.8 DNS as setting the right IPv6 shows up but pings dont work.

I think something is wrong with my Domain because the MXTools Website says that the DNS Record is not publishedimage.png.0e9bb0c8c95962a60ac5cd7a0c8d5f74.png

Tomorrow i try to figure out if the Domain Support have any Ideas to solve this Problem.

I write the result down here.

 

Daniel

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