Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > PIX troubles H.323 even with fixup disabled

Reply
Thread Tools

PIX troubles H.323 even with fixup disabled

 
 
Tilman Schmidt
Guest
Posts: n/a
 
      08-15-2007
We have some problems with H.323 videoconferencing in a private
network segmented by various PIXen running OS version 6.3.
Clients are Polycom PVX running on Windoze PCs, and the problem we
are seeing is that clients in one of the segments cannot connect to
those in any other segment. More precisely, the call is signalled but
when the called party clicks on "accept" the call is not connected
and the caller gets a "refused" message. This seems to be the normal
behaviour if the connection traverses a PIX which still has the
default "fixup protocol h323" settings in place, but we have double
checked that all the PIXen in this network have
no fixup protocol h323 h225 1720
no fixup protocol h323 ras 1718-1719
in their configuration, and with that, video connections work fine
now, except for that one segment.

Any ideas how to troubleshoot this? (Without the trouble shooting
back, if possible.

aTdHvAaNnKcSe
Tilman

--
Please excuse my bad English/German/French/Greek/Cantonese/Klingon/...
 
Reply With Quote
 
 
 
 
hanna.weiss@gmail.com
Guest
Posts: n/a
 
      08-17-2007
On Aug 15, 9:12 am, Tilman Schmidt <(E-Mail Removed)> wrote:
> We have some problems with H.323 videoconferencing in a private
> network segmented by various PIXen running OS version 6.3.
> Clients are Polycom PVX running on Windoze PCs, and the problem we
> are seeing is that clients in one of the segments cannot connect to
> those in any other segment. More precisely, the call is signalled but
> when the called party clicks on "accept" the call is not connected
> and the caller gets a "refused" message. This seems to be the normal
> behaviour if the connection traverses a PIX which still has the
> default "fixup protocol h323" settings in place, but we have double
> checked that all the PIXen in this network have
> no fixup protocol h323 h225 1720
> no fixup protocol h323 ras 1718-1719
> in their configuration, and with that, video connections work fine
> now, except for that one segment.
>
> Any ideas how to troubleshoot this? (Without the trouble shooting
> back, if possible.
>
> aTdHvAaNnKcSe
> Tilman
>
> --
> Please excuse my bad English/German/French/Greek/Cantonese/Klingon/...


I hope this will help, but it seems as though messages from this one
particular segment are being blocked somewhere along the line or, the
messages are getting modified somehow. run ethereal on the Polycom
PVX system where videoconfencing works fine on and then run ethereal
on a system from the network that is experiencing problems and compare
the packets.

-Chana Atar

 
Reply With Quote
 
 
 
 
Arthur Brain
Guest
Posts: n/a
 
      08-17-2007

Are you sure it's not just the destination ports that need to be
opened?

As it happens, I have today been playing with Polycom VC stations
across a WAN link, and it is clear that the documented ports are
WRONG.

This is where I was at with my access lists (before I decided to use
other means to filter this traffic):

permit tcp any any eq 1720
permit tcp any any range 3230 3237
permit udp any any range 3230 3237
permit udp any any range 2438 2445
permit udp any any eq 1719
permit tcp any any range 5555 5574
permit udp any any range 2326 2405
permit udp any any range 2478 2480

This range seemed to work fine initially,
permit udp any any range 3230 3237

But then I connected in some Tandberg VC stations, and the Polycoms
started using more and more ports, different for each new call.
The doco the software came with was useless.

 
Reply With Quote
 
Tilman Schmidt
Guest
Posts: n/a
 
      08-20-2007
Arthur Brain schrieb:
> Are you sure it's not just the destination ports that need to be
> opened?


Reasonably sure, because:
- The PIX is configured not to block anything between these two
networks.
- The behaviour is completely different from what I observe when
ports are blocked. (Blocked ports tend to result in timeouts,
ie. a long wait before the connection fails. Here the connection
errors out the very moment the called party clicks "accept".)
- The behaviour is very similar to what I observed in the past
if the h323 fixups were active in a PIX the connection had to
pass.

> As it happens, I have today been playing with Polycom VC stations
> across a WAN link, and it is clear that the documented ports are
> WRONG.


Yeah. That's why I usually determine the ports I have to open from
the PIX logs, not from the app docs.

--
Please excuse my bad English/German/French/Greek/Cantonese/Klingon/...
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Pix 506 - Fixup SMTP Christophe Pin Cisco 5 08-26-2008 03:12 PM
outbound VPN access through PIX with fixup pptp darkcape@yahoo.com Cisco 2 03-03-2007 04:05 AM
DNS Fixup/Inspect Pix/ASA 7.0 or greater breaking email Brian V Cisco 4 10-09-2006 07:19 AM
PIX MailGuard "fixup protocol smtp" and Exchange Server? David K Cisco 2 01-09-2004 02:26 PM
PIX 6.3(3) Fixup protocol dns and tftp... Masud Reza Cisco 1 01-03-2004 11:18 PM



Advertisments