topic Re: RTP and RTCP traffic jumping rule in General Topics

RTP and RTCP traffic jumping rule

soporteseguridad — Tue, 16 Jan 2018 10:53:30 GMT

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?

Re: RTP and RTCP traffic jumping rule

BPry — Tue, 16 Jan 2018 17:13:40 GMT

@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?

Re: RTP and RTCP traffic jumping rule

soporteseguridad — Wed, 17 Jan 2018 08:17:03 GMT

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.

Re: RTP and RTCP traffic jumping rule

soporteseguridad — Wed, 17 Jan 2018 08:43:44 GMT

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

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

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

Re: RTP and RTCP traffic jumping rule

mlinsemier — Wed, 17 Jan 2018 17:55:56 GMT

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