RTP and RTCP traffic jumping rule

Reply
Highlighted
L4 Transporter

RTP and RTCP traffic jumping rule

Hi,

 

We have created a rule for Voice IP.

 

Zone A to Zone B / Application RTP - RTCP / Service ANY / PERMIT

 

So all the voice RTP connections should matched in the previous rule, but we are seeing connections which should be matched the previous rule but its matching in this rule:

 

Zone A to Zone B / ANY / ANY / PERMIT

 

Its like some connections are jumping the first rule, but we can see in log traffic how the sessions are being identified like RTP and RTCP.

 

Any idea?

Highlighted
L7 Applicator

Re: RTP and RTCP traffic jumping rule

@soporteseguridad,

Once it's been properly identified by your catch-all rule, do you see subsequent sesions between source/destination on the same port properly matching the first rule? 

Highlighted
L4 Transporter

Re: RTP and RTCP traffic jumping rule

No, Its not about 3way handshake. I thought it when this case was opened. 

I was thinking that maybe some voice (RTCP) connections are differents and for that its jumping the first rule. But i can not see anythign different between them.

I will try to take pcaps to see the behaviour. 

 

Highlighted
L4 Transporter

Re: RTP and RTCP traffic jumping rule

This is the rule to match voice sessions. Numbers 32 and 33.

 

1.jpg

 

And these two rules are below, and sometimes the RTCP  and RTP sessions are matching here. Source and destinations arent problem.

 

2.jpg

 

Here we can session browser. the 3 sessions should match in the third rule. 

 

3.jpg

Highlighted
L3 Networker

Re: RTP and RTCP traffic jumping rule

Recently when  locking down my voice networks I ran into an issue similarly where RTP was matching the incorrect rule.  Come to find out that it was matching the parent session, which in my case was SCCP, that is opening up pinholes and predicting RTP traffic and was causing it to match against a different rule than expected (my signalling rule). 

 

To resolve the issue, I disabled ALG for the SCCP protocol.  I opened a case with Palo Alto who came back and had stated that this was working as expected.  I dug a little deeper reading and found out that SCCP (and others) performed ALG by default.  I had to disable ALG for SIP as well to get Cisco Telepresence to work correctly.

 

-Matt

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 Live Community as a whole!

The Live Community thanks you for your participation!