I suspect this question will show up my complete inexperience with the Polycom infrastructure, but here goes anyway!
I'm providing some more background below, but the simple question is:
"Should a VBP 5300 provide H.323 ALG/NAT traversal for calls originating on the WAN side, where the endpoints are behind a NAT?"
We have a relatively small Polycom installation, comprising
- 4 HDX units
- an RMX 2000
- a VBP 5300.
The VBP is running in embedded gatekeeper mode and successfully allows us to communicate with external endpoints. We also believe the VBP is allowing some external endpoints to connect through it, to our RMX. By some, I mean that external systems such as Polycom's own support sites are able to connect; similarly, devices behind an H.323 aware NAT are able to connect (for example, I was able to connect to the RMX via the VBP with the new Polycom iPad2 app from my home network).
However, the VBP doesn't seem to cope with endpoints on the WAN that are behind a non-H.323 aware NAT. For example, we have a dedicated visitor wireless network in our office that provides no access to our internal network, but gives visitors a NATed Internet connection. Using the iPad2 app connected to this network, although I could connect a call to the RMX via the VBP's WAN address, no media flowed back to the iPad2 - the VBP was sending media to the private address of the iPad2 on the wireless network rather than spotting it was behind a NAT and sending to the public address.
Is this the expected behaviour, or should the VBP be able to provide ALG function to incoming external calls as well as providing ALG function on internal calls going to the WAN? If this should work, anyone got any ideas why it isn't working for me?
Solved! Go to Solution.
Unfortunately, there isn't much you can do about the problem you are describing with the VBP.
Basically, the problem comes down to this:
A normal NAT will NAT the transport layer only, but it will not go into any of the other layers in the packet to change the addresses in there. The VBP is an application layer gateway, which means that in addition to NATing the transport address, it also goes into layer 7 of the packets and NATs the application layer address. So, your device at 192.168.1.132 will get NATed through the VBP so that its transport and application layer addresses are the WAN address of the VBP.
However, your external devices going through a normal NAT, will only have their layer 3 address NATed. So they will send the Open Logical Channels messages (the messages that negotiate the media) with a return address of 192.168.1.50 (for example) in the application layer. So the VBP is not able to get the media back to them, as the device doing the NAT on their end is leaving their private address intact in the application layer of the packet.
Any device calling in with a properly configured NAT or behind an H323 aware firewall should be fine, but other devices will not give the VBP the correct return address for the media and the calls will fail.
Hope this helps with understanding the problem.