[c-nsp] Question on h.323 video calls through a PIX 525 with NAT

[Steven Pfister]

I tried doing a capture on a call to the address that worked previously, but it's not working now, so I don't have a working/non-working setup to compare to.

I did get a packet capture of a failed call from outside the firewall. I notice that our side, in doing an openLogicalChannel, is showing the internal address in the H.245 section in Wireshark. This is a problem, isn't it? It would explain why audio and video get sent out from here, but nothing ever comes back from the other side.

Since the NAT transversal option is on at the video conferencing end on our side, and the inspect statements are in effect on the PIX, I'm not sure why this is happening. Is one fixing it and one breaking it again? Should I try without the inspect on the PIX?

Steve Pfister
Technical Coordinator, 
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us


>>> Andrew Yourtchenko <ayourtch at gmail.com> 7/15/2009 2:07 PM >>>
Hi Steven,

On Wed, Jul 15, 2009 at 6:28 PM, Steven Pfister<SPfister at dps.k12.oh.us> wrote:
> I'm having some trouble with h.323 (video) calls through a PIX 525 using NAT. We can get incoming calls fine, but not outgoing calls for some reason. My question has to do with 'inspect h323' vs 'fixup protocol h323'. What's the difference between them? The video conferencing unit in question has a NAT transversal option where I can supply an address and mask.I'm wondering if I'm having a NAT transversal problem anyway. Which one would handle the NAT transversal, inspect or fixup? Currently, the PIX config has:
>
>  inspect h323 h225
>  inspect h323 ras
>
> do I need:
>
>  fixup protocol h323 h225 1718-1720
>  fixup protocol h323 h225 1720
>  fixup protocol h323 ras 1718-1719
>
> instead of the inspect commands? In addition to them?
>

"inspect" is the name of the "fixup" from 7.0 onwards - obviously as
time went, some more enhancements were added.

you can enter the "fixup" commands, but they will be autoconverted
into the respective "inspect" under "magic" default policy.

You mention that the inbound call works - so a nice way to debug would
be to grab the pcap on inside+ pcap on the outside and study them in
wireshark for both failing and working scenarios and see what is
different.

The first cutover point is whether you see the tcp/1720 in the
outbound direction or not - if not, or if it is going to the wrong
address, would mean there is an issue related to RAS signaling - else
it's something with the call signaling.

The above can be tested much easier if you are able to make the direct
calls by IP address and the other party can accept such calls without
involving RAS at all - this could be an easy shortcut instead of
staring at the sniffer traces :-) - if the direct call using IP
address works, then you can further investigate RAS. If the inbound
calls to you work, most probably it is going to be the case, but worth
doublechecking.

The inspect in the default configuration normally should be able to
tweak all the embedded IPs both for RAS and call setup, so the
endpoints would not need to have any NAT awareness nor do any special
efforts to detect/traverse the NAT.

Also might be quite useful to have a quick test with another h323
stack if you can - openh323 had a very tweakable client, and ekiga can
do h323 video as well. If those work, again you get one more baseline
to compare the sniffer traces with.

cheers,
andrew