1. What is the issue? Please be detailed.
Exploring method to host ODK Central in Azure behind application gateway and SSL termination at application gateway. What are the changes need to make to .env and docker-compose.yml?
2. What steps can we take to reproduce this issue?
3. What have you tried to fix the issue?
4. Upload any forms or screenshots you can share publicly below.
Hi!
Yes, this seems to be possible. You can set up ODK Central behind a reverse proxy configuration [documentation reference], also Azure Application Gateway can be configured to entertain ODK Central and handle the SSL termination.
Hope this helps.. great day!
My setup is deploy a vm (private ip) behind application gateway.
I have try using upstream, change the .env and docker-compose.yml as suggested. I try additional step but nothing seem to work yet. 502 bad gateway
I stumble on a few issues with this setup. Thanks to the new AI integration in ODK docs, I manage to understand some aspect and try new ways that the AI have suggested. I hope some facts given by AI hold true and not make it worse.
The following are some trial and error:
Attempt 1 is not working. Still 502 bad gateway
Backed pool (8443), unlikely to work as there is no signed certificate according to AI.
However, once configure hosts:
domain vm_ip
and
extra_host in docker-compose.yml for enketo,
Finally, able to curl with http://domain:8080 . but curl with https://domain:8443 in vm (host) will fail.
Perhaps this has verified my first point.
Not sure this tweak is acceptable for production. Or, a private dns zone should be used instead.
Can anyone shed some glimpse of light here?
Hmm.. this should work in general.
Are you using the UPSTREAM_HTTPS_PORT=443 variable?
I think a key thing here is that the user --> proxy route is HTTPS, while the proxy --> central route is HTTP (you don't want double SSL wrapping, and would need a second cert for that)
So the proxy (application gateway) should route traffic to http://machine_ip:8080.
Have you confirmed the Central service is running locally? curl http://localhost:8080/v1/?
(if running in a container, be sure port 8080 is bound to the host in the compose file, so the nginx service is accessible to the application gateway)
yes. I use upstream mode and also use UPSTREAM_HTTPS_PORT=443.
In application gateway, backend pool is http.
Eventually I could login the hosted odk. However, when I uploaded the form, it returns 403 error
I have check docker log for nginx and service, but neither indicates this 403 error.
According to api documentation, 403 is relates to authenticator actor.
What could be the issues? Application gateway? token?
Hi, not sure but I would suggest checking the pyxform container logs:
Also, please try rebooting the containers / server.
I have checked:
NAMES STATE
central-nginx-1 running
central-service-1 running
central-enketo-1 running
central-pyxform-1 running
central-enketo_redis_main-1 running
central-enketo_redis_cache-1 running
central-postgres14-1 running
central-mail-1 running
Hmm.. that's interesting! If none of the containers showing any logs - then it's highly likely that the request is not even reaching the containers. That is - we need to troubleshoot Azure Application Gateway (WAF?) - that WAF is blocking the request content (maybe based on the size or content of the XLS file, or declaring it as a false positive, etc.). I would suggest checking the Application Gateway / Diagnostic / WAF logs (Azure monitor / log analytics). Try changing the WAF policy from prevention to detection only temporarily? Maybe that will help. If it starts functioning after updating the WAF policy, then we may customize the WAF policy to support ODK Central's functionality.
Edit: Yes, WAF returns 403 when it doesn’t like the request content.
