HDX 9002 unable to handle external and internal calls at the same time

[Anonymous]

Hello,

Here is the background to my situation:

I have 4 devices on different subnets.  A Cisco/Tandberg, an HDX 9002 and 2 VSX-7000's.  I am able to configure the Cisco with Auto NAT, but still manually assign a public IP which allows the device to talk externally as well internally to these Polycom systems provided the polycom systems have NAT turned off.

On the HDX9002, I can talk to external devices provided NAT is set to manual and the firewall is H.323 compatible setting is unchecked.  However, in this configuration, the HDX9002 is unable to communicate with other internal devices on different subnets.  If I turn NAT off or check firewall is H.323 compatible, I'm able to talk to internal devices on different subnets, but I am no longer able to communicate with public devices.

Is there some other setting I'm missing?  If I set the NAT to auto on the HDX9002 is takes the wrong NAT address and is unable to talk to external devices.

Any help is greatly appreciated!

[Anonymous]

Two solutions on the Polycom side.  Put the HDX9000/VSX7000 in a DMZ or insert a Polycom VBP-E with Gatekeeper turned on.

http://www.polycom.co.uk/products/telepresence_video/security_remote_access/vbp_e_series.html

A Firewall/GK solution wil;l allow all your LAN based VC to communicate internally AND externally through a secure FULLY H.323 aware Firewall on a single Public IP.

Pete

Here's how the HDX/VSX Firewall settings have been explained in previous posts.

If the NAT is 323 compatible is checked, the unit is putting the ‘real’ (internal) IP address at both layer 3 and layer 7 of the packet.

If it is unchecked, the unit puts the ‘real’ IP address in L3 and the WAN IP in L7 of the packet.

NAT is compatible is extremely close, in real-world function, to having no NAT settings at all. When it is checked, the unit is depending on the firewall to intercept the packets & do the L3 NAT (change internal IP to external IP/vice-versa), as well as open the payload of the packet, determine if there is anything ‘to do’ (such as determine if it is an H245 packet and alter the IP address/port numbers contained therein) & do whatever is necessary.

When not checked, the codec has the simple thought process of: “the firewall here is dumb, so I have to put the WAN IP in the payload part so this call will work”

The layer 3 part of the packet, regardless of the NAT settings, is the same as it would not work otherwise.