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


L4 Transporter
Hi community,

I have seen lot of Palo Alto documents and some blogs saying about ALG functionality issue in firewall.
I am facing some issues randomly with ALG functionality in firewall, I have seen documents says to disable ALG in PA, but my sip server/client is not aware of NAT, and I don't have any STUN servers.

Does any body faced this kind of problems in Palo Alto and how they fixed it, does it have a solution without application override and disabling ALG ?.
I have proper security and NAT policy in place and the setup was working for a while

Cyber Elite
Cyber Elite

Hi @Abdul_Razaq 


could you elaborate on what kind of issues you're experiencing?

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Cyber Elite
Cyber Elite


In the past I have had to disable all inspections on a SIP trunk plugged directly into the PAN since it was disrupting the traffic. 


Not a solution but hopefully it helps.

L4 Transporter

Hi Community


Not sure whether it is a bug or behaviuor of SIP(ALG enabled) or there is too much sessions between sip servers,

I fond out that my NAT buffer usage for that particular rule was so high. eventhough i didnt have any active sip/rtp sessions, my NAT buffer was used much. feels like it caused some packet didnt get NATed. Post clearing stale NAT buffers, cleared all sip connection and after long time (may be the sip timeout in sip servers is high), things started working


Anybody faced these kind of behaviour ?. reed to verify the root cause as the issue may return soon.

@reaper @OtakarKlier  your inputs are much appretiated.

Had a call loged with PA support for months on this...


We replaced an old Fortigate with a 3020, after porting across the SIP trunk it worked for 30 days and then refused to process any RTP sessions. Clearing the SIP session in "Session Browser" restored Calls... It worked for 30 days, Broke, 40 Days Broke, Etc, etc..  [ Firmware upgrade, swapped ISP's ] still continued.


We gave up on the Palo and put the traffic on a dedicated £100 Draytek, been solid..


Hey @RobinClayton @Abdul_Razaq 

We've had the same issue before; after logging it with TAC it seems that long-lived SIP sessions will die after going through six content updates. We worked with TAC for a long time and the fix is in PAN-OS 8.0.13 (PAN-97253). So give that a shot.


FYI current preferred 8.0.x release is 8.0.16




L3 Networker

We are also experiencing issues with SIP too and definitely seems to be related to RTP traffic


we are seeing some unknown-udp which via packet captures is RTP traffic, we are seeing PRED failures.


We upgraded from v8.0.13 to v8.1.6 and thats when it broke. I heard theres a hotfix for 8.1.7 thats supposed to fix things, but not rushing to install that at this time.


My video conferencing units support a NAT config, so been setting that up and turning off SIP ALG, along with app override which seems to have resolved our issues.


Our packet captures show SIP ALG translating, but dont think its doing all of them properly or not seeing PRED session types properly all the time (as opposed to FLOW),which is ALG.


I think there is also possibility of some app content updates that will fix some issues too, to identify and process RTP traffic better?

L0 Member

We have SIP with ALG enabled, works great to start with. Then after 30 to 60 days, depending on call volume, the ALG stops "layer 7 NAT". The packets are received correctly un NATed on the SBC but the SIP payload contains the outside NAT IP address.....wwwwwhhhhhhhhyyyyyy?!?!?!

  • 7 replies
  • 101 Subscriptions
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!