| Author |
Message
|
| TheBigEasy |
 Posted: Tue Jul 05, 2005 12:15 am Post subject: Firewall upgrade = channel dropping |
 |
|
Apprentice
Joined: 04 Jul 2005
Posts: 33
Location: London
|
Hi
We have upgraded our PIX firewalls to Checkpoint Cluster for a point-to-point link with a client (UNIX) from our AS/400. No WMQ changes made.
Sender channels were started manually to test the firewall rules - no problems.
Monday morning, messages begin to be passed - channels intermittently start dropping. Client manually stops then starts sdr chl - status goes to running (rcv also running), but quickly drops once the xmitq begins to drain, connection lost and messages backed out to xmitq.
Our sdr channel remains active, data successfully been passed.
We have an idea that this is to do with packet fragmentation - and the remote firewall performs a tcp reset and tears down the connection.
Any ideas please? |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Jul 05, 2005 3:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
See if the channel is logging error messages that indicate the TCP/IP return code - that may help.
Or use tcpdump and/or snoop to see what's going on at both ends.
Otherwise, examine the firewall log to see what it is doing to the traffic.
I doubt it's an issue of packet fragmentation, but it could be. Again, hopefully the firewall is reporting what it is doing at a level of detail to determine which rule or set of rules is causing it to drop the connection.
You aren't using SSL or otherwise tunnelling the MQ connection, are you? The firewall may be trying to do higher level protocol filtering (app level - 2?) and getting confused because it doesn't know MQ network protocols.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| TheBigEasy |
| Posted: Wed Jul 06, 2005 12:20 am Post subject: |
|
|
Apprentice
Joined: 04 Jul 2005
Posts: 33
Location: London
|
Thanks Jeff
We did a full trace with telco / networks and mq guys last night on both sides. Turned out to be a mismatch in IPSEC encryption software between two routers in a DMZ. Rotuers at the same os level did not work, the working solution had one router at a higher os level - I am guessing that our new firewall needs a higher level software for compatibilty.
The interesting thing about the WMQ during the testing - persistent messages left the xmitq inbound -> none received. The msgs were not rolled back, but when we tested with the encryption turned off, all the msgs flushed through. Always troubling when persisent msgs are floating around clouds that network folk like to draw.
Best wishes |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Jul 06, 2005 12:28 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The msgs were held in a prepared transaction on the xmitq. You could have seen this by checking the INDOUBT status of the channel.
This means that the network failure happened after the batch of msgs and the confirm flow were transmitted and before the confirm reply from the partner. The msg batch and confirm flow could easily have been in one physical transmission, so the channel had no chance to discover the network failure before the channel went indoubt at the end of the batch. |
|
| Back to top |
|
|
| TheBigEasy |
| Posted: Wed Jul 06, 2005 2:11 am Post subject: |
|
|
Apprentice
Joined: 04 Jul 2005
Posts: 33
Location: London
|
Hi Nigel
Thanks for the process explanation.
Luckily we saw this problem during the testing to find the network problem. The worrying aspect is that with live messages we would have lost the ability to move the messages from the xmitq in readiness for the dr route to be enabled.
Best wishes |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 06, 2005 2:35 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| TheBigEasy wrote: |
| The worrying aspect is that with live messages we would have lost the ability to move the messages from the xmitq in readiness for the dr route to be enabled. |
You would have been able to RESOLVE the channel with the BACKOUT option, at which point the INDOUBT messages would have been returned to the XMITQ, where you would have been able to move them off to another XMITQ to your DR site.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
