| Author |
Message
|
| pichelma |
 Posted: Wed May 01, 2002 6:11 am Post subject: |
 |
|
Apprentice
Joined: 11 Mar 2002
Posts: 25
|
Hi all,
Was hoping someone could share an experience of channel problems w/ VPN & firewalling?
When we restart MQ or stop/reset/start channels on the reciever channel side.
The sender can connect "sometimes", it's just intermittent?
I have changed the channel attributes,(heartbeat int/long/short retrys/etc.) and changed the keepalive(right?)/port number(s) for the listener as well.
WE see retrying..sometimes...but mostly it is in the "binding" state.
I have looked through the Intercommunication manuals and related doc...nothing relevant yet!
I have checked google/deja for other posts, I have checked this forum and MessageQ, talked to IBM Supt. even! No one has any solid answers yet. Sigh....
Can someone please give me maybe another resource or hint/clue of some kind?
I know I must be missing something...probably an easy thing too!
Thanks again for any help!
Scott
|
|
| Back to top |
|
 |
| Cliff |
| Posted: Thu May 02, 2002 4:36 am Post subject: |
|
|
Centurion
Joined: 27 Jun 2001
Posts: 145
Location: Wiltshire
|
From memory, your problem may be that the sending qmgr is talking out on a port that the firewall blocks traffic from. I believe there is a parameter called MQTCPSDRPORT which limits the port or ports (you can specify a range) the qmgr talks out on. I imagine it's an environment variable on the distributed platforms and set in the CSQZPARM on OS/390 - I couldn't find it documented - can anyone else provide some details??
Regards,
Cliff |
|
| Back to top |
|
|
| pichelma |
| Posted: Thu May 02, 2002 6:46 am Post subject: |
|
|
Apprentice
Joined: 11 Mar 2002
Posts: 25
|
Thanks cliff!
I will try this out and see what happens...
Stil wondering about that FIRST connection(similiar to a DB, right?) MQS makes w/ the Qmgr's via the SDR/RCVR channels on each machine thru the network?
I have read the the SYN/ACK aspect of a handshake(communication via TCP/IP) between the machines never completes properly or takes a long time...meaning the channel goes into "binding" or "retrying" state?
Could our sending machine take longer if it lacks power?
Meaning, a measily PII (around 4/500 MHZ?) WinNT SP6a w/ 128 MB RAM and 2 GB HD w/ little swap space(256MB?) OVER a 56K Dialup connection thru a local ISP via VPN?
How do we know the ISP is NOT messing w/ our connection?
I thought VPN avoids any FW issues?
Wow, sounds crazy even mentioning all of this...did you understand any of that?
Hope so...
Thanks for listening...
Scott
|
|
| Back to top |
|
|
| jhalstead |
| Posted: Thu May 02, 2002 9:34 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
VPN creates a secure tunnel beteen two points. However in my experince (using a VPN software client talking to a hardware VPN controller) the VPN controller will usually have firewall functionality built into it. To be clear I've only done VPN between UNIX systems, however in general all this should be transferable.
Be sure that rules are set up for both directions of the TCP/IP conversation.
qmgr1 to qmgr2 communication, i.e. sender channel on qmgr1
qmgr1 will use a port > 1023 to talk to the listner port of qmgr2.
qmgr2 will reply from it's listner port to the port communication was initiated from so >1023.
qmgr1 to qmgr2 communication, i.e. sender channel on qmgr2
qmgr2 will use a port > 1023 to talk to the listner port of qmgr1.
gmrr1 will reply from it's listner port to the port communication was initiated from so >1023.
As mentioned above the MQTCPSDRPORT environmental variable can be used to restrict the ports from which sender channel will communicate (The security people do get a bit techy when you say >1023!). In UNIX your can ammend the .profile of the user which MQSeries runs under. In NT I guess you'd just create a new environmental variable.
Another think to watchout for is the idle timeout interval configured on the VPN controller.
For firewall specific details see support pack MA86. I've been told problems can be caused by NAT'ing... But we'll say no more about that.
I've also included a packet sniff of the channel connection establishing successfully - in this case qmgr1 had MQTCPSDRPORT=7500,7600
1 0.00000 <qmgr1> -> <qmgr2> ICMP Echo request
2 0.00185 <qmgr1> -> <qmgr2> TCP D=1414 S=7501 Syn Seq=22
83729788 Len=0 Win=65535
3 0.29807 <qmgr2> -> <qmgr1> ICMP Echo reply
4 0.00002 <qmgr2> -> <qmgr1> TCP D=7501 S=1414 Syn Ack=22
83729789 Seq=26787 Len=0 Win=8688
5 0.00149 <qmgr1> -> <qmgr2> TCP D=1414 S=7501 Ack=26
788 Seq=2283729789 Len=0 Win=65535
6 0.00877 <qmgr1> -> <qmgr2> TCP D=1414 S=7501 Ack=26
788 Seq=2283729789 Len=132 Win=65535
7 0.32116 <qmgr2> -> <qmgr1> TCP D=7501 S=1414 Ack=22
83729921 Seq=26788 Len=132 Win=8556
8 0.00009 <qmgr2> -> <qmgr1> TCP D=7501 S=1414 Ack=22
83729921 Seq=26920 Len=0 Win=32766
9 0.07864 <qmgr1> -> <qmgr2> TCP D=1414 S=7501 Ack=26
920 Seq=2283729921 Len=0 Win=65403
Good luck
Jamie |
|
| Back to top |
|
|
| rposey |
| Posted: Tue May 21, 2002 5:29 am Post subject: MQSeries through a VPN |
|
|
Newbie
Joined: 06 Jun 2001
Posts: 2
Location: DotsConnect
|
I may have an answer for you!
You say some of the messages make it through, correct.
A VPN Encapsulates a packet with a 40 byte header and a 40 byte footer if you are doing 3DES encrytion. By default your packet leaving your machine has an MTU (Maximum Transmission Unit) Length of 1500 bytes. When your packet reaches the firewall the VPN encapsulates the packet in this 80 byte Header and Footer. If your packet leaves the MQSeries machine at close to 1500 bytes when it reaches the firewall it will add the 80 bytes to the Packet and send it out to the next device in the network. The default standard for Packet in most Ethernet networks is 1500 bytes. If a device receives a 1500+ byte packet it will crop off the bytes beyond 1500 and take with it part of your data. Thus causing a loss of delivery for that message.
The solution for this is setting you MTU Size on the Server to less than 1500 bytes. We use 1284 bytes as a default MTU size on all our MQSeries servers going through a VPN. This fixed our problem and we haven't had a problem since.
The reason some of your messages make it throu is because the Packet is leaving the machine less than 1500 bytes. This MTU size needs to be set on both MQ Machines talking back and forth through the VPN!
Hope this does it for you! |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue May 21, 2002 10:53 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Are you stopping/starting receiver channels, well I can tell you this if you
reset the receiver channel you will have to also reset the sender side,
There is a sequence number that wil get reset to 1 and if you dont reset the sender the sequence numbers wont match and the channel wont start.
From a runmqsc session if you "dis chs(CHANNEL_NAME) indoubt" you
will see an indoubt status field if this is YES then the sequence numbers dont match and you need to do a resolve channel.
NOTE: stopping the reciever channels before you restart queue manager
may help the situation.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| GregJ |
| Posted: Fri May 24, 2002 7:12 am Post subject: Try this |
|
|
Acolyte
Joined: 24 Oct 2001
Posts: 69
Location: Markham, On. Canada
|
|
| Back to top |
|
|
|
|
