I am currently attempting to cut over our office's internal gateway from a BSD firewall to our PA-2050 (running PAN-OS 4.1.9). When attempting the cutover, I can get all services to work properly with the exception of our two VoIP servers (running Trixbox, which is Asterisk-based). I can get the servers to make a call, but once connected there is no audio on either end. Both servers are using a 1:1 NAT through the firewall and I am only allowing SIP and RTP ports to be allowed from the internet. The only changes that were made were to the PA-2050's Ethernet interfaces to replace the existing gateway for the VoIP servers.
I had previously worked with Palo Alto Support to work through this. They had me set up an Application Override across all ports for both servers, which worked while testing. Unfortunately, every attempt at going live results in a lack of audio when calls are connected. Viewing the traffic log, it appears as if the RTP traffic is flowing normally. I really need to get this cutover completed, but am unable to do so until I can get the audio working. Has anyone else run into a similar issue? If so, how were you able to get audio working properly.
Solved! Go to Solution.
This is more of a troubleshooting scenario and may have to check different parameters as we narrow down the issue. Some points I think are:
> Is the app asterisk-iax allowed, based on the type of application may be some traffic is not being passed.
> Some times voip related apps may have variations on behavior with change in App content version as decoders would be getting updated, so if it was working at certain content version and not in another that may be the reason.
> If the voip servers are internal, did you check by disabling nat rules to see if natting has issue. Also it is good test mechanism to test with 1:1 nat but looks like this was tested already.
> Did you try and see the global counters at the time of passing traffic, this would give us an idea on the drops done by pan.
We will have to set up filters for specific source and destination and run the global counters command while traffic passing.
"show counter global filter packet-filter yes delta yes "
Run this back to back multiple times which would give some idea.
But I would suggest if a case is not opened yet pls open to isolate the issue.
FYI I just recently had to build App overrides for RTP and RTCP to get our host voice solution working in a remote office that is using a PA200. Leave the SIP App-ID alone! I noticed that doing an app override for SIP broke audio too. I have app overrides for just RTP and RTCP and it's working great.
I just set up our test PBX using this setup and am able to make calls and hear audio. I'm not completely convinced that this will work though, because I had audio working on it before using Application Override across all ports. Right now, I'm only using it for RTP and RTCP over UDP ports 9999 - 20001.
If you configure filters for the VOIP traffic and check the global counters, do you see any drop counters for Packets matching rtp/rtcp predicts of sip? To check for counters use this command with filters turned on: show counter global filter packet-filter yes delta yes
I ran across a known issue on PANOS 4.1.5, where asterisk based VOIP packets matching rtp/rtcp predicts of sip are dropped due to waiting for predicts merging, causing audi issues. This was addressed in PANOS 5.0 release. Do you have any plans to upgrade?
Right I had to do the same thing essentially... I built my override for UDP from ports 1024-65535. Luckily there is a specific pair of Class Cs that provide our hosted VoIP, which I used in the 'Destination' column in my PA-200 so that I didn't just flat out override ALL UDP 1024-65535 traffic. I dunno if that matches up with your case here.
We have our own VoIP servers in the office, so I attached the APP Override to those source addresses. The servers limit RTP traffic to ports 10000-20000, which is why I only set those ports on the override.
Well, I just attempted another cutover this morning and the audio was still not there. I don't understand how this will work on a test PBX (which is cloned from one of the two existing PBX in the office) but not work when I attempt to go live. All I've done was disconnect the BSD firewall, replace the interface IPs in the Palo Alto firewall, and then clear the ARP tables in our edge router and in the PA-2050.
I had opened a ticket with Palo Alto Support on Wednesday and after working with them for several hours, I still do not have an answer as to what could be causing this, much less what a permanent solution would look like. I've been attempting this since last Saturday and really need to have this resolved ASAP.
apasupulati We had let the licenses expire on our PA-2050 when we purchased a new PA-3020, so upgrading the OS isn't an option at the moment.
I'd say there's got to be some crucial difference between what you're testing in your lab versus what you've got in production... are you using a lab PA2050 but then when you try to go live you're using a PA3020?
Can you pull pcaps of a working lab session and a non-working production session, and maybe "diff" the two pcaps against each other?
The PA-2050 is being used for testing while the two production VoIP servers are using the BSD firewall as their gateway. I pull the Ethernet cables from that firewall while the PA-2050 is committing changes (changing the addresses of interfaces to the addresses that were being used by the BSD firewall). I know that the NAT rules are working, because the calls are going out to our SIP provider and connecting to my cell phone. Each time I back out of the cutover, replacing the interfaces with their previous addresses, I then lose audio on my test VoIP server. No changes have been made on any PBX.
I do have some PCAPs for failed calls, but have not yet been able to do so for successful calls.
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 Live Community as a whole!
The Live Community thanks you for your participation!