Improved server manager HTTPS Redirect

Now if you reach server from external and the server has local IP on red interface you’ll be redirect to https://hostname:980
If you reach it from Internet, but server has got public IP on red interface or you are in the same network of the server you’ll be redirect to https://InterfaceIP:980.

If someone wants to test it the command is:
yum install

The PR #34 is this


Just tried it on a test VM in virtualbox: works like a charm!

I went to http://IP:980 and it automagically changed to https://IP:980/en-US/Dashboard

@federico.ballarini reach… to what port?
I know that the redirect will lead to port 980. But which is the first contacted port of the installation?

You should try to connect from internal on http://IP:980 and see that you will be redirect to https://IP:980.
But if you connect from external you will be redirect from http://hostname:980 to https://hostname:980 or to http://publicIp:980 if you have a public IP directly on red interface.

Thanks for your explanation

Why? Why would you ever want to redirect to https on an IP address, virtually guaranteeing a certificate error? And how does your change result in the server speaking both HTTP and HTTPS on port 980?

Thank you @federico.ballarini for the PR!

I still have a doubt: what problem are you trying to solve?

I’m trying to improve the redirect when you call http://servername:980 but the server hasn’t got a public IP on Red interface. With my PR if you have a private IP and you are calling server manager from Internet you’ll be redirect to https://servername:980

1 Like

I understand what the patch does, but I can’t get in which cases it can be useful.
If you don’t have a public IP, probably neither of both redirects will work.

As maintainer, I see 30 new lines code which will work on very few cases.
Maybe I’m wrong, it seems that @robb appreciate the changes.

Does anyone else find this feature useful? What are the use cases?

How does your patch result in the server talking both HTTP and HTTPS over port 980?

@danb35 i’m modifying the error 400 bad request apache page.

@giacomo if Nethserver si behind a router your red IP will probably be 192.168.x.x:980 for example. As now, you will redirect to https://192.168.x.x:980 that is surely not reachable form Internet. With my patch you will be redirect to https://servername:980 that probably is reachable form Internet.

It doesn’t work only in the case that red Ip is private and there isn’t any DNS pointing to server name.

1 Like

Thank you, now the usage scenario is much clear :slight_smile:

I will request the review to @davidep who is on vacation until next week

1 Like

…probably! As we cannot find the perfect solution I propose a simpler implementation.

…Replace $url on line 15 with a new $_SERVER['SERVER_NAME'] based URL (say $url2). So if the META http-equiv does not work the suggested URL could work as manual fallback.

See also

I wonder if the SERVER_NAME can be subject to DNS attacks though… For instance SERVER_NAME value is server.lan and a poisoned DNS reply sends me to a malicious server.lan IP… Please do not consider it.

1 Like

But if you are on LAN and working on a server that have “domain.lan” hostname and you haven’t got DNS set properly, you’ll not able to reach the server.

My PR, doesn’t work only in the case that red Ip is private and there isn’t any DNS pointing to server name and you are calling the server from outside (but it doesn’t work also now…)

In LAN the automated page reload should redirect to https://<server_ip>:980 successfully, or am I missing something?

The steps would be

  1. try automated redirect to https://<server_ip>:980
  2. print https://<servername>:980 to let the user click the link manually

This is tipically the case in a double NAT situation where your Router NAT’s to a private subnet and in that subnet your NethServer RED interface is part of that private subnet. NethServer NAT’s to another private subnet where your GREEN interface is default gateway for the rest of your LAN.

I have this situation at home and it has been working like a charm for years. The only thing you need to be aware of that you can not have any clients on the subnet of your RED interface. This also means that if the router you use (probably obtained from your ISP) has an Accesspoint, you have to disable that accesspoint and add another Accesspoint on your LAN (GREEN subnet).

Yes, automated redirect on IP now works. But if you are out of the network, now you need to type manually the servername.

You mean to print the servername without autoredirect and the IP with autoredirect (that should works only when the IP is reachable) ?

Yes, exactly! I guess if the autoredirect doesn’t work the user clicks the link manually.

This is an alternative solution based on client-side script, that should work in any scenario.

1 Like

Wonderful! Tested and approved! :slight_smile:

1 Like