On Wed, Jul 15, 2009 at 8:58 PM, Steven Pfister<spfis...@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 spfis...@dps.k12.oh.us > > >>>> Andrew Yourtchenko <ayour...@gmail.com> 7/15/2009 2:07 PM >>> > Hi Steven, > > On Wed, Jul 15, 2009 at 6:28 PM, Steven Pfister<spfis...@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 > > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
