Exposing a behind-NAT OnlyOffice Workspace Service via SSH reverse tunnel

Workspace
1

I am trying to access my home server (behind residential NAT) online through SSH reverse proxy. The home server is a web server (Onlyoffice Workspace).

In the home server, I can confirm that the web server is running fine:

root@workspace:# curl "127.0.0.1/Auth.aspx?refererurl=%2fDefault.aspx"

Now, the host with public IP is a cloud server with Coolify (fwiw Coolify is like a self-hosted Heroku server). With Coolify I created a service to be the SSH tunnel through Docker compose:

version: '3.8'
services:
  reverse-ssh-tunnel:
    image: 'linuxserver/openssh-server:latest'
    container_name: reverse-ssh-tunnel
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - USER_NAME=webmaster
      - USER_PASSWORD=password
      - PASSWORD_ACCESS=true
      - SUDO_ACCESS=true
      - PUBLIC_KEY_FILE=/config/ssh/authorized_keys
    volumes:
      - './config:/config'
    ports:
      - '8889:2222'
    restart: unless-stopped
    labels:
      - traefik.enable=true
      - traefik.tcp.routers.ssh-tunnel.entrypoints=ssh
      - 'traefik.tcp.routers.ssh-tunnel.rule=HostSNI(`*`)'
      - traefik.tcp.routers.ssh-tunnel.service=ssh-tunnel-svc
      - traefik.tcp.services.ssh-tunnel-svc.loadbalancer.server.port=2222

And then set the service domain as https://<MY_DOMAIN>

Next, from within the home server web server terminal I can connect to the Docker SSH server (reverse-ssh-tunnel) in the Coolify cloud server via:

ssh -R 80:localhost:80 webmaster@1<PUBLIC_IP> -p 8889

However, accessing https://<MY_DOMAIN> or https://<MY_DOMAIN>/Auth.aspx?refererurl=%2fDefault.aspx after the supposedly tunneling

It just throws an internal server error. What could be wrong with my tunnel setup?

2

Hello @kerbymart
Sadly, I’m not sure that I can assist you in this scenario since it’s related to your NAT and network settings. I hope other users can share their insights.
Additionally, in another post you mentioned pangolin as a tool for public access and an issue with mixed contents. Probably these proxy configs might be useful as a guideline in HTTPS to HTTP scenario for Document server: