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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

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

L0 Member

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.

15 REPLIES 15

L6 Presenter

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.

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.

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

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

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.

L0 Member

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.

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,

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

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,

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.

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

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.

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.

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

  • 7878 Views
  • 15 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!