How do you allow Polycom (nat) via Palo Alto FW?

[akatev]

Hi,

I'm having issue with configuring NATing for my Polycom unit sitting behind the firewall to work.  I have allowed all the required apps for Polycom to allow outgoing and incoming.  My issue is when I can only call out to another party with public IP but can't receive call from outside the network.  I have both NAT rule for both ways in place.  Any one have experience with similar setup?

Thanks,

Tevin.

[rmonvon]

Hi,

Are you running PAN-OS version 3.1.0 as 3.1.0 has enhancements for ALG in a NAT'ed environment?  Please check out the release notes for version 3.1.0 and give 3.1.0 a try.

[john.langford@aplp.net]

I also had a problem with a Tandberg NAT. I  am running 3.1. The trick was to change the outbound NAT for the Tandberg  from dynamic ip and port to dynamic ip. I also had to allow the following  applications both inbound and outbound - h.245, h.323, rtcp and rtp.

[rmonvon]

So setting the NAT type to dynamic IP solved your problem for both Polycom & Tanberg? 

[john.langford@aplp.net]

We only have Tandberg but they are all standards based an interopable, so the Polycom "should" act the same

[akatev]

I won't have a down time window until the end of this month to upgrade to 3.1.  So will have to let you the status later.

[akatev]

So our PA is on version 3.1.3-h1 now and still having issue with NATing for Polycom.  We were close on being able to get our PA to make and receive call to the external network.  However, when calling internally, our NATed Polycom called the internal system with its public IP instead eventhough it was an internal IP call.

[LCMember1210]

Hello,

I have the same issue.

Our PAN runs PANOS 3.1.5 and protects a Tandberg MCU4250.

MCU has a private address (192.168.x.y) and I can ping it from Internet through the PAN with its public address (195.101.x.y).

But when I try to establish a videoconference, it fail.

During the process, the first TCP session connects correctly, client and MCU discuss and negotiate dynamic parameters. PAN correctly detects the h323 application.

But in the second (dynamic) TCP connection, I notice that the client try to establish a connection to the private address. The PAN does not modify the h323 payload.

The filter rule accepts following applications (from untrust to trust) from any to 195.101.x.y : h.245 h.323 rtcp rtp icmp rsvp

The NAT rule  simply "nats" statically (from untrust to trust) any->195.101.x.y to any->192.168.x.y.

Did I miss a parameter or a trick ?

Thanks,

[odaos]

Try creating your NAT rule by making your source and destination zone from "untrust" to "untrust".

Then create an security policy from untrust to trust, any any any -any application-, any, Action Deny policy.  This will log all your denied traffic and possibly from there we can indentify what application you may be missing, and add that to your rule.

Regards,

Oliver

[LCMember1210]

Hello,

It didn't work...

I also tried to change the NAT rule to :

Original packet :

any to trust, 192.168.* to any,

Translated packet :

195.101.* (static-ip, bidirectional) to none

The payload of the h323 packet wasn't change...

For the second dynamic connection, the client on the Internet, tries to connect to the private address.

For NATing H323 flow, is there a "priority" in the NAT rules ?

Regards,

[owenusa]

Did anyone figure out the resolution to this. We are having the same issue connecting our external VSX to a nat'ed RMX 2000 bridge. Subsquent packets from the VSX try to connect to the private address and not the nat'ed address.

[kbrazil]

Is the Polycom using H.323 protocol?  If so, we should support static NAT today.  You might want to work with Support to see if there is a configuration or content issue.

H.323 is not supported with Port Address Translation (PAT) today, but will be in a future release.

Cheers,

Kelly

[akatev]

Does anyone have luck with setting this up yet?  I'm struggling to have this to work after our deloyment with PA firewall.  It was working fine before with the SSG.  I have to literally uncheck the box for 'NAT is H.323 compatible' on my Polycom to be able to receive call from the public IP.  When i do that, incoming call from the public works but all the internal call is broken.  So i have to flip this option back and forth.  It's a real pain.

[rmonvon]

Have you checked with Polycom to see why internal calls didn't work with the NAT option unchecked?  For internal calls, there is no NAT'ing so the option should not have affected internal calls.

[kbrazil]

Also, the latest PAN-OS version (4.1) has NAT enhancements for H.323 traffic (specifically Polycom).  You might test that code in your lab.

Cheers,

Kelly