Signaling server behind Apache

Hello there!

Can someon help me setup Nextcloud signaling server behind an univention server. My Univention server would be the public facing webserver. I set up may signaling server hopefully fine.
BUT I can’t figure out the virtualhost on univention.
My config currently is:
<VirtualHost *:443>

# ... existing configuration ...

# Enable proxying Websocket requests to the standalone signaling server.
ProxyPass "/standalone-signaling/"  "ws://192.168.1.71:8080/"

RewriteEngine On
# Websocket connections from the clients.
RewriteRule ^/standalone-signaling/spreed$ - [L]
# Backend connections from Nextcloud.
RewriteRule ^/standalone-signaling/api/(.*) http://192.168.1.71:8080/api/$1 [L,P]

# ... existing configuration ...

But I only get an 404 error. (I already enabled the site)

After some trys I managed to get a 503 error as well. If I put the internal ip of the HPB it works great.

I followed this guide:

and this guide:

I made a different ddns record and tried to use it as an alias in the front facing apache conf, but I only managed to get a 503.

Does this work from the server running apache?

curl -i http://192.168.1.71:8080/api/v1/welcome

What does

curl -i https://your-ddns/standalone-signaling/api/v1/welcome

from any other outside client yield?

Can you show me your redacted apache config?

Thank you for replying to my issue, I’m very grateful. Right now I’m only getting a “Connection refused”, but I’m sure nextcloud accepted the internal url before. So I must have messed up something along the way. Give me some time I’m gonna restore the HPB to a correctly working state.

Even if I do this in the VM I installed the signaling, I get this:
curl -i http://192.168.1.72:8080/api/v1/welcome
curl: (7) Failed to connect to 192.168.1.72 port 8080: Connection refused

It’s only works if I use curl -i http://127.0.0.1:8080/api/v1/welcome

I’ve moved away from my family an entire continent and I was planning to use Talk for keeping in touch with them. But Talk is so incredibly flaky I had to do the HPB setup all over again.
I managed to install and sort of setup the services (signaling, nat, janus, turn).
In nextcloud’s settings I can set up the high performance backend and it will say okay, but when I open the Talk app it either says it couldnt connect or that somethings wrong with my signaling server.
Since I followed this tutorial: How to Install Nextcloud Talk High Performance Backend with Stun/Turnserver on Ubuntu – Markus’ Blog (markus-blog.de)

And everything seems to be green on the server, I highly suspect my tries for the proxy, since I’m planing to run the signaling behind my web facing web server.

So far I tried theese reverse prox configs, without any luck.

Some help would be greatly appreciated,s ince if I can’t figure this out, I will have to abandon Talk, thank you!!!

<VirtualHost *:443>

    # ... existing configuration ...
   
    # Enable proxying Websocket requests to the standalone signaling server.
    ProxyPass "/standalone-signaling/"  "ws://192.168.1.73:8080/"

    RewriteEngine On
    # Websocket connections from the clients. !!! see the additional slash compared to
    # strukturag/nextcloud-spreed-signaling on github
    RewriteRule ^/standalone-signaling/spreed/$ - [L]
    # Backend connections from Nextcloud.
    RewriteRule ^/standalone-signaling/api/(.*) http://192.168.1.73:8080/api/$1 [L,P]

    # ... existing configuration ...

</VirtualHost>

^^^For some reason, this version wont even recognized by apache and it will says not found. ^^^

<VirtualHost *:443>

    # ... existing configuration ...

    ServerName signaling.****as.com
    ProxyPreserveHost ON
    ProxyRequests ON

    # Enable proxying Websocket requests to the standalone signaling server.
    ProxyPass /  "http://192.168.1.73:8080/"
    ProxyPassReverse /  "http://192.168.1.73:8080/"


    # ... existing configuration ...

</VirtualHost>
<VirtualHost *:443>

    # ... existing configuration ...
    ServerName signaling.***s.com
    # Enable proxying Websocket requests to the standalone signaling server.
    ProxyPass /  "ws://192.168.1.73:8080/"

    RewriteEngine On
    # Websocket connections from the clients. !!! see the additional slash compared to
    # strukturag/nextcloud-spreed-signaling on github
    RewriteRule ^/spreed/$ - [L]
    # Backend connections from Nextcloud.
    RewriteRule ^/api/(.*) http://192.168.1.73:8080/api/$1 [L,P]

    # ... existing configuration ...

</VirtualHost>

Do you have any firewall running? Or some geoblocking or things like that?

I’m seting it up from the same IP I try to test it, so if I can connect to the VPN there, I think I’m good with the firewall or geoblocking.

Hey!
So I guess I managed to get the farthest with this:
But it says:

“Failed to establish signaling connection. Something might be wrong in the signaling server configuration”

Is it still possible that my proxy isnt set up properly? Or its great and I screwed up something during the setup? I can curl the signaling service from anywhere!

<VirtualHost *:443>

    # ... existing configuration ...

    ServerName si***.***s.com
    ProxyPreserveHost ON
    ProxyRequests ON

    # Enable proxying Websocket requests to the standalone signaling server.
    ProxyPass /  "ws://192.168.1.73:8080/"
#    ProxyPassReverse /  "http://192.168.1.73:8080/"

#    RewriteEngine On
    # Websocket connections from the clients. !!! see the additional slash compared to
    # strukturag/nextcloud-spreed-signaling on github
    RewriteRule ^/spreed/$ - [L]
    # Backend connections from Nextcloud.
    RewriteRule ^/api/(.*) http://192.168.1.73:8080/api/$1 [L,P]

    # ... existing configuration ...

</VirtualHost>

Maybe the logs are showing some information? Signaling log, proxy log, fw log…

Hey,

it seems like I finally figured it out! So actually the last config for proxying works. The problem was that I’m using a couple of CNAMEs for my nextcloud server. YOU HAVE TO FILL IT OUT IN THE SIGNALING CONFIG WITH YOUR CNAMEs as well. I didn’t figured it out yet how to use it from different CNAME’s at the same time, butI guess that something I can live with. Thanks!