Jump to content

is there a way to change local http or https port in emby server ?


turpentine
 Share

Recommended Posts

turpentine

hello friends, i have a networking question about emby server

emby-server-synology_4.7.1.0_x86_64.spk

during the night my telco operator changed my box firmware and has desactivated full stack ipv4 with port redirection menus and force my ipv4 to IPv4 CGNAT, with the same ipv4 on mutltiple customers. so i cannot redirect any external ports to my local emby server internal ports anymore in ipv4. this is the bads news

the good news is that i have now ipv6... with firewall rules that autorises incoming ipv6 tcp connexion.

the bad news is that in the home router incoming ipv6 interface rules allows to input only the tcp external port  and only the public ipv6 adress of my emby server without changing it to something internal. i have not the possibility to specify another internal port as HTTPS port 8920 by default, when pointing to my ipv6 emby server. it is likely with ipv6 external port = internal port with most ipv6 only routers.

firewall or cloudflare usually accept only 443 8443 for https.. so incoming tcp connexion will arrive directly only 443 or 8443 with ipv6 directly on emby servers with no nat at all.

is there a way to change emby internal local port 8920 to be the same as https external port 8443 in emby server due to direct ipv6 ?

or more simple question, is there a parameter in emby server to have the same internal port as external port in emby due to damned ipv6 :)

thanks a lot and have a nice day

 

 

 

Edited by turpentine
Link to comment
Share on other sites

seanbuff

Manage Server > Network

You have plenty of options to play with there.

  • Like 1
Link to comment
Share on other sites

turpentine
9 minutes ago, seanbuff said:

Manage Server > Network

You have plenty of options to play with there.

hello thank you, but

the only ports that are playing are

Public HTTPS port number

and

Public HTTP port number:

i cannot see any options to change internal http 8096 and https 8920 :(

 

 

Link to comment
Share on other sites

seanbuff
41 minutes ago, turpentine said:

i cannot see any options to change internal http 8096 and https 8920

At the top of that tab, you don't see the following?

image.png.d65b1085f73df0bf0e0ad58cf3af63a9.png

Link to comment
Share on other sites

turpentine
10 minutes ago, seanbuff said:

At the top of that tab, you don't see the following?

image.png.d65b1085f73df0bf0e0ad58cf3af63a9.png

no unfortunately not

i can see only external ports on the synology emby package

1511930572_damnedIPV6.jpg.ae7217cab991bfd62805a599282499b6.jpg

 

 

Link to comment
Share on other sites

turpentine
1 minute ago, FrostByte said:

Also read Luke's response

 

2 minutes ago, FrostByte said:

 

i use DSM6.

so due to ipv6, and no tcp port nat feature on routers, you cannot setup internal port as external ports, i can suicide myself.

Link to comment
Share on other sites

kaj

You could look at using zerotier or wireguard to access your NAS, as that should bypass CGNAT

Link to comment
Share on other sites

turpentine
4 minutes ago, kaj said:

You could look at using zerotier or wireguard to access your NAS, as that should bypass CGNAT

thank you, but it is like a deep pain.  i would to access my emby server "service" not my NAS

CGNAT means no incoming tcp connections for ipv4. 

ipv6 means incoming connections possible

ipv6 routers do not do nat, or port translation, they accept or not to access the ipv6 prefix. that's all not changing the destination port on the fly.

i cannot change in DSM6  the service listening for emby so i am stucked at 8096 or 8920 for a dark reason

i can change external ports in emby, but if i change them, i am blocked by cloud services or firewalls (which is are not my home router)

so basically "emby for DSM6" is a tenet paradox, in case of IPV6.

the only solution i can see is too activate a reverse proxy in DSM, to redirect the ipv6 https request to port https 8920, which is not really optimized.

Link to comment
Share on other sites

turpentine

Yes this Is an option. But it is quitte hard to find a provider with ipv4 available with 65536 ports assigned to one router. IPv6 should be the Future. Ipv4 Is rare.

Emby should be IPv6 friendly And designed according to network IPv6 rules.

Link to comment
Share on other sites

1 hour ago, turpentine said:

 

i use DSM6.

so due to ipv6, and no tcp port nat feature on routers, you cannot setup internal port as external ports, i can suicide myself.

No that's not the reason why. It's because of the reason that I mentioned here:

Some users have found workarounds to use custom ports by editing the server config file, but it's not something I've ever experimented with.

Link to comment
Share on other sites

turpentine
8 hours ago, Luke said:

No that's not the reason why. It's because of the reason that I mentioned here:

Some users have found workarounds to use custom ports by editing the server config file, but it's not something I've ever experimented with.

what do you mean exactly by editing the server config file. i am a network expert, not a system expert how can we achieve that ? have you got an exemple of this file

luke if you leave emby server as it is, with no possibilities to change the local port, ipv6 emby users are doomed, because the way of thinking of ipv6 means emby internal port = emby external port.

ipv6 was not meant or invented to do nat, or port translations, it is direct to the internal machine, with permission or deny clauses

 

 

 

 

Link to comment
Share on other sites

FrostByte
59 minutes ago, turpentine said:

what do you mean exactly by editing the server config file. i am a network expert, not a system expert how can we achieve that ? have you got an exemple of this file

 

 

Notepad?  Change the two lines cayars mentioned in the link I gave you above.

DSM 7

/volume1/@appdata/EmbyServer/config/system.xml

Can't remember where they are in DSM 6, but it will be something similar

  • Like 1
Link to comment
Share on other sites

turpentine
7 hours ago, FrostByte said:

Notepad?  Change the two lines cayars mentioned in the link I gave you above.

DSM 7

/volume1/@appdata/EmbyServer/config/system.xml

Can't remember where they are in DSM 6, but it will be something similar

thank you frost byte, i will test it. and let you know.  i hope it will work. what a paradox :)

  • Like 1
Link to comment
Share on other sites

turpentine

i have made some test in ssh on my diskstation

 

the file seems located elsewhere in DSM6, this is here this is the good newsembyparadox.jpg.2fdd1c45fa0e80a2bc82c6d6bd20aab7.jpg

 

what a deep pain to edit this file with vi the only editor working.

  <PublicPort>2095</PublicPort>
  <PublicHttpsPort>8443</PublicHttpsPort>
  <HttpServerPortNumber>2095</HttpServerPortNumber>
  <HttpsPortNumber>8443</HttpsPortNumber>
  <EnableHttps>true</EnableHttps>

now it is ok

 

ipv6doomed.jpg.fbe2cd1be3b57d21a4bed0932c220fdb.jpg

 

why it is not possible to code something in DSM EMBY normal user interface, some deamon that will modify the local ports in the xml file and restart service ?

because all ipv6 DSM users are doomed there.

 

Edited by turpentine
Link to comment
Share on other sites

Hi, it's not that simple because the port number is also defined in the Synology package manifest, which gives us some special permission with the system.

  • Haha 1
Link to comment
Share on other sites

turpentine
8 minutes ago, Luke said:

Hi, it's not that simple because the port number is also defined in the Synology package manifest, which gives us some special permission with the system.

so why you do not ask synology support team to find an acceptable workaround with permissions. do you realise this is "nonsense" to the proof of concept of incoming tcp connections in ipv6. as public https port and local https port MUST be the same. it should be only one parameter for https when talking with ipv6 :)

 

Edited by turpentine
  • Thanks 1
Link to comment
Share on other sites

On 5/30/2022 at 6:41 PM, turpentine said:

firewall or cloudflare usually accept only 443 8443 for https.. so incoming tcp connexion will arrive directly only 443 or 8443 with ipv6 directly on emby servers with no nat at all.

Cloudflare by default uses HTTPS ports: 80, 8080, 8880, 2052, 2082, 2086, 2095

Cloudflare by default uses HTTPS ports: 443, 2053, 2083, 2087, 2096, 8443

You can use a tunnel and forward any port you want as well.

On 5/30/2022 at 9:49 PM, turpentine said:

thank you, but it is like a deep pain.  i would to access my emby server "service" not my NAS

CGNAT means no incoming tcp connections for ipv4. 

ipv6 means incoming connections possible

ipv6 routers do not do nat, or port translation, they accept or not to access the ipv6 prefix. that's all not changing the destination port on the fly.

CGNAT doesn't mean you can't have incoming traffic.  It just means it has to be opened from the inside first.

IPv6 routers most certainly do NAT. I've got a NAT setup for IPv6.

On 5/31/2022 at 5:38 PM, turpentine said:

what a deep pain to edit this file with vi the only editor working.

  <PublicPort>2095</PublicPort>
  <PublicHttpsPort>8443</PublicHttpsPort>
  <HttpServerPortNumber>2095</HttpServerPortNumber>
  <HttpsPortNumber>8443</HttpsPortNumber>
  <EnableHttps>true</EnableHttps>

Why use VI if you're not familiar with it? Install NANO or some other text based editor that you'll find easier to use.
For that matter you can install the text editor right from the catalog:
image.png.1269f79892e348129b2c6f534b5d5856.png

Editing the file is pretty easy if you have the right tools setup to use.

On 5/31/2022 at 5:51 PM, turpentine said:

so why you do not ask synology support team to find an acceptable workaround with permissions. do you realise this is "nonsense" to the proof of concept of incoming tcp connections in ipv6. as public https port and local https port MUST be the same. it should be only one parameter for https when talking with ipv6 :)

Synology has you covered many different ways that do not interfere with their new security model (DSM 7). They have intentionally added the ports to reserved lists on purpose so the "out of the box" experience is hardened vs open like many other NAS vendors.  Synology is the only main stream NAS product to not have a breach of security leading to users getting hit with Ransomware.

They do give you a few options to make things work the way it's needed:

  1. They allow you to edit the package config file like you did.
  2. They supply a reverse proxy you can use to redirect ports
  3. You can change the ports Synology uses to free up port 80 and 443
  4. Use Synology VPN
  5. You can use Quickconnect  & port forwarding rules

image.png.a633df5d5310583dfa6ad93410a708a6.png

Forgetting about built in Synology tools you can:

  1. You can install your own reverse proxy such as or Traefik, Nginx, Caddy, HAProxy, Apache, etc
  2. Use a Cloudflare tunnel
Link to comment
Share on other sites

turpentine
On 6/8/2022 at 12:05 AM, cayars said:

Cloudflare by default uses HTTPS ports: 80, 8080, 8880, 2052, 2082, 2086, 2095

Cloudflare by default uses HTTPS ports: 443, 2053, 2083, 2087, 2096, 8443

thank you, i know this.

 

On 6/8/2022 at 12:05 AM, cayars said:

You can use a tunnel and forward any port you want as well.

what for ? why you want to tunnelize https request, you like over encapsulations ? true incoming http with TLS is not enough for you ? simplicity is the best

tunnelling is very good for performance (joke).

 

On 6/8/2022 at 12:05 AM, cayars said:

CGNAT doesn't mean you can't have incoming traffic.  It just means it has to be opened from the inside first.

maybe i am a stupid old CCIE Expert

i never said you can't have incoming traffic, no incoming tcp connections for ipv4. that means no incoming initiated by the outside, that the way core emby works

? CGNAT means no incoming session TCP packet at ALL initiated from the outside,

if you open from the inside first,  of course CGNAT will allow incoming traffic if the session is initiated from the inside, but that does not mean, that emby end to end core system will work to connect to the emby NAS as designed by Luke... as the incoming TCP comes always from the outside first.....to connect to emby server.......

i can assure you that with CGNAT on ipv4 only activated with my telco home router i cannot receive any incoming tcp connexions from emby connect, due to CGNAT on this same ipv4 shared by some neighbours and other customers.

the only incoming connexion working (from outside) is on ipv6 nas adress, that has a very clever implementation of choosing your listening port for emby server (this is bad humour lol). of course with AAAA dns entry it works again (unless you are able to modify the xml file). but no way to modify it directly in emby normal UI settings...

On 6/8/2022 at 12:05 AM, cayars said:

IPv6 routers most certainly do NAT. I've got a NAT setup for IPv6.

please show me a screenshot of it for your home router, i do not believe you at all.

ipv6 to ipv6 nat does not exist at all in home standard FTTH "mister everybody" normal routers provided by home operators. this is not the way ipv6 works

the only nat setup existing for ipv6 is when someone wants to nat ipv4 to ipv6, which exists only in entreprises high end networks routers....

i am talking a bout normal routers in homes. not some geek customised firmware routers

some mad guys have done a draft NAT66 to nating ipv6 to ipv6 in linux custom routers but it is not well supported by the industry yet. these guys are simply heretics

they do not understand at all ipv6. ipv6 was invented to avoid nat, and logically to avoid port forwarding as well.

nat takes a lot of cpu, ipv6 is direct and fast.

 

On 6/8/2022 at 12:05 AM, cayars said:

Why use VI if you're not familiar with it? Install NANO or some other text based editor that you'll find easier to use.
For that matter you can install the text editor right from the catalog:
image.png.1269f79892e348129b2c6f534b5d5856.png

 

thank you i didn't know this. very usefull

 

On 6/8/2022 at 12:05 AM, cayars said:

Synology has you covered many different ways that do not interfere with their new security model (DSM 7). They have intentionally added the ports to reserved lists on purpose so the "out of the box" experience is hardened vs open like many other NAS vendors.  Synology is the only main stream NAS product to not have a breach of security leading to users getting hit with Ransomware.

They do give you a few options to make things work the way it's needed:

  1. They allow you to edit the package config file like you did.
  2. They supply a reverse proxy you can use to redirect ports
  3. You can change the ports Synology uses to free up port 80 and 443
  4. Use Synology VPN
  5. You can use Quickconnect  & port forwarding rules

image.png.a633df5d5310583dfa6ad93410a708a6.png

 

i am stucked at DSM6, xpenology emulated do not have DSM7 yet.

tunneling for me is an heresy :) you have to install extra services cloudflared.... a world of optimized workarounds (joke).

for my point of vue, reverse proxys are evil for port forwarding. there are used by people that does not configure well their network only.

they have only a purpose to convert https to http request with old http server service that does not support TLS... with this you can encrypt things even with a service with no encryption

using reverse proxies for port forwarding is a very bad design, and using reverse proxies with ipv6 incoming connections, just because emby for sinology has not a way for changing listening port (to fullfill normal ipv6 home router behaviour) is just a work around, not a clever way

only level 3routing devices has the true right to do port forwarding (ipv4 only with full stack ip no CGNAT).  using reverse proxy for port forwarding, is like making pancakes with mittens.

ipv6 connectivity is simple (nat free/port forwarding free), think simple, just do it :) soon or later, all users will be either doomed by CGNAT for IPV4, or forced to migrate to ipv6. you will have to find a clever solution, not a bunch of complicated workarounds for most emby users:)

CGNAT for IPV4 means no incoming tcp connections (initiated from the outside)

in this particular case, the less worse solution is to edit the xml file and have the ipv6 working as expected "in the books". All the other solutions are not ethically acceptable.

have a nice day

 

 

Edited by turpentine
Link to comment
Share on other sites

Oh noy. :)

4 hours ago, turpentine said:

what for ? why you want to tunnelize https request, you like over encapsulations ? true incoming http with TLS is not enough for you ? simplicity is the best

tunnelling is very good for performance (joke).

You made a joke but tunneling can be quite faster for a few reasons. First with a tunnel you can dynamically change connection points thus always using the fastest connection.  For example where I live in Southern NJ I can route through Phila, Newark & Patterson exchanges and it's a coin toss which will be fastest. But if traffic is higher than normal or another tunnel is faster it will use the alternate tunnel. A good tunnel also adjusts the external MTU size correctly as big as it can be before fragmenting packets. This will improve throughput by itself.

Try opening a command box on windows and  typing this

netsh interface ipv4 show subinterface

What does your results look like?

Internal to the tunnel you can run higher MTU sizes as well helping to give better local throughput.

5 hours ago, turpentine said:

i can assure you that with CGNAT on ipv4 only activated with my telco home router i cannot receive any incoming tcp connexions from emby connect, due to CGNAT on this same ipv4 shared by some neighbours and other customers.

the only incoming connexion working (from outside) is on ipv6 nas adress, that has a very clever implementation of choosing your listening port for emby server (this is bad humour lol). of course with AAAA dns entry it works again (unless you are able to modify the xml file). but no way to modify it directly in emby normal UI settings...

l would generally agree with your first comment. I agree in spirit with some of your second part as well but have no idea what you're talking about starting with the AAAA part.

5 hours ago, turpentine said:

please show me a screenshot of it for your home router, i do not believe you at all.

ipv6 to ipv6 nat does not exist at all in home standard FTTH "mister everybody" normal routers provided by home operators. this is not the way ipv6 works

the only nat setup existing for ipv6 is when someone wants to nat ipv4 to ipv6, which exists only in entreprises high end networks routers....

i am talking a bout normal routers in homes. not some geek customised firmware routers

some mad guys have done a draft NAT66 to nating ipv6 to ipv6 in linux custom routers but it is not well supported by the industry yet. these guys are simply heretics

they do not understand at all ipv6. ipv6 was invented to avoid nat, and logically to avoid port forwarding as well.

nat takes a lot of cpu, ipv6 is direct and fast.

Be happy to but hoping you think this through first. How many IPv6 IPs did your ISP give you? Did they assign you 100 to 255 IPv6 IPs for your own use or did you get just one IPv6 and need to use it for your whole LAN?  Assuming it's the latter, how do you think your home router shares that one external address IPv4 or IPv6 with an unknown number of internal IPs?
What about a network that is strictly IPv4 internal with an IPv6 external IP?

Remember NAT and CGNAT are not the same thing.

5 hours ago, turpentine said:

i am stucked at DSM6, xpenology emulated do not have DSM7 yet.

tunneling for me is an heresy :) you have to install extra services cloudflared.... a world of optimized workarounds (joke).

for my point of vue, reverse proxys are evil for port forwarding. there are used by people that does not configure well their network only.

they have only a purpose to convert https to http request with old http server service that does not support TLS... with this you can encrypt things even with a service with no encryption

Oh Xpenology.  You still may be able to do 7.0 or 7.1 DSM.  Have you tried RedPill? I've gotten DSM 7 installed on ProxMox, Xen, Hyper-V, VMWare and Bare Metal with the RedPill boot loader https://github.com/pocopico/tinycore-redpill. It's still in testing but definitely worth testing and playing with. One of the biggest problem I've seen with Xenology in general is it's poor networking performance due to lack of hardware offloading support. It's ok for 1 Gb and maybe 2.5 Gb but anything higher and it will bog down the VM badly.

5 hours ago, turpentine said:

using reverse proxies for port forwarding is a very bad design, and using reverse proxies with ipv6 incoming connections, just because emby for sinology has not a way for changing listening port (to fullfill normal ipv6 home router behaviour) is just a work around, not a clever way

only level 3routing devices has the true right to do port forwarding (ipv4 only with full stack ip no CGNAT).  using reverse proxy for port forwarding, is like making pancakes with mittens.

We obviously feel quite different about the use of internet toolboxes such as reverse proxies. :) Reverse proxies are quite handy for a lot of jobs they accelerate at and make your life easier. As an example you can have a small NAS/server setup for family/friends with Emby, Nextcloud, Blog, and small website with Search & Bookmarks that ties it all together.  If you use names like emby.domain.ext, nextcloud.domain.ext, blog.domain.ext, search.domain.ext, bookmarks.domain.ext, www.domain.ext for each component you can setup everything to use port 443. Yes, no need for multiple port open on your router. The router is setup to send all incoming traffic to the proxy server for ports you open.  The reverse proxy gets a 443 connection inbound, looks to see if it can answer the request from cache (ie. all the static javascript and graphic files) so not having to hand off to the server. If it can't it looks at the name "emby" and knows to forward the request to your 192.168.1.7 machine, It sees "nextcloud" and knows to send this to 192.168.1.24, etc. So that allows sharing ports for multiple sites.  You can also load balance as well You could have 3 old computers running Emby and the reverse proxy could "balance" the load across all your servers.

We're not done yet.  A reverse proxy can be configured to decrypt all incoming requests and encrypt all outgoing responses, freeing up valuable resources on the origin server. You could get multiple individual certificates but 1 wildcard cert setup on the reverse proxy has you covered for everything you do on your domain. Lastly using a text record added to the DHCP server you can "tag" any record with information the reverse proxy will use automatically. This way on receiving a brand new subdomain it can very quickly do a "dns" lookup from the internal setup determine there is a new subdomain that's authorized and supplying the IP and port in the dns/tags.  A new subdomain using your settings of choice is automatically deployed complete with SSL/TLS certs. If the lookup showed this wasn't a valid "tag" record it can ban the source handling it like an attack without ever letting the traffic hit your server(s).  It can be setup to add bans to your router itself or if using a CDN could pass that IP right up the chain to them so they can block it for you.

So you also get protection from attacks - With a reverse proxy in place, a web site or service never needs to reveal the IP address of their origin server(s). This makes it much harder for attackers to leverage a targeted attack against them, such as a DDoS attack. Instead the attackers will only be able to target the reverse proxy, such as Cloudflare’s CDN, which will have tighter security and more resources to fend off a cyber attack.

7 hours ago, turpentine said:

only level 3routing devices has the true right to do port forwarding (ipv4 only with full stack ip no CGNAT).  using reverse proxy for port forwarding, is like making pancakes with mittens.

ipv6 connectivity is simple (nat free/port forwarding free), think simple, just do it :) soon or later, all users will be either doomed by CGNAT for IPV4, or forced to migrate to ipv6. you will have to find a clever solution, not a bunch of complicated workarounds for most emby users:)

CGNAT for IPV4 means no incoming tcp connections (initiated from the outside)

in this particular case, the less worse solution is to edit the xml file and have the ipv6 working as expected "in the books". All the other solutions are not ethically acceptable.

Don't confuse a router with a switch. Most layer 3 switches are about 60% routers from a functionality standpoint. Layer 4+ switches are pretty close to most entry level routers. From a switch standpoint a layer 2 switch looks at frames and sends things based on MAC addresses but doesn't know anything about the network or protocols running in the traffic. Layer-3 switching is solely based on (destination) IP address stored in the header of IP datagram. Layer 4 switching does hardware-based layer 3 switching that can also consider the type of network traffic (for example, distinguishing between UDP and TCP), etc

Trying to compare the two is like using a pancake as a frisbee. It may look similar, but port forwarding has nothing to do with routing or switching per say. :)

So port forwarding is easy to do, is very common and nothing to work to avoid. Your packets get port forwarded all the time. NAT is not a bad thing either as it's the building blocks of proper security to protect internal computers from outside exposure. CGNAT is a paint but only slightly an obstacle these days as their is at least a good dozen ways to work right around this while sometimes speeding up your connection!  Tunnels can vastly improve performance or hurt performance, as it goes both ways depending on configuration and topology. Reverse Proxies are a stable of running clustered web servers that improve/accelerate connections and reduce server loads.  That's why they are often called "web accelerators" vs "reverse proxies".

That's a long winded answer to a few things but getting back to the source of the issue with CGNAT. I see CGNATs quite often helping people and know it's one of the harder things to deal with for most admins.  I've got some ideas how to automate and handle some of this better and even working on some early prototype code I can use to test different situations with. We also have some other things remote/login related we would like to improve as well.

  • Haha 1
Link to comment
Share on other sites

turpentine
17 hours ago, cayars said:

Oh noy. :)

You made a joke but tunneling can be quite faster for a few reasons. First with a tunnel you can dynamically change connection points thus always using the fastest connection.  For example where I live in Southern NJ I can route through Phila, Newark & Patterson exchanges and it's a coin toss which will be fastest. But if traffic is higher than normal or another tunnel is faster it will use the alternate tunnel. A good tunnel also adjusts the external MTU size correctly as big as it can be before fragmenting packets. This will improve throughput by itself.

Try opening a command box on windows and  typing this

netsh interface ipv4 show subinterface

What does your results look like?

Internal to the tunnel you can run higher MTU sizes as well helping to give better local throughput.

l would generally agree with your first comment. I agree in spirit with some of your second part as well but have no idea what you're talking about starting with the AAAA part.

Be happy to but hoping you think this through first. How many IPv6 IPs did your ISP give you? Did they assign you 100 to 255 IPv6 IPs for your own use or did you get just one IPv6 and need to use it for your whole LAN?  Assuming it's the latter, how do you think your home router shares that one external address IPv4 or IPv6 with an unknown number of internal IPs?
What about a network that is strictly IPv4 internal with an IPv6 external IP?

Remember NAT and CGNAT are not the same thing.

Oh Xpenology.  You still may be able to do 7.0 or 7.1 DSM.  Have you tried RedPill? I've gotten DSM 7 installed on ProxMox, Xen, Hyper-V, VMWare and Bare Metal with the RedPill boot loader https://github.com/pocopico/tinycore-redpill. It's still in testing but definitely worth testing and playing with. One of the biggest problem I've seen with Xenology in general is it's poor networking performance due to lack of hardware offloading support. It's ok for 1 Gb and maybe 2.5 Gb but anything higher and it will bog down the VM badly.

We obviously feel quite different about the use of internet toolboxes such as reverse proxies. :) Reverse proxies are quite handy for a lot of jobs they accelerate at and make your life easier. As an example you can have a small NAS/server setup for family/friends with Emby, Nextcloud, Blog, and small website with Search & Bookmarks that ties it all together.  If you use names like emby.domain.ext, nextcloud.domain.ext, blog.domain.ext, search.domain.ext, bookmarks.domain.ext, www.domain.ext for each component you can setup everything to use port 443. Yes, no need for multiple port open on your router. The router is setup to send all incoming traffic to the proxy server for ports you open.  The reverse proxy gets a 443 connection inbound, looks to see if it can answer the request from cache (ie. all the static javascript and graphic files) so not having to hand off to the server. If it can't it looks at the name "emby" and knows to forward the request to your 192.168.1.7 machine, It sees "nextcloud" and knows to send this to 192.168.1.24, etc. So that allows sharing ports for multiple sites.  You can also load balance as well You could have 3 old computers running Emby and the reverse proxy could "balance" the load across all your servers.

We're not done yet.  A reverse proxy can be configured to decrypt all incoming requests and encrypt all outgoing responses, freeing up valuable resources on the origin server. You could get multiple individual certificates but 1 wildcard cert setup on the reverse proxy has you covered for everything you do on your domain. Lastly using a text record added to the DHCP server you can "tag" any record with information the reverse proxy will use automatically. This way on receiving a brand new subdomain it can very quickly do a "dns" lookup from the internal setup determine there is a new subdomain that's authorized and supplying the IP and port in the dns/tags.  A new subdomain using your settings of choice is automatically deployed complete with SSL/TLS certs. If the lookup showed this wasn't a valid "tag" record it can ban the source handling it like an attack without ever letting the traffic hit your server(s).  It can be setup to add bans to your router itself or if using a CDN could pass that IP right up the chain to them so they can block it for you.

So you also get protection from attacks - With a reverse proxy in place, a web site or service never needs to reveal the IP address of their origin server(s). This makes it much harder for attackers to leverage a targeted attack against them, such as a DDoS attack. Instead the attackers will only be able to target the reverse proxy, such as Cloudflare’s CDN, which will have tighter security and more resources to fend off a cyber attack.

Don't confuse a router with a switch. Most layer 3 switches are about 60% routers from a functionality standpoint. Layer 4+ switches are pretty close to most entry level routers. From a switch standpoint a layer 2 switch looks at frames and sends things based on MAC addresses but doesn't know anything about the network or protocols running in the traffic. Layer-3 switching is solely based on (destination) IP address stored in the header of IP datagram. Layer 4 switching does hardware-based layer 3 switching that can also consider the type of network traffic (for example, distinguishing between UDP and TCP), etc

Trying to compare the two is like using a pancake as a frisbee. It may look similar, but port forwarding has nothing to do with routing or switching per say. :)

So port forwarding is easy to do, is very common and nothing to work to avoid. Your packets get port forwarded all the time. NAT is not a bad thing either as it's the building blocks of proper security to protect internal computers from outside exposure. CGNAT is a paint but only slightly an obstacle these days as their is at least a good dozen ways to work right around this while sometimes speeding up your connection!  Tunnels can vastly improve performance or hurt performance, as it goes both ways depending on configuration and topology. Reverse Proxies are a stable of running clustered web servers that improve/accelerate connections and reduce server loads.  That's why they are often called "web accelerators" vs "reverse proxies".

That's a long winded answer to a few things but getting back to the source of the issue with CGNAT. I see CGNATs quite often helping people and know it's one of the harder things to deal with for most admins.  I've got some ideas how to automate and handle some of this better and even working on some early prototype code I can use to test different situations with. We also have some other things remote/login related we would like to improve as well.

You seem not to understand that i am talking about "networking" not your system skills that seems good.

port forwarding is a router task, for home routers when they have full stack IPV4. i am not here to discuss here about if port forwarding is related to routing or BGP here, nor confusing switches or routers. i am here to discuss about "easy reachability" to our emby home nas, when users are doomed by IPV4 to CGNATed IPV4 every night in all europe countries, because america has vampirised most of all ipv4 adresses, and telco operators start migration to ipv6, because they have no choice.

i will not argue with you about tunnels, bugs, performance issue that exists with tunnels, and doomed dont fragment bits this is not the point here.

the readers will be lost.

the point is that tunnelling is a too complex solution for most humans here for dealing with nas connectivity through CGNAT ipv4 only.

the simple point is how to make emby nas working easily when the only hope you have is ipv6, and you  unfortunately meet CGNAT on your way.

you seem to confuse features around ipv4 or your explanations looks like you want IPV6 to be used as old IPv4 model.

once again, i am not talking about complex enterprise networks, nor confusing NAT or CGNAT, but normal home configs. i am not talking about me and you that are experts. but normal users :) that can connect to their "non-geek-modified" home router, as delivered by the home operator in each countries.  maybe you have entreprise level  routing devices or linux geeked servers at home, but personnaly i prefer to let this devices at work.

again i am talking about home classic setup.

CGNAT is related only to IPV4, all telco mister everybody routers has no NAT feature or port forwarding feature when CGNAT is enabled, as the public ip adress of these routers are shared.

i am talking about normal human NAS at home, with normal FTTH home router.

NAT and port forwarding is usely used on IPV4 Full Stack, not shared IPV4 with CGNAT.

CGNATed IPV4 telco routers = SHARED IPV4= NO NAT feature provided UI = NO port forwarding UI= NO incoming TCP from the outside = you cannot use a A record to this CGNAT ipv4 adress in your nas.cayars.org in your registrar dns entries, for exemple cloudflare, because no incoming tcp is possible, on this CGNAT IPV4 from the outside.

do you understand this fact ? were are not in a datacenter here. we are at home.

NAT IPV4 telco routers = each user got a public IP = nat feature available = port forwarding available, no problems at all everybody is happy. emby users are happy.

but the issue here is that home telco routers do not provide anymore full stack public ip to the new customers, only the old one, until they are migrated by force by night. this is a countdown fact. tic tac tic tac tic tac. there is not only americans on earth that have 35% of ipv4 adresses in the world. you can understand that as system expert.

please look at this video, it explains why americans do not care about  CG NAT issues, they have a lot non-CGNAT ipv4 addresses (joke).

if you look at the statistics, america is not either the first country to like ipv6. not even in the first 3 according to its adoption to telco operators:)

so you cannot rely anymore on CGNAT IPV4 to reach your nas. you have understood that.

if a normal user is doomed by CGNAT, what can he do ? to reach his favorite nas.myhome.org. he can rely on ipv6 provided automatically by all CGNAT IPV4 telco routers. and make a AAAA DNS entry to reach directly the sinology public ipv6 address. simple for me it is, but not obviously for you :). some people like simplicity, others like to build nuclear plants to buypass CGNAT issues. why doing things easy if we can make it complicated.

all CGNAT ipv4 ftth routers in europe provide ipv6 with incoming feature enabled only for IPV6

you seems to mix ipv4 and ipv6, and you make a huge mistake here.

ipv6 do not work as ipv4, you have no 253 ipv6 adresses in your home, you have billions and billions of reachable public ipv6 adresses reachable from the outside, with no nat and no port forwarding.

ipv6 adresses in your home are buit with an public ipv6 prefix, and a suffix that are built automatically based of the network card mac adresses.

for example 2a01:5d8:52e2:f478::/64 after the :: you have your macadresses for most normal home users

IPV6 =  each devices in your home as a public ipv6 address reacheable from the outside if you grant access to them from the outside = NO NAT UI= NO port forwarding UI = only FW UI to allow incoming connexions to public ipv6 adresses on your lan.

so you have to make efforts to make emby ipv6 friendly, you wrongly think "ipv6 should work as ipv4". that is a lie. ipv6 is not as ipv4 you do not need to do port forwarding at all, or make a difference in the configs with public port http servers and listening port http servers. that should be the same in case in IPV6.

ipv6 is direct and should be direct. this the purpose of this topic. why bother users with setting up port forwarding in case of ipv6. it is not normal that you even advice the users to edit the xml file to change the listening port. but this is acceptable.

please make things simple in emby. that's all what you should consider. telling others using reverse proxies or using dark workarounds is not user friendly.

i do not ask you to find a solution with CGNAT, it is a waste of time, believe me my friend, ipv6 is the correct solution to CGNAT issues.

the only thing you have right, what to do for users that have only CGNAT and no ipv6. hopefully most european routers do both.

Do you find normal to tell people, hi guys sorry in case of sinology, we cannot change listening port inside user interface ? and we the emby team do not like ipv6 and advice you to use port forwarding as ipv4 :) personnally i would be ashamed :)(joke)  . user interface are meant to do so

if i tell a cisco technician to download a running config file, in flash to edit it on the fly, they would kill me :).

for me emby user interface is stucked in the ipv4 old world. ipv6 synology public ip address assigned is not even displayed in the UI, as we were all together blocked in a sadomasochist world where we must nat private ipv4 RFC1918 ip addresses to one public ipv6 ip address on the router. ipv6 is useless afterall (joke)

that is not how ipv6 works by delfault on home telco routers. as i reappeated 50 times, ipv6 should be direct with no nat and no port forwarding features :)

 

 

 

 

 

Edited by turpentine
joke
Link to comment
Share on other sites

On 6/9/2022 at 11:46 AM, turpentine said:

You seem not to understand that i am talking about "networking" not your system skills that seems good.

port forwarding is a router task, for home routers when they have full stack IPV4. i am not here to discuss here about if port forwarding is related to routing or BGP here, nor confusing switches or routers. i am here to discuss about "easy reachability" to our emby home nas, when users are doomed by IPV4 to CGNATed IPV4 every night in all europe countries, because america has vampirised most of all ipv4 adresses, and telco operators start migration to ipv6, because they have no choice.

Again, port forwarding is not a routing task, it can and does take place everywhere from software, to switches, to your android phone, smart TV and of course any computer you use. It's a normal part of using TCP.

On 6/9/2022 at 11:46 AM, turpentine said:

the point is that tunnelling is a too complex solution for most humans here.

the simple point is how to make emby nas working easily when the only hope you have is ipv6, and your meet CGNAT on you way.

IPv6 comes with it's own set of issues which is why a lot of users and businesses do not use it.

Tunneling itself is not hard. It's just a matter of what provider you use.

On 6/9/2022 at 11:46 AM, turpentine said:

you seem to confuse features around ipv4 or your explanations looks like you want IPV6 to be used as old IPv4 model.

once again, i am not talking about complex enterprise networks, nor confusing NAT or CGNAT, but normal home configs

CGNAT is related only to IPV4, all telco mister everybody routers has no NAT feature or port forwarding feature when CGNAT is enabled, as the public ip adress of these routers are shared.

i am talking about normal human NAS at home, with normal FTTH home router.

NAT and port forwarding is usely used on IPV4 Full Stack, not shared IPV4 with CGNAT.

CGNATed IPV4 telco routers = SHARED IPV4= NO NAT feature provided UI = NO port forwarding UI= NO incoming TCP from the outside = you cannot use a A record to this CGNAT ipv4 adress in your nas.cayars.org in your registrar dns entries, for exemple cloudflare, because no incoming tcp is possible, on this CGNAT IPV4 from the outside.

do you understand this fact ?

 

I understand your confused as you're mixing NAT and CGNAT together as if they're the same thing and used for the same purpose, yet don't understand why the information your stating is wrong.

NAT in general is the foundation of network security. It's the way you setup private IPs for an internal network vs public IPs that exist outside your LAN. It has  nothing to do with running out of IP addresses but about having a boundary up between your devices and the rest of the world. NAT is the foundation upon how most Firewalls work. There is no path between a public IP and private IP unless the firewall (rules) allows the packet through. The firewall won't normally pass the packet willy nilly to an IP but will be more hardened than that allowing the pack to pass to a specific IP as well as specific port or set of ports.

With a CGNAT this is just another example of a NAT done normally on a larger scale by a carrier/ISP and termed Carrier Grade Network Address Translation to differentiate it from the end user NAT. Contrary to your thinking CGNAT does not need to block inbound ports to the WAN port on your consumer router. Not all ISP do a total block so what you keep repeating about CGNAT is not fact. It's only a minor problem when your ISP uses the NAT like a firewall not allowing anything to pass that wasn't opened from the inside first.

An ISP can take a C class /24 segment and service 5 to 10 thousand customers with it. They could also give everyone of those 10K customers 1000 ports strictly for their use as well. That's an easy provisioning job and often an ISP will do that without charge if you ask them. They may charge $10 for a static IP but will give you 1000 ports forwarded for the asking.

CGNATs are also used as part of a managed ISP security subscription. This goes for IPv4 and IPv6. I almost guarantee your home router that does IPv6 uses NAT as well. If your using DHCP for IPv6 that's a strong "hint" you have an IPv6 NAT.  It makes no difference to a switch or router as it's doing the same thing routing and forwarding between two IP ranges.

On 6/9/2022 at 11:46 AM, turpentine said:

NAT IPV4 telco routers = each user got a public IP = nat feature available = port forwarding available, no problems at all everybody is happy. emby users are happy.

but the issue here is that home telco routers do not provide anymore full stack public ip to the new customers, only the old one, until they are migrated by force by night. this is a countdown fact. tic tac tic tac tic tac. there is not only americans on earth that have 35% of ipv4 adresses in the world. you can understand that as system expert.

so you cannot rely anymore on CGNAT IPV4 to reach your nas. you have understood that.

if a normal user is doomed by CGNAT, what can he do ? to reach his favorite nas.myhome.org. he can rely on ipv6 provided automatically by all CGNAT IPV4 telco routers. and make a AAAA DNS entry to reach directly the sinology public ipv6 address. simple for me it is, but not obviously for you :)

all CGNAT ipv4 ftth routers in europe provide ipv6 with incoming feature enabled only for IPV6

you seems to mix ipv4 and ipv6, and you make a huge mistake here.

ipv6 do not work as ipv4, you have no 253 ipv6 adresses in your home, you have billions and billions of reachable public ipv6 adresses reachable from the outside, with no nat and no port forwarding.

ipv6 adresses in your home are buit with an public ipv6 prefix, and a suffix that are built automatically based of the network card mac adresses.

for example 2a01:5d8:52e2:f478::/64 after the :: you have your macadresses for most users

IPV6 =  each devices in your home as a public ipv6 address reacheable from the outside if you grant access to them from the outside = NO NAT UI= NO port forwarding UI = only FW UI to allow incoming connexions to public ipv6 adresses on your lan.

so you have to make efforts to make emby ipv6 friendly, you wrongly think "ipv6 should work as ipv4". that is a lie. ipv6 is not as ipv4 you do not need to do port forwarding at all, or make a difference in the configs with public port http servers and listening port http servers. that should be the same in case in IPV6.

ipv6 is direct and should be direct. this the purpose of this topic. why bother users with setting up port forwarding in case of ipv6. it is not normal that you even advice the users to edit the xml file to change the listening port. but this is acceptable.

please make things simple in emby. that's all what you should consider. telling others using reverse proxies or using dark workarounds is not user friendly.

i do not ask you to find a solution with CGNAT, it is a waste of time, believe me my friend, ipv6 is the correct solution to CGNAT issues.

the only thing you have right, what to do for users that have only CGNAT and no ipv6. hopefully most european routers do both.

Do you find normal to tell people, hi guys sorry in case of sinology, we cannot change listening port inside user interface ? and we the emby team do not like ipv6 and advice you to use port forwarding as ipv4 :) personnally i would be ashamed :) . user interface are meant to do so

if i tell a cisco technician to download a running config file, in flash to edit it on the fly, they would kill me :)

Again this has some truths in some of what you said but you make assumptions that aren't correct.  You're not limited to 253 internal addresses (256 actually for c class) as you can use an A class such as 10.0.0.0. The same goes for IPv6 in it's use.

Here's the actual issue.  You want to run a public server for your media, but don't have proper service to do so. So you want/expect a software vendor to make up for something hard because you don't have the proper infrastructure in place to run a public server. There are a lot of way you can solve this problem outside of Emby so you can give it an environment it can be public.

Yes I mix IPv4 and IPv6 because there's little difference in setup from a routing standpoint. The same set of tasks and tools are used on IPv6 as IPv4 including NAT and port forwarding, the address space is different and IPv6 comes with it's own setup of rules to follow but it's essentially the same.

On 6/9/2022 at 11:46 AM, turpentine said:

for example 2a01:5d8:52e2:f478::/64 after the :: you have your macadresses for most normal home users

IPV6 =  each devices in your home as a public ipv6 address reacheable from the outside if you grant access to them from the outside = NO NAT UI= NO port forwarding UI = only FW UI to allow incoming connexions to public ipv6 adresses on your lan.

Not true. You assume there is an "::" in the address. "::" is shorthand for 16 0 bytes.  It's only available if you setup a certain way at that. 

Only one of many subnet setups actually supports what you've been saying. ie /48 provisioning

On 6/9/2022 at 11:46 AM, turpentine said:

so you have to make efforts to make emby ipv6 friendly, you wrongly think "ipv6 should work as ipv4". that is a lie. ipv6 is not as ipv4 you do not need to do port forwarding at all, or make a difference in the configs with public port http servers and listening port http servers. that should be the same in case in IPV6.

ipv6 is direct and should be direct. this the purpose of this topic. why bother users with setting up port forwarding in case of ipv6. it is not normal that you even advice the users to edit the xml file to change the listening port. but this is acceptable.

please make things simple in emby. that's all what you should consider. telling others using reverse proxies or using dark workarounds is not user friendly.

i do not ask you to find a solution with CGNAT, it is a waste of time, believe me my friend, ipv6 is the correct solution to CGNAT issues.

the only thing you have right, what to do for users that have only CGNAT and no ipv6. hopefully most european routers do both.

Do you find normal to tell people, hi guys sorry in case of sinology, we cannot change listening port inside user interface ? and we the emby team do not like ipv6 and advice you to use port forwarding as ipv4 :) personnally i would be ashamed :)(joke)  . user interface are meant to do so

if i tell a cisco technician to download a running config file, in flash to edit it on the fly, they would kill me :).

for me emby user interface is stucked in the ipv4 old world. ipv6 synology public ip address assigned is not even displayed in the UI, as we were all together blocked in a sadomasochist world where we must nat private ipv4 RFC1918 ip addresses to one public ipv6 ip address on the router. ipv6 is useless afterall (joke)

that is not how ipv6 works by delfault on home telco routers. as i reappeated 50 times, ipv6 should be direct with no nat and no port forwarding features :)

Emby is IPv6 friendly and works with it out of the box already.

IPv6 is not a preference to IPv4. This is where your faulted thinking is. You gain nothing from IPv6 over IPv4 if both IPs you get are public.

You surely don't want to have your internal machines available directly on the public internet as you suggest.  That's never a good idea.  You want all your machines to be behind a NATted firewall for protection only passing traffic you allow to pass with logging so you can see where your traffic is coming from.

Link to comment
Share on other sites

turpentine
On 6/12/2022 at 1:50 AM, cayars said:

Again, port forwarding is not a routing task, it can and does take place everywhere from software, to switches, to your android phone, smart TV and of course any computer you use. It's a normal part of using TCP.

IPv6 comes with it's own set of issues which is why a lot of users and businesses do not use it.

Tunneling itself is not hard. It's just a matter of what provider you use.

I understand your confused as you're mixing NAT and CGNAT together as if they're the same thing and used for the same purpose, yet don't understand why the information your stating is wrong.

NAT in general is the foundation of network security. It's the way you setup private IPs for an internal network vs public IPs that exist outside your LAN. It has  nothing to do with running out of IP addresses but about having a boundary up between your devices and the rest of the world. NAT is the foundation upon how most Firewalls work. There is no path between a public IP and private IP unless the firewall (rules) allows the packet through. The firewall won't normally pass the packet willy nilly to an IP but will be more hardened than that allowing the pack to pass to a specific IP as well as specific port or set of ports.

With a CGNAT this is just another example of a NAT done normally on a larger scale by a carrier/ISP and termed Carrier Grade Network Address Translation to differentiate it from the end user NAT. Contrary to your thinking CGNAT does not need to block inbound ports to the WAN port on your consumer router. Not all ISP do a total block so what you keep repeating about CGNAT is not fact. It's only a minor problem when your ISP uses the NAT like a firewall not allowing anything to pass that wasn't opened from the inside first.

An ISP can take a C class /24 segment and service 5 to 10 thousand customers with it. They could also give everyone of those 10K customers 1000 ports strictly for their use as well. That's an easy provisioning job and often an ISP will do that without charge if you ask them. They may charge $10 for a static IP but will give you 1000 ports forwarded for the asking.

CGNATs are also used as part of a managed ISP security subscription. This goes for IPv4 and IPv6. I almost guarantee your home router that does IPv6 uses NAT as well. If your using DHCP for IPv6 that's a strong "hint" you have an IPv6 NAT.  It makes no difference to a switch or router as it's doing the same thing routing and forwarding between two IP ranges.

Again this has some truths in some of what you said but you make assumptions that aren't correct.  You're not limited to 253 internal addresses (256 actually for c class) as you can use an A class such as 10.0.0.0. The same goes for IPv6 in it's use.

Here's the actual issue.  You want to run a public server for your media, but don't have proper service to do so. So you want/expect a software vendor to make up for something hard because you don't have the proper infrastructure in place to run a public server. There are a lot of way you can solve this problem outside of Emby so you can give it an environment it can be public.

Yes I mix IPv4 and IPv6 because there's little difference in setup from a routing standpoint. The same set of tasks and tools are used on IPv6 as IPv4 including NAT and port forwarding, the address space is different and IPv6 comes with it's own setup of rules to follow but it's essentially the same.

Not true. You assume there is an "::" in the address. "::" is shorthand for 16 0 bytes.  It's only available if you setup a certain way at that. 

Only one of many subnet setups actually supports what you've been saying. ie /48 provisioning

Emby is IPv6 friendly and works with it out of the box already.

IPv6 is not a preference to IPv4. This is where your faulted thinking is. You gain nothing from IPv6 over IPv4 if both IPs you get are public.

You surely don't want to have your internal machines available directly on the public internet as you suggest.  That's never a good idea.  You want all your machines to be behind a NATted firewall for protection only passing traffic you allow to pass with logging so you can see where your traffic is coming from.

you only right only on this sentense both ip are public. but we stop here 😛 there are only public but these public ip have not the same features, in term of configuration, reachability, scalability.

IPV4 and CGNAT IPV4 is not the same.

when users have the choice only between a dual broadband CGNAT ipv4 and native ipv6 nowadays, on most new suscriptions, the fact they are both public, does not mean the ISP let the users configure them port forwarding on that CGNAT :). with CGNAT ipv4 connectivity enabled the only thing you can configure is ipv6.

 

image.thumb.png.3db8af1d1be99566216ab11b3d38a67b.png

ISP brodbadnd customers have 3 kind of connectivity in the european union

- public ipv4 only (no CGNAT, port forwarding avaible for normal users) => getting rare

- dual stack ipv4, ipv6 (no CGNAT,  only available on entreprise expensive contracts) => we are not in a datacenter, we do not assume we are in this case.

- dual CGNAT ipv4, ipv6 (CGNAT only on a shared public ipv4 with multiple customers, nothing is configurable related to this CGNAT public ipv4), and a normal native ipv6 for the wan address of routers, and normal native ipv6 address for all the lan machines, with firewall rules => the common architecture for most users,

please look above (the screenshot) , this the only firewall feature available for ipv6. no nat no port forwarding, it seems that this isp also thinks that nat and port forwarding seems useless in case of ipv6.

you can put the source ipv6 adresses, tcp or udp, the destination service port and the destination ipv6 adresses, to authorise incoming tcp ipv6 connexion

(no nat 46 no port forwarding). do you really think that europeans isp is so retarded, that they forget to propose nat or port forwarding for ipv6. or have they the truth ipv6 is meant to be direct ?

but where you are wrong, that a CGNAT ipv4 and a full stack ipv4 have the same features

https://en.wikipedia.org/wiki/Carrier-grade_NAT

Carrier-grade NAT usually prevents the ISP customers from using port forwarding, because the network address translation (NAT) is usually implemented by mapping ports of the NAT devices in the network to other ports in the external interface. This is done so the router will be able to map the responses to the correct device; in carrier-grade NAT networks, even though the router at the consumer end might be configured for port forwarding, the "master router" of the ISP, which runs the CGN=>   than means users have no control. users are doomed. no users have control on the ISP far routers...

i think you missunderstand "preference" with no choice, and misconception about ipv6

 

BEFORE (connectivity IPV4)

ipv4 Full stack (all ports 65535 reachable) NAT ok

no ipV6 connectivy

end to end direct connectivy possible from the outside with port forwording and nat, configurable directly easily on your home internet router UI

AFTER (connectivity IPV6& CGNAT IPV4)

(millions of home routers are like this in europe or broadband internet home connection).

new ipV4 GNATed (no incoming ports are forwardable)

Native ipv6 connectivity , NAT ipv6 not even proposed (because it is maybe considered as stupid to do nat who knows with ipv6 :)

firewall connectivity, to allow incoming connectivity to in lan native ipv6 adresses, with no nat and destination port checking only not port forwarding. by default, incoming connectivity to native ipv6 lan are blocked of course...

i am not confusing anything i can assure you, because when my router was monostack ipv4, it was normal full stack ipv4 nat, and everthing was fine

and when dslam upgrades comes to ipv6, routers started to be delivery with  dual ip, a worse CGNATed ipv4 and a public ipv6 prefix. the bonus , was nat feature was removed on router and port porwarding feature as well. a new bonus firewall ui was put only on ipv6

GGNAT ipv4 on home internet connections all over europe brokes end-to-end direct connectivity for any session initiated by the outside.

i do not know in which country you are living brand new home fibre routers comes with dual ip CGNAT (useless for incoming) and a ipv6 prefix.

if we were on an ipV4 with NO CGNAT only network, why not, let's do nat in the home part. what i strongly disagree with you is concerning ipv6.

people who have sinology do not put their nas in a public server or a datacenter

obviously you do not understand that all home new ftth routers recetly provided, by telco operators have a dual ip (CGNAT ipv4 and a native ipv6 prefix). and concerning the ipv6 stack, there is not nat feature, no port forwarding feature, but there is a fw feature. you seem stucked in the ipv4 world

https://blog.apnic.net/2019/03/18/common-misconceptions-about-ipv6-security/ please read this...

One of the most common misconceptions regarding IPv6 security is that the lack of NAT makes IPv6 less secure. NAT44 is often seen as a security feature in IPv4 networks. The use of public addresses in IPv6 and the restoration of end-to-end connectivity is of great concern to many IPv4 network administrators.

Confusing brokenness with security is a mistake. Firewalls can easily provide equivalent and better protection than NAT without breaking end-to-end connectivity. Ironically, NAT44 and its associated myriad of NAT-traversal techniques have many security issues of their own.

i do not say emby has a broken ipv6 network connectivity, i just say emby is not ipv6 user-friendly for 2 main reasons

1) assigned ipv6 address, only In-Home (LAN) access, displays the RFC1918 private ipv4 adress only. despite i have a native ipv6 adress, you do not display it on the user interface.

for exemple 192.168.1.10:8443, not the native ipv6  hexadecimal address, made with macaddress 2XXX:XXXX:XXXX:XXX:XXXX:XXff:feXX:XXXX:8443

2) the emby server listening port is not configurable in the user interface, and you force users to do port forwarding or nat, which is not relevant or even possible in case of full ipv6 connectivity, for normal users in their home setup.

What right do you have to decide that emby users who have a native v6 ip address on their emby server must do nat or port translations elsewhere ?

because native ipv6 is designed like this, when home routers assign automatically native ipv6 addresses to all your lan machines, based on their own macaddresses....

of course all your lan machines are not reachable directly from the outside unless, you autorise them in the FW filtering home routeur UI.

even pfsense (which is not really a home solution) firewalls says NAT for ipv6 is useless.

users that would like to have end-to-end connectivity to their home NAS with ipv6, because it's only the only way to get this end-end connectivity nowadays, if you force them to do "port forwarding" or "nat 46" they surely might not have available on their internet broadband routers available by defaut, nor the skills or the place to build their "datacenter at home" to fullfill your NAT obsession with ipv6.

ipv4 for all your new customers will not be reliable at all very soon, if the users got CGNATed on public shared ipv4  with plenty of others customers.

you said ipv6 is not a preference, but here ipv6 is the only way to get the "end2end" principle initiated from the outside, for most new users.

you are simply discriminating them. all users in ipv6 & ipv4 CGNAT mode (also called dual stack lite in some countries) are discriminated :)

it's purely discrimination :)

 

 

 

if you still do not believe me, please ask google for it.

Is NAT unnecessary for IPv6? and look at first result.

 

 

 

PS : you said port forwarding is not a routing task.  yes you are right. but i said it is a common home router task. i already know that all equipements on earth have a routing table.

of course it was a common router task until the invention of CGNAT on ipv4 on far end isp routers.

here the screenshot when the home router was on ipv4 stack only without CGNAT ipv4 and without ipv6.

professional cisco routers can also do port forwarding with ip nat commands.

image.thumb.png.b18f9734e711042845dc3fa5ec86e519.png

 

Edited by turpentine
mispell
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
 Share

×
×
  • Create New...