search

ibm-messaging / mq-helm

Apache License 2.0
25 stars 33 forks source link

Not able to connect to Queue manager running in AKS via MQ Explorer #92

Open Sumanth-A opened 2 weeks ago

Sumanth-A commented 2 weeks ago

Hi, We have setup MQ in AKS and networking within the cluster is implemented with Istio. I was able to connect and login to web console but when trying to connect to queue manager from MQ Explorer tool I get this error

"Could not establish a connection to the queue manager - reason 2009. (AMQ4059) Severity: 10 (Warning) Explanation: The attempt to connect to the queue manager failed. This could be because the queue manager is incorrectly configured to allow a connection from this system, or the connection has been broken. Response: Try the operation again. If the error persists, examine the problem determination information to see if any information has been recorded."

Is there a default username and password we'd have to pass like how we did for web console or do we need any other settings? Please let me know.

Sumanth-A commented 2 weeks ago

@arthurbarr, any help would be much appreciated.

arthurbarr commented 2 weeks ago

There are two main things to consider here:

  1. The MQ queue manager configuration
  2. The MQ Explorer configuration

IBM MQ does not configure users for you, in the queue manager or web console. The MQ Advanced for Developers container image however, does offer a simplified set up of two users called "app" and "admin". If you want to use these users, you need to turn them on, and set passwords for them. See https://www.ibm.com/docs/en/ibm-mq/9.4?topic=reference-mq-advanced-developers-container-image for some more information.

The connection from MQ Explorer (on your laptop) to the queue manager on AKS will be done using an MQ client. It will need to be routed correctly in the networking layer. In OpenShift, the HAProxy router uses the TLS Server Name Indicator (SNI) header to do that routing, so you need to configure MQ to use that. See https://community.ibm.com/community/user/integration/blogs/avinash-ganesh/2023/06/14/ibm-mq-queue-manager-on-ocp-kubernetes-cluster-mq?CommunityKey=183ec850-4947-49c8-9a2e-8e7c7fc46c64 for some more details. If you're using another sort of networking configuration, things will be different.

Sumanth-A commented 2 weeks ago

I've set both variables in the configuration, and for the connection from MQ Explorer to the queue manager, I've set similar route to allow connections on 1414. Verified there are no firewall denies and verified connectivity using network tools. Still I'm only getting "reason 2009. (AMQ4059)". I've ran a trace from the explorer and it says "MQQueueManager not defined to " does this mean anything?

Sumanth-A commented 1 week ago

Port 1414 is set for plain communication, does Qmanager expect TLS on this port too? if so can we use out gateway's TLS certs? or do we have to configure any certificates for Qmanager? @arthurbarr please help.

arthurbarr commented 4 days ago

Port 1414 can be used for TLS and non-TLS traffic.

Connecting via TLS is notoriously complex, as the underlying TLS code can't expose detailed error messages, as that could represent a security risk. It's all handled low down in the networking and security stacks.

Which certificates you need depends on which "gateway" you're using, and whether it is terminating the TLS connection or not. e.g. one approach is to use a "passthrough" mode on a gateway/router, which just passes the bytes directly across — this means that the client (MQ Explorer) needs the cert of the queue manager. If the gateway/router is terminating the TLS connection and making a new one onto the queue manager, then the client (MQ Explorer) will need the gateway's certificate, and the gateway will need to be configured with the queue manager certificate.