How the sequence numbers work is an MQ internal and changes from time to time. However, my understanding is that the channel status records are keyed by a combination of attributes that would make the second B2B Edge QMgr unique, assuming it has a different name. QMgrs that apps connect to directly may have dependencies on the QMgr name (which I abhor) but a B2B Edge QMgr is used only for routing and that should be based on QMgr aliases (aliai?) and not the name. So if the pair of B2B Edge QMgrs are not exact clones, the seq numbers should be managed separately. This is how RQSTR channels on different QMgrs are able to start the same SVR channel and have it work.
That said, I've seen several cases using scripts (preferably that run on the B2B Edge QMgrs and not the internal ones) to spot a sequence number error and reset the inbound to match. Haven't seen these lately and I assumed it was because they were no longer necessary but I haven't tested.
So either it works the way you expect right out of the box or else it's easily fixed with instrumentation. In any case, clustering through the firewall represents much greater exposure and risk by far than SDR/RQSTR channels, even in the worst case that some instrumentation is required.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Tuesday, October 01, 2013 8:19 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ cluster, proxy, and NAT
âWhen I said multi-instance CONNAME that does not necessarily imply multi-instance QMgrsâ
:-? I thought it did. Otherwise the sending QM flipping to the secondary conname in its SNDR channel definition would only find itself talking to a RCVR channel on other QM and the sequence numbers would be off.
I had assumed you were going down the path of proposing traditional point to point channels (SNDR/RCVR or SNDR/RQSTR), optionally thru MQIPT, between companies, where the availability concerns of the single Edge Queue Manager is mitigated by making it a multi instance QM.
How else can you use multi instance CONNAMES in a QM to QM channel if not to a multi instance QM? To a Backup QM I suppose is one option.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: Monday, September 30, 2013 5:01 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ cluster, proxy, and NAT
Understood. Quick clarification on one point, though. When I said multi-instance CONNAME that does not necessarily imply multi-instance QMgrs.
Without MCAUSER and CHLAUTH, the QMgr can be administered by the adjacent upstream QMgr. If none of the QMgrs have this protection, it's possible for someone outside the company to have complete administrative control, including the ability to execute arbitrary OS commands, on the internal QMgrs. Hopefully the "discussion" revolves around either securing these effectively or else getting that "get out of jail free" memo I mentioned in the previous email. Keep escalating until you find someone with funding authority who *could* make it happen but signs off on the risk. It can be marginally helpful to get sign-off by someone not actually in a position to fund the remediation but not ideal. I have from time to time seen Operations managers sign off on risk rather than telling the business users about it or spending their political capital trying to get the remdiation funded. Then when the business users find out just how exposed they are, the Ops manager scapegoats the WMQ admin claiming they hadn't been properly informed.
(On the other hand, the people I've known who were fired over this have universally said later it turned out to be good for them. Companies who ignore risk until they can't hide it any longer and then blame the exposure on the very line manager who tried to do something about it tend to be sub-optimal as employers.)
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of LM Demey (MQ)
Sent: Monday, September 30, 2013 16:16 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ cluster, proxy, and NAT
Hi TRob,
In this project, no choice, I *must* !
The whole setup is a little more complex:
There are three interconnected clusters, the one in the middle act as gateway and contains cluster alias queues and alias Queue Manager cluster.
No apps nor triggering in the middle cluster.
Strict routing rules (a bit too much for now!) protect servers and SSL with SSL peer filtering will be configured.
MCAUSER and / or CHLAUTH are still in discussion.
Multi-instance was not a solution because by design there is no way to share a disk between data centers.
Clearly there would still be room for improvement, but compared to what we see in other cases, the security level is reasonable.
As usual, the goal is to build a sufficiently advanced system, but still manageable and understandable by operators in charge of production.
Regards, LMD.
Le 30/09/2013 16:27, T.Rob a écrit :
Hi Luc-Michel,
I'm a strong opponent of clusters across B2B boundaries. However, if you *must* do this, consider the following:
1. Make sure your CLUSRCVR has an MCAUSER that does *not* allow inbound messages to land directly on any transmit queue or the command queue. Ideally, use v7.1 or higher and set up dynamic MCAUSER on the CLUSRCVR channels to restrict inbound channels from internal and external QMgrs to different sets of objects.
2. If you use triggering in any way, also disallow messages from landing on queues that trigger monitors listen on.
3. Make sure the firewall rules enumerate the specific IP addresses and ports used by the channels and not routing an entire subnet.
4. Do not allow the B2B QMgrs to participate in your regular internal cluster. Instead, set up an overlapping cluster that contains only the subset of QMgrs which require the ability to exchange messages with the B2B edge QMgrs. (Make sure the cluster channels are unique to the cluster and do not use a cluster namelist. Another example of why the convention TO.<qmgr> is so horrible.)
5. Make sure that all routes through the QMgrs only pass through enumerated QALIAS definitions or QREMOTE definitions. No application queues on the B2B edge QMgrs, no QMgr-routing through XMitQs.
6. Make sure that the internal QMgrs similarly use restricted MCAUSER values on their CLUSRCVR so that messages arriving from the B2B edge QMgrs cannot go to unspecified queues.
And for anyone reading this and thinking "oh good, here's a handy checklist to secure a B2B cluster", please don't. It's a checklist to somewhat mitigate the vulnerabilities of a B2B cluster and that's all. There is no way to secure a B2B cluster adequately because to offer B2B clustering is by definition to allow an extraordinary amount of visibility and control into the local network up to, in most cases including, full admin access. Remember that one of the stated design goals of WMQ clusters is specifically to relieve you from some of the administrative tasks. There is no option for clustering that says "please do the helpful load balancing things but don't do the administrative things and don't expose my entire namespace to the cluster." Even if a CHAD exit enforces policy on the channels, you don't get the benefits of clustering without giving up control of the cluster's namespace, which means control of how the resolution of routing works.
The right answer here for Luc-Michel and anyone else using B2B clusters is to get to V7.1 or higher and use multi-instance CONNAME and CHLAUTH rules at the edge QMgrs for the external-facing channels. Those QMgrs can participate in the *internal* cluster but not offer clustering to 3rd parties. Between the QMgr and the business partner can be MQIPT and all of the security described in the Redbook but this is the minimum on the QMgr itself.
If you are a WMQ administrator and have a B2B cluster, please make certain that you have either received sign-off from someone higher than your pay grade who has accepted the extraordinary risk (and get this updated yearly), or that you have definite plans to move to a modern version of WMQ that does not require clustering through the firewall.
If you are a WMQ administrator and have either a single B2B cluster that is used by multiple 3rd parties or else have B2B edge QMgrs that participate in multiple overlapping B2B clusters, then sell your stock and update your resume.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of LM Demey (MQ)
Sent: Monday, September 30, 2013 9:46 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: MQ cluster, proxy, and NAT
Hi Neil,
Thank you for the information, it does appear to be an excellent solution.
MQ clusters are here to ensure high availability of MQ link between the two companies. In fact there are on each side of the proxy two Partial Repo, located in different data centers, a way to maximize the level of service.
Initially, the technical architecture was not made ââby me, so I could not offer the MS81.
I've used it in a simple configuration, but this function is totally under-marketed by IBM (MQ 81 = an obscure supportpack!). So it is difficult for customers to think about it.
I will implement your suggestion about host names. Thanks.
Le 30/09/2013 06:23, Neil Casey a écrit :
Hi Luc-Michel,
there are a couple of different issues here, and you have correctly identified that proxy addresses are one of them.
Firstly I would generally recommend to try to avoid using MQ clusters for B2B connectivity because they make management of the separation of the administrative scope much more difficult. They can also present some security challenges. That being said, if you do go down this path, there are a couple of things that you can do.
1. Use MQIPT. MQIPT with it's socks proxy capability can help with some of the issues with address resolution, and also help with SSL certificate validation and allowing your queue manager (actually MQIPT) to present different certificates internally and externally, or to different external partners.
2. Use host names in the receiver channel conname field instead of an address. Then use the /etc/hosts file to resolve the names. This allows your internal and external address resolution to be different, which is needed for a cluster to work as you have described. The internal servers can define the actual addresses. The external servers can define the natted addresses.
Regards,
Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: +61 414 615 334
On 30/09/2013, at 7:45 AM, LM Demey (MQ) <lmd-4gGhCVI4xPzA+***@public.gmane.org> wrote:
Hi all,
I just came across an unexpected configuration problem on MQ clusters.
Consider an MQ cluster that allows the exchange of messages between the two companies.
Here is an extract of the configuration:
QM1
company A
Full repo
DMZ 1
192.168.0.1
QM2
company A
partial repo
DMZ 1
192.168.0.2
QM3
company B
partial repo
DMZ 2
192.168.1.3
DMZ1 DMZ2 and are connected by a proxy that is doing NAT:
192.168.1.1 is natted to 192.168.0.1
192.168.0.3 is natted to 192.168.1.3
To contact QM1, QM3 specify IP 192.168.1.1 in the CLUSSDR, this IP will be natted to 192.168.0.1 by the proxy. So QM3 is able to communicate with QM1.
But the return channel can not be established because the Full Repo attempts to contact QM3 on 192.168.1.3, which is not known in the DMZ2.
The solution seems to be to configure the channel CLUSRCVR in QM3 with 192.168.0.3, so that the address would that be natted to 192.168.1.3 while crossing the PROXY.
In fact it is necessary that all CLUSRCVR channels not indicate the IP address of QM, but that by which they are known to the proxy.
As a result, the link between QM1 and QM2 will also have to go through the proxy
What do you think? Is this the right way to configure a cluster MQ located on either side of a proxy?
Thanks in advance
--
Luc-Michel Demey - Freelance WAS & WMQ Expert
http://www.demey-consulting.fr/ - lmd at demey-consulting dot fr
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com <http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com <http://www.lsoft.com/resources/manuals.asp>
--
Luc-Michel Demey - Freelance WAS & WMQ Expert
http://www.demey-consulting.fr/ - lmd at demey-consulting dot fr
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com <http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com <http://www.lsoft.com/resources/manuals.asp>
--
Luc-Michel Demey - Freelance WAS & WMQ Expert
http://www.demey-consulting.fr/ - lmd at demey-consulting dot fr
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com <http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings <http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com <http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html