Please note that I’m using a subdomain that I own and control and my.domain.com is NOT a valid real domain I’m attempting to use. I’ve simply swapped mine here since it is irrelevant.
Actual behavior:
https://my.domain.com/support/ loads and accepts the https/ssl cert as vaild but gets stuck on a screen with the Zammad bird logo and “Loading…” while the console gives http 404 errors:
The overall flow of network traffic should be as follows: Client on Internet uses URL with https → Cloudflare DNS/proxied connection → Swag docker container (on host A) → Nginx reverse Proxy on said Swag container forwards traffic to upstream server on another intranet host (host B) → Zammad server responds and serves the full web app to the requesting client.
The current setup works fine from Client browser on the LAN to Host B:8080
Why the Virtual Machine (VM)? Originally I wanted to use Docker-Compose but this became more complicated than it was worth and all documentation I see for Zammad recommends using the application instead of docker containers. I was unable to get the Docker images setup to run even on the LAN. VM’s are a good middle ground that allow some level of privacy and modularization to keep it as a secure resource that’s also easier to backup and restore than tying it directly to the bare metal OS. I’m open to other ideas, but I had similar “Loading…” problems with the docker containers.
Other servers work quite fine via the Swag container to Nextcloud and Gitea, for example.
Nextcloud in particular requires certain Headers be set in the directive on the Swag container’s Nginx proxy config, it’s possible that Zammad does too, but I’ve yet to find documentation on what those are. This is different from the server itself, which is running on another physical server from the Swag container.
Installed Zammad 4.0.x via apt-get package on Debian 10 VM running inside Kubuntu 20.04 host system on Intel NUC x86_64 (Host B).
Zammad can be accessed via http://HostB:8080 on local network, basic first admin account was setup and system can be used, however without https/SSL/TLS
Configured Swag with the following zammad.subfolder.conf configuration file:
location ^~ /gitea/ {
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
set $upstream_app gitea;
set $upstream_port 3000;
set $upstream_proto http;
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
rewrite /gitea(.*) $1 break;
}
Hypotheses
I’ve a few hunches about what may be going on or need to change, but I’m thinking that the problem exists somewhere in the Swag proxy config as LAN direct connect over http works fine to Zammad. My guesses are:
Swag proxy config needs something else
There may be a CORS problem
There’s a trust issue on the origin server for Zammad where it doesn’t know to accept the request from the Swag proxy
Anyone have any thoughts on what’s wrong and how to fix it? I don’t mind grabbing some more relevant logs and such if you need those too.
I’m glad to be a part of this online community and look forward to being able to use Zammad and help out anyone else based on what I learn from hosting and using it.
Big thanks Floris, I’ll see what I can do, it helps to know that your implementation works. Swag is very similar to any Nginx reverse proxy so this ought to help.
Finally, some notes for understanding where I’m at:
Zammad server was moved to port 81 from port 80 directly in the zammad server config
Zammad port was changed due to using a different server on http://localzammad:80. The other server has web services that are on host machine, keeping in mind the zammad server is installed on a VM guest running on the same host. The other server is a container in docker.
Perhaps stating the obvious, but the LAN PC browsing to the LAN address works fine. Eventually I’ll block that connection, but I want the secure http WAN connection to be stable first.
Swag works fine for gitea, heimdall, nextcloud and so on. If I’m to change the configs, I mean to change only the zammad server’s proxy. Part of the problem I’ve had implementing changes to make my config more like Floris’s is that it seems to apply the changes to all the proxied hosts and configs, breaking them all simultaneously, including getting the http error 521 from zammad as well.
Because those changes break both current production servers and connectivity to zammad, I may not have it fully right. Don’t worry too much about outages on the production servers as I’m the only person using them right now.
The actual problem may be that my nginx reverse proxy/swag container needs to send the correct directive to allow communication over the ws protocol.
Thanks for anyone who has any ideas, feel free to share them here!
Thanks @MrGeneration that clears this up. I’ll see what I can do with a subdomain instead. These will be eventually routed to the same network and I hope that doesn’t cause any other problems.
Progress update:
After banging my head on the wall a bit yesterday (and honestly looking into alternatives) I was able to assimilate the good advice everyone has given thus far and identify some of the problems I was having.
Before jumping to the screenshots of the partial success, a few details and discussion:
The reason my swag config kept busting up my other servers is entirely logical and I’ve figured out how to mitigate it while troubleshooting this issue. SWAG being Secure Web Access Gateway functions like any gateway where the traffic comes in through it as a gateway but also bottleneck. With any secure setup you want to limit traffic to only authorized use within it. So changes to the bottleneck that effected everything in turn broke everything. In my case this was a change that will be temporary, but needed at the moment - I had allowed an nginx config block that forced all traffic (particularly over port 80) into the https port 443. After commenting this out, my existing servers worked and further I was able to add the subdomain support.my.domain/ for use with the zammad origin server.
The Mitigating strategy is that the nginx config update can be run by only touching the swag container via the command on the host machine: sudo docker restart swag following any config changes.
Using that understanding and the examples you provided @Floris and suggestions from @bernhardk and @MrGeneration ONLY (that is removing some of the template/boilerplate config from Swag’s built-in suggestions) I was able to get this to work.
The final step will be getting the connection to also use https with the SSL certificate on the Swag container. I suspect this will require adding a bit of the Swag nginx site-conf template’s directives back in, but not the ones that are redundant or break functionality.
Now, congrats to those of you who’ve commented and helped me with this project, here’s the screenshots of things so far:
I am really looking forward to being able to use this server in production. I’m working to provide more affordable IT services through my company to smaller organizations (startups, non-profits, NGO’s, etc.) Zammad provides a great tool for part of that stack. So thanks to the developers like @MrGeneration
Just in case I read and understand correctly, in case you’re planning to provide Zammad as a service for customers, please have a look at Zammads Policies just to be extra sure:
