KB - Protocol mismatch causes service unavailability

Affects product

  • Microgateway
  • Ingress

Question or problem

Protocol mismatch causes unavailability of the protected service.

Error page shown in the client

Observation

The client is connecting to the service protected by Airlock Microgateway. An error page is shown with a request id. Airlock Microgateway does not show a single log entry about this request id.

Explanation

If the Kubernetes ingress controller tries to connect with HTTP to the HTTPS port of Airlock Microgateway, requests are blocked and no log messages are found. The situation is depicted here:

[K8s Ingress Controller] <--(HTTP)--> !!! <--(HTTPS)--> [Airlock Microgateway]

The Apache weblistener within Airlock Microgateway is accepting requests. In this scenario, Apache rejects connection attempts and clients will receive blocks, including valid Airlock request id (req_id). However, since the requests never made it to the filter engine of the Airlock Microgateway, which writes the summary log messages, no log message for these blocked requests are found.

Instruction

  1. Ensure that the Kubernetes ingress controller is connecting with the same protocol scheme than Airlock Microgateway is listening.
  2. Airlock Microgateway shows logs about the requests passed to the back-end service.
  3. The back-end service protected by Airlock Microgateway is accessible.

Ingress controller shows service not available

Observation

The client is connecting to the service protected by Airlock Microgateway. An error page from the Kubernetes ingress controller is shown that the service is not available.

Explanation

If the Kubernetes ingress controller tries to connect with HTTPS to the HTTP port of Airlock Microgateway, requests are blocked and no log messages are found. The situation is depicted here:

[K8s Ingress Controller] <--(HTTPS)--> !!! <--(HTTP)--> [Airlock Microgateway]

The Apache weblistener within Airlock Microgateway is accepting requests. In this scenario, Kubernetes ingress controller is unable to establish successfully a TLS connection. Therefore, an error page is displayed saying that the service is unavailable.

It might be confusing because all pods and services are up and running but the Kubernetes ingress controller says that the service is unavailable.

Instruction

  1. Ensure that the Kubernetes ingress controller is connecting with the same protocol scheme than Airlock Microgateway is listening.
  2. Airlock Microgateway shows logs about the requests passed to the back-end service.
  3. The back-end service protected by Airlock Microgateway is accessible.

Outdated links or content?

In case of outdated links or bad content, please let us know by sending an email with a short description of your findings. Thank you very much!