I have our VoIP PBX set up with an IP on our external side via NAT. The policy is a simple static NAT from the internal IP to the external. I also have the correct security policies in place to allow SIP/RTP traffic to pass freely to and from the external IP address. The PBX server can be accessed via HTTP from outside our network, and my cell phone (using BRIA) can successfully register to the PBX.
However, whenever I make a call from outside, it will disconnect after seven (7) seconds when picked up. This happens every time without fail. I have tried tweaking around security policies, enabling application override, and altering the NAT rules.. nothing seems to help.
Can anyone give me suggestions? This setup worked perfectly fine on our old Juniper SRX-240B with the PA-500 in vWire. Ever since I swapped the PA-500 into being our gateway/firewall, it just won't do it.
More information can be provided upon request.
What software version and content is running on the device?
We are continuing to make improvements to the SIP decoder so I would recommend updating to the latest app/content version to see if this resolves your issue.
VoIP issues can be tricky to troubleshoot so I would highly recommend opening a case with your support team so we can gather packet captures, global counter and session information.
An update to this ticket:
I've been working with Palo Alto support and still no fix, yet.
Packet captures show that RTP traffic is flowing from the internal phone to the SIP phone outside the network, but there is no flow from outside to inside. It is passing out of our dynamic-ip-and-port NAT rule, but cannot find a way back in.
Still waiting on support for additional testing.
Try sniffing manually on your uplink to see if the voip client returns any packets at all?
My guess would be that some header within your SIP connection isnt replaced to show the PA's outside ip/port but showing the original (RFC1918?) address. Which of course will never find its way back to your PA (specially if this is over Internet).
Packet capture on a laptop running a SIP client shows that packets are being received on the external unit, but packets are hitting the NAT and being dropped when trying to re-enter the network.
PBX has a static NAT to an external IP.
External unit registers via PBX external.
External unit makes call.
PBX connects to internal phone and sets up the call.
Internal phone takes the call and tries to communicate with external unit via default dynamic-port-and-ip NAT (different IP than PBX external).
Traffic flows from internal to external via default NAT, but not vice versa.
The issue is that the traffic cannot re-enter the network via the dynamic-port-and-ip NAT. Our old Juniper SRX-240B did not have this issue, as it would route all SIP traffic back out the PBX external IP in it's default behavior (from what I've been told). This would utilize the static NAT and not the dynamic NAT.
Still working with someone from Palo Alto..
Never really got any tangible progression. Ultimately, we decided to stop pursuing the issue and wait for our new phone system upgrade after the first of the year. The 3COM system we're using isn't supported any longer and has issues with NAT traversal.
One thing we also did was purchase an InGate Siperator so that our future SIP provider traffic will not pass through the PA-500 and instead will be parallel to the firewall. Managed to find a hardly-used unit on Ebay for way less than retail price.
I had the same problem and finally pointed the outside interface of the VOIP PBX to the internet bypassing the PAN. It has a built in firewall that's satisfactory for it's purpose. I created a zone on the PAN to get to he voice subnet for secure management of the VOIP PBX and also to keep the voice subnet off my internel network. It works for now.
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!