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.
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.
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..
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
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?
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?!?!?!
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!