10-24-2011 02:05 PM
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?
10-25-2011 11:39 AM
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
01-23-2012 02:43 AM
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!
01-23-2012 12:58 PM
what version of PAN-OS and what version of content are you running?
01-23-2012 01:05 PM
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.
SRC PORT: 5060
DST PORT: 3478
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.
Com1 Communication Solutions BV
Message was edited by: branders (added content version)
01-23-2012 08:20 PM
Please open up a support case by logging into support.paloaltonetworks.com or calling in at +1-866-898-9087
02-28-2012 05:11 AM
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...
05-14-2012 11:44 PM
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
06-05-2012 08:11 AM
I'd also really like to know how you got past this. Facing an identical issue and I'm at a loss.
06-05-2012 10:01 AM
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
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)
06-05-2012 01:15 PM
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.
06-10-2012 12:49 PM
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.
07-31-2012 02:01 AM
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?
07-31-2012 04:42 AM
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/LAN/17 (188.8.131.52)
vsys1 184.108.40.206/INTERNET (220.127.116.11)
But, after that, another connection using the same source port, it doesn't work:
127233 rtcp ACTIVE FLOW 10.42.56.253/LAN/17 (10.42.56.253)
vsys1 18.104.22.168/INTERNET (22.214.171.124)
Most of the situations: it fails with ports 3000 and 3001.
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!