Connecting to a Codian from behind a PIX firewall

[televideoguy]

I have had an old problem re-surface while implementing a project and wonder if anyone else has come up with a workaround or solution to it. When a few sites in our network try to connect to our Codian 4220 from behind PIX firewalls, the connection just doesn't initiate. The CDRs log the endpoint and its E.164 number, but I also see an H.245 error message on the MCU and the endpoints won't connect. This has happened at two sites so far with both Tandberg and Polycom endpoints. In some cases, turning on error logging in the Codian allowed the sites to connect when we saw this, but doesn't seem to be helping now.
I recall that Codian had looked into this at one point and said there was some issue being caused by the 4220 putting two pieces of information within a single packet that couldn't be processed by the older IP implementation of the PIX on certain software versions - I can't remember the specifics now, but they said it wasn't really a Codian problem, but rather an issue with the PIX. At my location, am having no problems calling out to the Codian from either appliance or software endpoints, and my PIX is on the now old 6.3 (5) version, but would like to find out if there is a Cisco patch, Codian workaround, or endpoint config setting that will alleviate this problem for locations experiencing it.
I may just have to go to the remote location and set up Wireshark and watch what's going on...

Thanks for any advice you can provide!

[Joe Vallender]

Does the problem involve fragmented packets? If the originating side is generating fragmented packets due to a large amount of capabilities being advertised, the firewall may not be handling the H.323 messages properly.

[televideoguy]

That's a good thought. I did try disabling some of the caps on the Codian in hopes that would enable the endpoint to connect.

Through further investigation, I learned that the problem site's PIX is on 6.1 (4) not 6.3 (4) as I had believed earlier. I've read that 6.1 only supports h.323 1&2 and with 6.3 support for versions 3&4 were added, so I'm fairly certain that is the source of these symptoms.

[mboonedog]

Hi, are you able to pass other video calls thru the PIX? I ran into a similar situation using a routed (q.931) gatekeeper, which wasn't supported buy the PIX code. The call would fail after the gatekeeper sent the q.931 Connect message using the IP address of the bridge for the H.245 flow. That was 3yrs ago and Cisco said a fix was in the works to support routed GK's, but never saw if it was implemented.

[televideoguy]

At my location, I can connect to either the Codian 4220 or our MGC100s with no problems through our PIX and using our GNU gatekeeper. I can also call the Codian without a gatekeeper and even mix gatekeeperless connections and GK connections in the same event, which is very cool. The problem site can call the MGC100s using the GNU gatekeeper without incident, but can't connect when the Codian replaces the MGC with all other variables unchanged.

Interesting that you should mention q.931. While comparing Wireshark traces on my laptop connecting to both a Codian and an MGC100 using PVX through my PIX, I noticed that while using the Codian, there are two q.931/TPKT packets in one of the Ethernet frames and only one packet in the frame at the same point in call setup when connecting with the MGC. The source address indicates that the data is coming from our GNU gatekeeper - which I'd expect - but in connections with the MGC only one packet comes from the gatekeeper, according to the trace. Not sure why that is the case. I've heard that the root problem with the PIX is that the older software versions can't handle two packets in a single Ethernet frame. I'm looking into this and will let you know when I know more.

[televideoguy]

Supplemental: Codian was very responsive on this issue and did work with us to come up with a patch. Unfortunately (sort of) our test locations all upgraded their PIX units to 7.2 or higher by the time we had the patch in place, so we never were able to verify that the patch worked. The sites were able to connect as soon as 7.x was installed on the PIX devices. Subsequent Wireshark traces did show, however, that the doubled q.931 packets were no longer present in the call setup. One added note: Experienced users in our network tell me that the 7.0 version of PIX software was buggy and should be avoided at all costs. At my location, I only support a group of four, so we have a small PIX 501 that can't even run 7.x software. I am perpetually on 6.3 (5) here - at least until we acquire a new network security device.