$Target is either http://destination or https://destitiation in the Nethserver.
=~ |http|| just replaces http with nothing so leaving either an empty string “” (in case of http) or an “s” (in case of https).
Then it appends this expression to “ws”, giving either “ws” or “wss”.
I still have the same problem reported some days ago even with the new implementation.
What issue, I can reverse to mattermost without complains about websockets ???
As already said: It is impossible to solve your problem if you don’t explain your exact configuration as requested several times. What exactly did you enter in the reverse proxy entry?
These are the my tests.
mattermost.test.local=VhostReverse
CertVerification=yes
Description=
HTTP=no
HTTPS=yes
PreserveHost=no
SslCertificate=
Target=https://nethservice.nethesis.it/webtop
ValidFrom=
WebSockets=enabled
mattermost.test.local=VhostReverse
CertVerification=yes
Description=
HTTP=no
HTTPS=yes
PreserveHost=no
SslCertificate=
Target=https://mattermost.nethesis.it
ValidFrom=
WebSockets=enabled
Targets are fully functional using a Let’s Encrypt certificate.
Try to deactivate CertVerification and turn on PreserveHost.
Also it might be the problem of the URL setting of Webtop.
In my setup I set the backend URL in webtop to cloud.mydomain.de/webtop which actually points to the front end reverse proxy server. This worked fine.
I’ve spent some more time on testing the PR, I’ve finally managed to make the proxy pass work for mattermost but just in one case: name on proxy is mattermost.nethesis.it, target mattermost.nethesis.it, it works only after removing the automatically created alias and enabling the PreserverHost option.
If I try to proxy mattermost.test.local to mattermost.nethesis.it it doesn’t work, tested also with all combinations of PreserveHost and CertVerification.
I couldn’t make it work in any way with WebTop.
Which automatically created alias? In which server? Front-End or backend? On the frontend there is a problem when Webtop5 or Matterhost ARE or WERE installed as the configuration interfere with the reverse proxy (which is actually a bug, see discussion mentioned above).
In general: The backend server must be configured in a way that it could be placed directory on the internet. This includes the externel URL settings for NextCloud and Webtop (with the exception, that you don’t need certificates). The frontend server has to listen to the external URL configured at the backend server and has a reverse proxy entry for the whole subdomain to the backend server. This entry could also use an IP-address instead of a host name (but must have certificates ignored).
This is because the applications include bac kreferences in the html code which are not translated from the front end reverse proxy (unless an additional request and rewriting parsing module is installed).
Please post you webtop5 configuration, i.e. reverse proxy entry, external URL of the backend webtop5 and domain name of the front end server.
Frontend: the alias is automatically created by proxypass UI. The machine is clean and there wasn’t webtop nor mattermost installed.
Proxy pass for webtop:
#
# Virtual Host webtop.test.local - *:443
# Description :
<VirtualHost *:443>
ServerName webtop.test.local
# Start Rewrite Engine
RewriteEngine On
# forcessl_redirect
RewriteCond %{HTTPS} !=on
RewriteRule (.*) https://%{SERVER_NAME}$1 [R,L]
#20ssl_engine
SSLEngine On
SSLProxyEngine On
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
# Reverse Proxy (with exclusion of local Letsencrypt challenge path)
ProxyPassMatch ^/.well-known/acme-challenge/ !
# Websockets proxypass
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule .* wss://nethservice.nethesis.it/webtop%{REQUEST_URI} [P,L]
ProxyPass / https://nethservice.nethesis.it/webtop/ max=3 retry=30
ProxyPassReverse / https://nethservice.nethesis.it/webtop/
<Location "/">
<RequireAll>
Require all granted
</RequireAll>
</Location>
</VirtualHost>
[root@test ~]# hostname -f
test.local.neth.eu
[root@test ~]# db proxypass show webtop.test.local
webtop.test.local=VhostReverse
CertVerification=yes
Description=
HTTP=yes
HTTPS=yes
PreserveHost=no
SslCertificate=
Target=https://nethservice.nethesis.it/webtop
ValidFrom=
WebSockets=enabled
So, if the virtual host configuration is broken, please suggest the fix directly into the PR (using code suggestion) and I will check again.
got it workable to reverse to the localhost:8065 for mattermost and localhost:58080 for webtop
Indeed it doesn’t work OTB when the websocket proxypass is remote
but when I reverse to a remote mattermost
websocket_client.jsx:38 WebSocket connection to 'wss://toto.com/api/v4/websocket' failed: Error during WebSocket handshake: Unexpected response code: 403
For WebTop did you set the public URL in the settings correctly (must be the front end server)?
Did you also check the problem I hat and solved in Reverse proxy subdomain to secondary application Nethserver
Maybe we should have a look into it in a remote session.
honestly I tend to meet the point of @giacomo, this could work, but it might also not work and create issue in the community or the enterprise version.
Like you point (nicely) to me, we have to trick some url to possibly make it works. People waits after something working out of the box, not after something that could work.
Maybe the best way is to drop a vhost configuration manually. Except if you would like to help and drive the development, I think I will close my PR
It DOES work out of the box at my place. I only did the follwing
Ensure that neither of the applications were installed at some time at the frontend, because they leave configurations even after uninstall.
Enter the correct public URL in the backend NS for WebTop
Apply my WebSocket patch.
Create Reverse-Proxy from frontend subdomain to backend subdomain.
I think this configuration is something which should work OTB, because especially in enterprises it is common to separate the firewall from the application servers. NS should support this configuration output of the box.
If it does’t work at your place then this should be resolved. Technically and in documentation for all the service Nethserver offers. It should be just a couple of mintues to redirect all services from a frontend reverse proxy and firewall to backend servers.
BTW: I was almost considering abandon Nethserver in the frontend because of the problems I had.
I would like to contribute in having Nethserver be able to proxy all its own services from a frontend Nethserver to a backend Nethserver without heavy debugging and changing templates. There seem to be other issues which prevent this and should be resolved and I would be happy to work with you on the solution.
My concern is I am not sure this solution is a fully workable and reliable, it could depend of the web application and must be probably adapted to the context
By the way, you created the wrong target. With that you get a double webtop/webtop generated in the URL which leads to an 403 error. Frontend https://frontendserver/webtop gets mapped to https://backendserver/webtop/webtop which cannot work.
The target has to be just https://backendserver (in your case https://nethservice.nethesis.it) not https://backendserver/webtop.
if I set to reverse webtop
ns7dev4.org is the reverse backend
then magically it works, but how would you like explain it in the documentation 
toto.com=VhostReverse
CertVerification=yes
Description=
HTTP=no
HTTPS=yes
PreserveHost=no
SslCertificate=
Target=https://ns7dev4.org
ValidFrom=
WebSockets=enabledYes, that should be in the documentation and it took me some time to figure this out, because nothing was mentioned in the documentation. If you leave it empty, then you see the default in grey, which is the internal backend server name, but this has nothing to do with the public URL from the internet and be definition the backend server is NOT reachable from the internet…
Webtop generates urls based on this setting, and in my case this was already wrong with only ONE Nethserver, because this internal server name is NOT the public URL. It is like you don’t name your Nethserver “www” as the hostname to serve http requests to your domain www.yourdomain.xy. This default is a bad choice anyway. Why webtop needs this settings and does not use relative paths is another question. This settings should be not be neccessary at all in an ideal world.
Also keep in mind, that there is a big difference wether you reverse proxy a whole subdomain or a path, which is documented in the documentation. There are different templates used. In an ideal world both should work and should be documented.
Just to note: also this configuration from you is not correct and only works by pure chance, because you set the target URL to the insivible backend server, but it must be set to the visible frontend server URL as it is seen from the internet. I would expect that it doesn’t work from the internet.