In external DNS (my host provider) I have defined mymail.mydomain.org to point (CNAME) to my dyndns IP. (this part works)
In my router I port forward HTTP and HTTPS (and some other) traffic to my NethServer.
In my NS (NethServer), in Virtual Hosts I have defined mymail.mydomain.org as one.
In my NS DNS settings (which is the primary DNS of my internal clients), I have defined quasar.mydomain.gr and quasar.local.mydomain.gr to point to my NS own IP.
From a client PC, from a web browser all the above FQDN send me to NS home page (the one that says “Congratulations, your NethServer installation is up and running!”).
Any of the above with /webtop in the end, takes me to webtop.
Now… I want to do this:
Use NS own Reverse Proxy and define mymail.mydomain.org to point to https://quasar.local.mydomain.org/webtop.
Unfortunately no combination I tried works. Using the IP as destination (plus the path), using internal or external domain, forcing or not forcing HTTPS (and ignoring certificate as it is the self signed).
When I try to use https://mymail.mydomain.org (from external network - i.e. my smartphone with closed WiFi and using 4G) it gets ignored and still takes me to NS home page and not to webtop.
IIUC you want to reach a webtop in LAN from both the LAN itself and from the Internet. And webtop URL has to be something like https://mymail.mydomain.org.
Is that right?
Probably “virtual hosts” and “reverse proxy” are not the right tools to configure webtop here! They are designed for third party web apps. Web applications like webtop (already integrated) have their own Apache configuration for specific use cases.
In the manual we have an example about customizing the public webtop URL that still has the /webtop path suffix.
Well stop the press, this is not closed yet. MORE WEIRD ISSUES!
I am doing further tests to see how accessible things are from the Internet.
NOTE all subdomain rewrites I use, I also have appropriate DNS entries in my public DNS.
The entries are all CNAME and all point actually to my dyndns domain (which was not a problem before using a reverse proxy and worked fine) and reach my NethServer.
So now I am doing kind of “double rewrites”.
All reverse proxy entries enforce HTTPS and have all the ticks ticked in advanced settings.
So here are the weird things I noticed testing the reverse proxy:
I made an entry to point to my host unRAID server web GUI. Note my unRAID is the host of my NethServer VM. So the rewrite is both to a completely different FQDN and to a specific port. THIS WORKS (from outside).
I created an entry for nethgui (i.e. NS domain at port 980). Trying to access this, produces
Nethgui:
404 - Forbidden
1504084156+1504084157
Did the same for Cockpit. Takes me to login screen properly. After entering credentials, blank page.
*** CRITICAL ISSUE ***
WebTop doesn’t work that well after all. It seemed to login fine. Then I am taken to a URL that is actually the subdomain I defined in reverse proxy BUT ALSO the path /webtop! This takes me to the main WebTop GUI, BUT (here is the most weird thing)… in the list of services offered, I HAVE NO MAIL!!! I have home icon, admin, calendar, contacts, tasks, cloud, but NO MAIL and there is a notification bell that “server is unreachable”.
After this happened, my WebTop installation has major issue logging in! I deleted the reverse proxy entry for it and used the proper URL and still after login it fails!
It pops “error” and over that “mail account authentication error”!
This is major as I cannot actually login to my email!
Help?
EDIT: Critical issue resolved. I rebooted NethServer VM and WebTop resumed operation. I am a bit scared to experiment on my production system with reverse proxy right now.
I don’t know if it’s possible to make reverse proxy work with cockpit or nethgui.
I tried with cockpit but without success.
This code could be included in the manual configuration.
Webtop uses a websocket too so I assume you need it but I never tested.
No risk, no fun.
Usually adding or removing virtual host reverse proxies shouldn’t raise big problems because only a specific domain name (maybe not even used before) is affected if something goes wrong. In that case just remove the proxies/files and everything should be working again.
One of nice things of virtual environments is that a lot of tests can be done in “quite a safe way”, until you take care of backup, snapshots and consolidation.
Another nice thing to use a product that do not have license limitation is than you can install machines as much as you need for any kind of test.
So… Just test as pro play chess: create a lot of path with full explained (and planned) steps.