HTTPS connection to container breaks down after authentication.

Question

Hello community,

I try to run the openvas container from immauss (https://hub.docker.com/r/immauss/openvas) on Azure Container Instance (ACI).
At first I tried to work with the environment variables as recommended by immauss "HTTPS=true" and "SKIPSYNC=true". When I entered them into the portal, like described here (https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/container-instances/container-instances-environment-variables.md#azure-portal-example), during creation of the container instance under "Advanced" (Key1=HTTPS, Value1=true; Key2=SKIPSYNC, Value2=true) it hasn´t worked (same result as without variables). So the sync was not skipped and the provided web session was HTTP. At least I could get an unencrypted session with the browser but when I wanted to login the credentials where accepted for a short moment but then the login screen came back. In the container logs a positiv authentication request was logged and nothing else.
Then I modified the default of the variables in the project (https://github.com/immauss/openvas). In the document "scripts/single.sh" I changed the lines 20 and 23 from "false" to "true". When I build the container then locally and run it without any environment variables (-e in the docker command) it works with HTTPS and the SYNC is skipped.

docker build -t openvas:latest . (in the copied repository from immauss with the changed single.sh)
docker run -d -p 9392:9392 openvas:latest

So I pushed the project to github and built the container via Azure Pipeline and pushed the image to my Azure Container Registry (ACR). From the ACR I ran the container via ACI and Portal without any arguments besides port forwarding for 9392 on TCP. Now the container runs without any errors and the logs look nice but when I try to access the web frontend the connection is refused.
Safari says: "Safari can´t open the page "xxx.xxx.xxx.xxx:9392" because the server unexpectedly dropped the connection. This sometimes occurs when the server is busy. Wait for a few minutes and then try again."
I waited for more than an hour and I also setup the container with 2 CPUs and 8GB of RAM. Same problem.
I checked the availability of the port 9392 on Azure as described here:
https://learn.microsoft.com/en-us/azure/container-instances/container-instances-troubleshooting#container-group-ip-address-may-not-be-accessible-due-to-mismatched-ports
Possible problem: The test container is only running a HTTP site. Probably there is a problem with HTTPS and the self signed certificate. The other problems seem not to be the likely.
I tried to scan the client with nmap

nmap -Pn xxx.xxx.xxx.xxx

The result was the client is up but not responding on any port.
I now try to sniff the network with wireshark. Probably I can find something here.

Does anybody have an idea what I also could do about that problem?

Update:
It works now, if I use FQDN with "https://" in front and ":9392" at the end.
Now I have the same problem as with the HTTP connection before. When I enter the credentials (standard configuration username:admin, password:admin) I get a short glance of the dashboard but then the login screen reappears. In the container logs it just notes "Authentication success for ..."
Is there probably some kind of session management from Azure or so?!

Big thanks in advance!
Regards,
Christopher

Answer 1

I want to chime in and tell you I'm facing a similar problem.

I wrote a Go web server and it works perfectly anywhere really but specifically on ACI, despite the logs showing it's loaded, it takes about 15-20 minutes(!!!) for it to start actually responding to requests.

Azure Support's response hasn't solved my issue yet.