BLUEPRINT

Introduction

Replacing IBM Queue Managers in the DMZ with MQIPT to deliver a Secure and Cost-Effective approach to connecting businesses

The average person does not think about MQ very often, if at all. Nonetheless, most of us interact with MQ in one way or another daily.

From booking flights, sending money abroad, shopping online; to simply checking your online banking – MQ is involved, making secure and reliable data exchange possible, and it ‘just works’.

MQ is not just fundamental to end-user interactions with service providers – a large portion of organisations rely on MQ for their Business-to-Business communication channels. Often, those are organisations in the government and banking sectors where security and reliability are at the forefront of company values.

Figure 1: Common Infrastructure Scenario

Often, such organisations end up with an infrastructure setup similar to the one depicted in Figure 1. In those cases, an MQ Queue Manager is placed in the DMZ to act as a channel concentrator or single point of access fronting local queue managers.

This is a perfectly reasonable MQ architecture, albeit not very cost-effective. IBM MQ licensing is based on Virtual Processor Cores (VPCs), and therefore licenses must be purchased for the Queue Manager(s) placed in the DMZ. If a highly available DMZ MQ mediator is required, those costs start to multiply.

But there is an alternative, which reduces DMZ MQ mediator costs to zero.

What is MQIPT?

MQIPT, or MQ Internet pass-through, is an extension to the base IBM MQ product that can be used to connect remote MQ sites across the internet.

MQIPT is a standalone Java-based service that can receive and propagate MQ messages between queue managers or MQ clients and queue managers.

MQIPT is placed in the path between MQ endpoints and facilitates message exchange, without the need of a direct TCP/IP communication channel between them. Since MQIPT is an MQ endpoint, multiple instances can be chained to implement various configurations.

Why use MQIPT?

License Cost

One of the main reasons to use MQIPT from a commercial perspective is cost reduction. MQIPT is part of the base IBM MQ package, which means holding an IBM MQ license is also an entitlement for MQIPT [1].

MQIPT licensing is not based on PVCs, therefore unlimited MQIPT instances are allowed. This is especially cost-effective in highly available and/or load-balanced configurations where multiple instances are required.

Hardware Utilisation

MQIPT is lighter than IBM MQ in terms of system resource requirements. It can be deployed on a minimal Linux or Windows installation and requires very little space – mostly for logs.

This could be a decision factor in a cloud deployment scenario with fixed-size VPS instances or managed Kubernetes clusters where price is highly dependent on resource allocation/utilisation.

Simple Management

MQIPT instance configuration is managed in a single configuration file where all properties and route definitions can be specified. It comes bundled with a Java runtime environment, so it does not require anything else to be installed to get up and running.

MQIPT holds data in memory as it forwards it from its source to its destination, and it does not write data to disk (except for memory paged to disk by the operating system). The only time MQIPT accesses the disk explicitly is to read its configuration file and to write connection log and trace records [2]. Due to being effectively stateless, MQIPT can be easily managed in high availability and/or disaster recovery scenarios – all it takes is to stand up another instance with the same configuration file and redirect traffic.

MQIPT implements a log rotation strategy and allows the user to specify the size of backup logs to keep before rolling over. This allows fine-grained control over the already minimal disk space requirements, which can result in an extremely light footprint of the MQIPT instance(s).

Other non-functional requirements are also straight-forward to address:

• Backup: the only items of interest for backup are static configuration items and security assets (key/trust stores, certificates, etc.) – all conveniently bundled in a single directory.
• Uptime Management: MQIPT can be configured to run as an OS-level service (system or equivalent), implementing a suitable restart strategy.
• Monitoring: MQIPT writes connection logs to a single, well-defined location that can be piped into a log aggregation system for remote monitoring and/or troubleshooting in the event of a host failure.

Possible Configurations

From an MQ perspective, MQIPT is just another MQ node – client, server, or both – and is treated as such. Therefore, any high-level deployment configuration that can be achieved with a queue manager, can be achieved with MQIPT, as well – with small exceptions; see sections Limitations.

For the sake of brevity, we will not go through all possible configurations, but just touch on the common/base ones. More examples can be found in the official documentation for the product [2,3]. In many – if not all – use cases, the more complex deployment configurations are effectively base configurations chained together.

Figure 2: MQIPT- Channel Concentrator

It is worth noting the depicted component connections are generalised in the diagrams, but MQIPT can use either the IBM MQ Formats and Protocols (FAP) or an SSL/TLS protocol.

There are some compatibility items to consider based on the protocol used, but these are out of scope for this article [4].

Figure 2 depicts MQIPT in a channel concentrator configuration. The MQIPT instance has several routes defined, to allow queue managers on the different sides of a firewall to communicate. In this case MQIPT effectively runs as a proxy and destination queue managers only see MQIPT, not the source queue manager.

This configuration is useful when complex internal firewall rules must be managed. In the depicted scenario, the firewall only needs to allow inbound connections from MQIPT and does not need to know about the various hosts MQIPT is fronting.

Figure 3: MQIPT- Single point of entry

In Figure 3 the MQIPT instance is situated in the DMZ with several routes defined. Each route is allocated a port on the MQIPT instance. Clients connect to the exposed ports as if they are connecting to a queue manager. In reality, they are connecting to MQIPT, which forwards the traffic to the destination queue manager defined in the route for that port.

In this case, MQIPT can run either in proxy or server-client mode. Proxy mode preserves the connection context and only forwards it to the destination. In server-client mode, MQIPT acts as a ‘server’ from the perspective of the connecting application; and as a client, when connecting to the destination queue manager. In server-client mode a new connection context is established between MQIPT and the destination queue manager.

Server-client mode makes advanced security configurations possible. For example, the inbound (from MQIPT perspective) connection may be established in a different TLS context that the outbound connection – i.e., authentication between a client and MQIPT is separate from MQITP and destination.

In the depicted use case, MQIPT is a single point of entry, but also acts as a channel concentrator.

Figure 4: MQIPT- Mixed use cases

Figure 4 depicts a slightly more complicated scenario, encompassing several use cases for MQIPT.

Use Case 1: App1 from Business X needs to connect to QM2 in LAN2 of Business A.

In this case App1 and QM2 have their own certificates and exchange trust. MQIPT2 has a route configured in SSL proxy mode. This allows App1 to do mutual TLS with QM2 via MQIPT2, because the TLS context is preserved and just passed along. At the same time QM2 stays protected in a local network fronted by a firewall that allows traffic from MQIPT2, but not App1 over the internet.

 Use Case 2: App2 from Business Y needs to connect to QM3 in LAN2 of Business A.

In this case App2 needs to talk to QM3, but it does not do message encryption or MTLS due to some hypothetical constraint. QM3, on the other hand, expects clients to provide a trusted certificate.

To overcome this issue, MQIPT1 is deployed in Business Y and exposes an outbound route that acts as an SSL client. MQIPT2 exposes a different inbound route to QM3 configured in server-client mode. Certificates are generated and trust exchanged between MQIPT1 and MQIPT2. QM3 inherently trusts MQIPT2.

This results in the implementation of the following workflow:

• App2 connects to what it thinks is QM3 – in reality, this is MQIPT1.
• MQIPT1 initiates an SSL context and does mutual authentication with MQIPT2.
• MQIPT2 initiates another SSL context and does mutual authentication with QM3.
• The message is propagated to QM3.

 Use Case 3: Queue managers in LAN1 of Business A need to send messages to LAN2 queue managers.

This is a classic use case where MQIPT3 acts as a channel concentrator, hiding the machines in LAN1 behind a single firewall rule for inbound connections to LAN2.

Limitations

MQIPT has a lot of advanced capabilities and configuration options that are beyond the overview purpose of this article. Capabilities that do not exist can often be implemented as an ‘exit’ – a small program that can be attached to a route and ran for every message passing through that route.

With that said, there are very few situations where MQIPT limitations would justify using a full-blown IBM MQ queue manager, instead. And usually those are obscure limitations for very specific edge cases.

One such limitation, for example, is that MQIPT cannot participate in MTLS when the destination endpoint is an MQ queue manager, presenting a channel-specific certificate, as opposed to a queue-manager-wide certificate. When the MQ channel is switched back to using the QM-wide certificate, connectivity is as expected. This limitation was observed in MQIPT v9.2.1.0 connecting to IBM MQ v9.1.0 – later versions might not suffer from this limitation.

From the Field

At the core of Responsiv are some of the best integration specialists in the UK with countless combined years of experience. This is proven by our many success stories from clients in the government, financial, banking, automotive and retail sectors.

One of those stories, particularly around MQIPT, is with an international bank where we helped upgrade, refresh and reduce the on-going maintenance and license costs of their MQ infrastructure. All done in a methodical manner with attention to detail in every step – from inception; through analysis, design, discussion and decision; to execution.

Conclusion and next steps

MQIPT is a cost-effective way to create a point of connection and control for MQ messages that are passing through the DMZ or between control regions.

We have no doubt that MQIPT will add value and be a candidate solution in any situation where messages are passing between businesses or between departments.

If you recognise the situation or have a problem that sounds similar, then we look forward to our first conversations.

*By pressing submit you agree to receiving communication from Responsiv. You may unsubscribe from communications at any time.