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

[Andrew Yourtchenko]

On Wed, Jul 15, 2009 at 8:58 PM, Steven Pfister<SPfister at dps.k12.oh.us> wrote:
> Yes, tcp/1720 seems to be going to the correct address. The thing I'm wondering now is this... I did the capture on the PIX itself on the outside interface. I've found at least one spot where the internal address for the unit on our side appears.

If the rfc1918 address is seen on the outside (presumably in one of
the openLogicalChannel/openLogicalChannelAck exchanges?) - then it
would be a very good reason for the media streams to not reach you
from the remote end.

>I would have thought the NAT transversal setting on the unit itself would have taken care of this before hitting the PIX. And the capture being on the outside interface... would it be showing the packets before or after inspect has gotten to them.

capture is in the packet path shortly before putting the packet onto
the low-level driver for transmission. So, it's after all the inspect
work is already don (if we're talking of the inside->outside). For the
outside->inside, it's indeed the opposite - very early in the packet
processing, so before the inspect.

>We've got one unit in the same building  as the firewall... hopefully I can >duplicated the problem on that.

ok. this indeed could be useful too.

>
> When I first started getting involved with the video conferencing units here, we >weren't able to dial out until I turned the NAT transversal setting on. Then I

hmm I thought it was indeed the outbound calls that had difficulties
now ? Or those are two different failures of a different degree ?

Anyway, normally inspect should take care of the translating the
embedded addresses.

>found out about inspect/fixup and never understood why that setting on the unit >would be needed if those commands were on the firewall config. Maybe we >should try it without the inspect? No other h.323 traffic normally goes in or out >of our network.

Yes - it's either/or, so if you don't have any other H.323 traffic,
then indeed give nat traversal a shot without the h323 inspects
enabled on the PIX.

cheers,
andrew

>
> 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
>
>