Voice server reply out of the session

[SdanteMate]

Hi mates, 

We recently integrated our CRM with a voice system (Coperato). 

Out of the office (home network), we can do calls from CRM without issues.

Within the office, we have checkpoint cluster load sharing r81.10, and I track in the logs that voice server, is replying back to the client using new session on high ports instead the session where client's PC generate. 

If I expose the client (set static IP on the object) and allow inbound traffic to the public IP, the phone call is working, but obviously I can't do that for all users.

Any ideas regarding checkpoint settings that may solve the issue?

Thank you.

[the_rock]

Do you have example screenshot of the log generated?

Andy

[SdanteMate]

Hello Andy,

Home scenario

Client PC generate traffic to --> CRM 443 --> from CRM initiate a call, from client PC (8089, high ports) --> voice server --> client PC.

Office scenario

Client PC generate traffic to --> CRM 443 --> from CRM initiate a call, from client PC (8089, high ports) --> voice server --> end of session.

New Session, voice server (high ports) --> client PC.

Does this make sense? 

Also I get logs with the error: (from client to voice server)

Firewall  -  Protocol violation detected with protocol:(RTP), matched protocol sig_id:(1), violation sig_id:(9). (500)
Connection terminated before the Security Gateway was able to make a decision: Insufficient data passed.
To learn more see sk113479.

"Connection terminated before detection" in log reason for Unified Rulebase (checkpoint.com)

and packets drops from CRM to client PC:
TCP packet out of state:  First packet isn't SYN

TCP Flags:  FIN-PUSH-ACK

[the_rock]

Let me try draw simple diagram later to better understand this.

Andy

[the_rock]

Does it make sense what I drew? If so, are high ports allowed in the rule for this traffic to work?

Andy

 

[SdanteMate]

Hi Andy,

 Yes it fails because voice server reply back with random high ports to a public IP with many clients hiding behind. 

If I allow the high ports on my public IP range and set in smartconsole, object with static IP, it starts working but if I set more than 4-5 objects with the same static IP then FW is forworking the traffic to random clients having that IP. 

[the_rock]

Normally, that message you mentioned, it means CP fw is not an issue, but rather indicated it does not have enough data to pass the connection, so 3 way handshake is failing somewhere along the way.

[SdanteMate]

I thought the same thing, but ideas why from home is working fine? 

[the_rock]

One way to confirm would be to do fw monotir when it works and when it does not and then compare from wireshark.

If you can get that, send it to me (with IP addresses involved) and I am happy to check.

Andy

[SdanteMate]

Thank you rock! I'll gather Wireshark logs from the home machine and fw monitor from the office, and send it privately. 

[the_rock]

Sounds good to me!

[SdanteMate]

Hi @the_rock , I'll send you the logs soon, I want to share with you also something that I noticed a while ago. 

I have cluster load sharing (3 members),

From the remote IPsec VPN connection is working fine, and I notice that the traffic is handled by member 2 outgoing/incoming.

Internally, the traffic is handled by member 2 outgoing and member 1 incoming.

[the_rock]

Please do and also, do not forget to indicate IP addresses involved.

Andy

[the_rock]

Hey mate,

I got your captures via email, tx a lot. here is one thing Im confused about. I did not want to put the whole screenshot for privacy reasons, BUT, Im totally not clear on one thing...where I marked it as NW (non working), I do NOT see a single attempt to public IP of the voice server 3.x.x.x...any idea why?

Andy

 

[SdanteMate]

Hi Andy,

As you can see, in the non-working attempt, I share two pcap files with you, these files are for the same attempt from 2 members of the cluster. 2 members handle the same session or the voice server is replying from new session.

[the_rock]

Yes, apologies, missed that one. Will check bit later.

Andy

[the_rock]

Just checked it and top one is non-working one. The ONLY difference I see is that src port is different, but that never matters, only dst port is important.

Andy

 

[the_rock]

Can you also send us the screenshot of the log when this FAILS? Please blur out any sensitive data, or if you feel more comnfortable, just email it to me and I will have a look. Or even better, lets do remote if you are allowed to.

Andy

[SdanteMate]

Hi Andy,

Please find the screenshots below.

   

[the_rock]

Appears its not matching the right rule somewhere or protocol itself cant be matched, or both. Honestly man, I would open TAC case to check this further.

Andy