Trying to use Reverse Proxy, I seem to fail completely

NethServer Version: 7.7
Module: web server

Here are my data starting from “outside”:

  • 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.
  • My NS internal domain is local.mydomain.org (AD).
  • My NS domain is mydomain.org, so the FQDN of NS is quasar.mydomain.org.
  • From a client PC, from command all the below FQDN ping properly and return the IP of my NS:
    quasar.mydomain.org
    quasar.local.mydomain.org
    mymail.mydomain.org
  • 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.

What am I doing wrong?

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

http://docs.nethserver.org/en/v7/webtop5.html#change-the-public-url

We could ask @lucag: does it work without /webtop too?

1 Like

For Webtop you need to add this in Virtual Host config:

RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
RewriteRule .* wss://<webtopserverip>%{REQUEST_URI} [P]

and it should works.

1 Like

Thank you.
But can you elaborate a bit?

  1. Where is that config to edit.
  2. Where do I add those? In the bottom of the file?
  3. Why? Is this a bug? Something that will be fixed some time?

@pagaille, do you have some hint for Nick regarding the reverse proxy and webtop?

If it’s still relevant, there was an effort to bring a dedicated virtual host for webtop. Maybe some of the code could be reused:

1 Like

:thinking: I don’t know really - all I did was creating a simple virtual host in Reverse Proxy :

1 Like

OK. Thanks, like always, for jumping in and helping. :wink:

1 Like

Guys this is what I did and doesn’t work.
I think we are square one.

Did you disable the virtualhost? If not, it will be used instead of the reverse proxy.

2 Likes

Erm… I need to check that.
(although I think the virtual host was created exactly because reverse proxy was not working)
Will get back to you.

What about the code posted by federico? Do I need it?

EDIT: I think it works! (so maybe I had the virtual host from the start and I needed to delete it)

1 Like

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:

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

  2. I created an entry for nethgui (i.e. NS domain at port 980). Trying to access this, produces

Nethgui:
404 - Forbidden
1504084156+1504084157

  1. Did the same for Cockpit. Takes me to login screen properly. After entering credentials, blank page.

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

If you look at the browser error console when you get the cockpit blank page, you’ll find an error about a not working websocket connection.

For these cases you need manual configuration.

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

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.

1 Like