Zammad 6.0 Mobile view behind an apache reverse proxy

Technical assistance
1

Infos:

  • Used Zammad version: 6.0.0-1689860438.de5a066a.focal
  • Used Zammad installation type: (source, package, docker-compose, …) source
  • Operating system: Ubunutu
  • Browser + version: Mobile Safari / Mobile Chrome

Expected behavior:

Ability to access the new /mobile interface behind a reverse proxy

Actual behavior:

“The connection to the server was lost”

I have my Zammad install behind a separate Apache webserver, using it as a reverse proxy. I have gone and added the following line to the config on the reverse proxy:
ProxyPass /cable ws://192.168.1.244:3000/cable
192.168.1.244 is the internal IP address of the zammad server.

If I am local on the network and go to 192.168.1.244/mobile the page loads without issue
When I am remote and go through the apache reverse proxy I get the error.

I’m sure I’m missing something stupid here, but I’d appreciate any help.

1 Like
2

This is my full config on the reverse proxy, minus a few lines obscured.

<VirtualHost :443>
ServerName helpdesk.***********.com

SSLProtocol -all +TLSv1.2
SSLEngine on
SSLCertificateFile ***********
SSLCertificateKeyFile ***********

ErrorLog ***********

ProxyRequests Off
    ProxyVia Off
    ProxyPreserveHost On
    AllowEncodedSlashes NoDecode

<Proxy *>
	Order deny,allow
	Allow from all
</Proxy>

ProxyPass /cable ws://192.168.1.244:3000/cable

ProxyPass        /   http://192.168.1.244/
    ProxyPassReverse /   http://192.168.1.244/

    <Location />
            RequestHeader set X-Forwarded-Proto "https"
    </Location>
3

Hi @schmittg25,

you have to set the proper settings, http_type and fqdn. In your case https and helpdesk.***********.com.

https://docs.zammad.org/en/latest/admin/console/zammad-settings.html
https://docs.zammad.org/en/latest/admin/console/zammad-settings.html

4

Yep, and the FQDN is all lowercase too as I saw that in another thread.

5

… this means it’s now working fine, @schmittg25?

6

Sorry for the confusion, no it’s still not working. Just meant that I had already checked and verified that.

7

Please have a look at your production.log. What happens if the request from the mobile view to /cable is made? Is it successful?

Example:

I, [2023-08-04T07:17:35.007724#75029-211740]  INFO -- : Started GET "/cable" for 127.0.0.1 at 2023-08-04 07:17:35 +0200
I, [2023-08-04T07:17:35.060753#75029-211740]  INFO -- : Started GET "/cable/" [WebSocket] for 127.0.0.1 at 2023-08-04 07:17:35 +0200
I, [2023-08-04T07:17:35.061283#75029-211740]  INFO -- : Successfully upgraded to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: Upgrade, HTTP_UPGRADE: websocket)
8

Did you restart your Zammad instance after changing the http_type/fqdn?

9

If I attempt to access the mobile view externally (through my reverse proxy in my DMZ), no request ever appears in the production.log
If I attempt to access it internally, it shows this in the log:

I, [2023-08-04T08:10:47.791104#21044-685860] INFO – : Started GET “/cable” for 192.168.1.106 at 2023-08-04 08:10:47 -0400
I, [2023-08-04T08:10:47.794500#21044-685860] INFO – : Started GET “/cable/” [WebSocket] for 192.168.1.106 at 2023-08-04 08:10:47 -0400
I, [2023-08-04T08:10:47.794592#21044-685860] INFO – : Successfully upgraded to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: Upgrade, HTTP_UPGRADE: WebSocket)

So I had those settings correct before my 6.0 upgrade, but for the sake of testing, I restarted it and tried again and it didn’t change anything.

10

This means internally it works just fine, but by accessing from external, it shows the warning and it’s not working?

11

Maybe you could compare your apache config with this one: https://github.com/zammad/zammad/blob/stable/contrib/apache2/zammad_ssl.conf

In your config, it seems to me that some parts are missing.

12

Correct, internally it works, externally it doesn’t.

I posted the apache config in the 1st reply. The only thing I changed is the 127.0.0.1 to the IP of the zammad server.

13

Yes. Please compare and adjust it. If the response from external is not logged at all in the production.log, it’s a configuration issue with your apache I guess.

14

I did. It still isn’t working. That’s why I came here, for support.

The docs say it’s supported but that’s all they say.
https://docs.zammad.org/en/latest/prerequisites/software.html?highlight=Proxy#reverse-proxy

15

What you’re referencing to is the reverse proxy on the Zammad server directly, not a second in front of that.

Running web requests through several proxies / web servers is challenging and may come with trouble.
Or we’re all not speaking about the same.

16

I agree. I had Zammad working perfectly with this setup prior to the 6.0 release. These changes don’t have any documentation for anyone who uses a proxy for their setups.

17

The mobile UI requires websockets. The old desktop variant has an Ajax fallback.
So technically while it seemed to be working it was just falling back but still failed before.

In the future this will also affect the Desktop app.

18

So you have found a solution?

I have exact the same problem. Internally it works fine but if I connect from an external device the mobile view says „The connection to the server was lost“
We use a reverse proxy in our DMZ too. The cable rule in the Nginx config is set.

Maybe you have a solution and can describe it, please?
Needs websockets another port?
Only 443 and 80 is forwarded in my case.

Thanks!

20

Dennis1993,

Yes I did. Here is the code for my edge facing apache proxy (Note I sanitized a few things)

<VirtualHost *:443>
ServerName helpdesk.MYDOMAIN.com

SSLProtocol -all +TLSv1.2
SSLEngine on
SSLCertificateFile /path/to/file
SSLCertificateKeyFile /path/to/file

ErrorLog /path/to/file

ProxyRequests Off
    ProxyVia Off
    ProxyPreserveHost On
    AllowEncodedSlashes NoDecode

<Proxy *>
	Order deny,allow
	Allow from all
</Proxy>

ProxyPass /cable ws://INTERNAL_IP_ADDRESS_OF_ZAMMAD:80/cable

ProxyPass        /   INTERNAL_IP_ADDRESS_OF_ZAMMAD/
ProxyPassReverse /   INTERNAL_IP_ADDRESS_OF_ZAMMAD/

	<Location />
    RequestHeader set X-Forwarded-Proto "https"
	</Location>  

</VirtualHost>

This seems to have done the trick, thankfully. This helps…

1 Like
21

This topic was automatically closed 360 days after the last reply. New replies are no longer allowed.