SIP/RTP + NAT - One way audio

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

SIP/RTP + NAT - One way audio

L2 Linker

Hi all,

We are facing difficulties with a plain-in-to out and out-to-in NAT which is configured as described below:

- Private to public

- Public to private for ports 5060 an 9000-9049 UDP with the PBX address as destination.

For some reason SIP signaling works fine, but the incoming RTP stream doesn't come through.

The firewall was tested even with allow any-any on both destinations but even then there is no solution.

Is this a known issue, or are we facing a serious operator error?

Best regards,

Bas Sanders

13 REPLIES 13

L0 Member

I'm having a similar problem.  I assume you are working on a 3CX system judging from the ports.  What's interesting is that with CallCentric, things work fine but with Nexvortex, it doesn't and I end up with a disconnected call.  Hopefully someone will shed some insight into this

Hi,

Sorry for the late response. We are indeed using a 3CX PBX solution for our own purposes, as wel as for our customers.

Up until now we were able to use another public IP which we configured directly on the PBX so without the PA2050 in the path to the internet. This works fine of course, but now we have to build a similar configuration for a customer as PoC.

Again we are testing and configuring, but without any result. Still we face one way audio.

I tried to configure application override for SIP, but i could not find a config guide yet, so i can't check if i configured it the right way. Either way, it doesn't work.

Would be a lot easier if Palo Alto would just make an option to enable or disable SIP ALG somewhere...!!

Any suggestion is welcome!

Best regards,

Bas Sanders

@Bas:

what version of PAN-OS and what version of content are you running?

-Benjamin

Hi,

We are running 4.1.2 (with content version 270.1140) but have seen similar results with all other releases we had (4.0.5 and up).

Currently we are examinating traces and noticed that the PA translates the source port in the STUN traffic coming from the PBX.

Original:

SRC PORT: 5060

DST PORT: 3478

Translated:

SRC PORT: 30412

DST PORT: 3478

Why does the PA translate the source port? Possibly because port 5060 is below 10.000 and thus is registered for destination ports?

From this point we stronly believe that this is where the PBX looses it. As we are now facing this configuration also on customer sites we are eager to solve this matter.

Best regards,

Bas Sanders

Com1 Communication Solutions BV

Netherlands

Message was edited by: branders (added content version)

Please open up a support case by logging into support.paloaltonetworks.com or calling in at +1-866-898-9087

Problem solved with a workaround!

We used static source and destination translation which makes it work. NOT the way this should be done, but at least our PBX is happy now.

Has been running for several weeks without any issue...

Regards,

Bas

Not applicable

Hello,

Would you mind share your NAT/Policy rules to make 3CX work ?

I have same problem and it's driving me nuts - even with bi-directional NAT it's not working.

Thanks in advance

Br

Jørgen

I'd also really like to know how you got past this. Facing an identical issue and I'm at a loss.

At the moment - this *seems* to be working for us:
3CX v.10 w. SP6, default ports and STUN resolving. We're using the "PBX delivers audio" option.
PA-2020 w. software v. 4.1.6, Application version 310-1401, Threat version 310-1401, Antivirus version 760-1045

Incomming NAT rules:
Public ip on selected ports (port service) send to 3CX server

Outgoing NAT rules:
Internal IP to Public IP, Translated IP = Static IP, Bi-directional=no

Rules:
Allow STUN & RTP to outside from 3CX server
Allow selected ports from outside to 3cx server
Allow selected ports from 3cx server to outside
Allow SIP from phones to 3cx

(I'm not entirely sure if you need to allow rtp or selected ports from phones to 3cx server - at the moment it doesn't appear to be needed)

Br

Jørgen

Unfortunately, our old 3COM VCX doesn't have all those fancy options.. I'm anticipating our switch to NEC Spherical in the near future..
Until then, I'm stuck trying to fiddle with App Override and NAT rules. I've been working with Palo Alto for a few weeks now and we've still have no luck getting audio to enter the network from outside the firewall. Audio has no problem exiting, though.

Not applicable

Having been jumping on this for a while - I think that I finally have found out what the (/&%(/&¤&% goes on.

Fortunately one of our SIP trunk providers allows you to change the codec and ho and below I found that:

G711U - works

G711A - works

GSM-FM - works

G729 - DOES NOT WORK !!!!!

So. If your provider is using G729 - then this is likely why it doesn't work.

You need to have the provider to set G711U/A as prefered codec AND you need to set the G711U/A as prefered codec on the SIP trunk on the 3CX.

It seems (according to my test) - that if the provider is set to G729 it doesn't matter what you set - it just won't work.

Please let me know if you can confirm my latest finding.

Br

Jørgen

L2 Linker

Hi everybody.

We're having problems with NAT for RTP. In our configuration, we've created a static NAT rule(as described above) for our CallManager. That works fine.

The problem is with telephones. They must communicate with our provider (public IP's) so we created a NAT rule type Dynamic-IP-and-Port, so our telephony subnet shares a single public IP. SIP session is created and negotiated correctly. The problem comes with RTP traffic, and, the worst thing: only with some telephones (nothing in common between them). If we reload the firewalls, everything works fine, but, after a time, some telephones doesn't work: one-way audio (incoming audio doesn't work). It seems a problem with NAT, because, after a time, Firewalls stop doing NAT, using for the sessions the private IP address of the phones; then, obviously, provider isn't able to respond to a private IP address.

I've checked this with tcpdump captures and we cannot explain this behaviour of the firewalls. Maybe the NAT table is full?

Could you help me please?


L2 Linker

Hi again.

I've seen the failed NAT and when it happens:

This is a connection RTP from  a phone to our telephony provider, and it works:

67130 rtcp           ACTIVE FLOW  NS   10.42.38.250[3001]/LAN/17  (94.124.28.150[2940])

vsys1 212.230.32.192[23639]/INTERNET  (212.230.32.192[23639])


But, after that, another connection using the same source port, it doesn't work:

127233 rtcp           ACTIVE FLOW       10.42.56.253[3001]/LAN/17 (10.42.56.253[3001])

vsys1 212.230.32.192[21789]/INTERNET  (212.230.32.192[21789])


Most of the situations: it fails with ports 3000 and 3001.

Thank you.

  • 12639 Views
  • 13 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!