Zendesk voice application 3 second delay

[dehaasm]

Not sure if this is a Check Point related issue but the issue only appears when connected behind a Check Point firewall, when connected to direct internet the issue does not occur.

The issue is that whenever the Zendesk servicedesk application makes a Voice call (via Cloud STUN server) after answering a call there is a 3 second delay before the voice is heared, after 3 seconds the call works fine. While performing the same test without a firewal in between this issue does not occur.

We made packet captures and also tried to disable coreXL (fwaccell off) but it didnt resolve the issue.

In the packet capture the only thing i see is that there is a DTLS handhakes with a 3 second delay, meaning that it takes 3 seconds for the external server to reply. This does not show any delay on the Check Point firewall but perhaps i am overlooking something as we cannot find the root cause.

Dit someone already experience such issue?

[the_rock]

Do you have simple network diagram?

Andy

[bacim]

Traffic is initiated by the client (user)

FW is a cluster of 2 (no difference noticed in which node is active)

[the_rock]

Will respond in a bit with some ideas/suggeestions.

Andy

[the_rock]

K, so here is how I would approach troubleshooting this. So, lets start with whats logical, or what we know...so, we know 100% that if all this works without CP fw in the "pitcure", there is something on the fw side causing the problem. What can it be? Well, usually, for things like this, I would first look at the service(s) used.

In the old days of CP, what people would do is edit the service, select protocol as 'NONE, which in simple terms, would essentially bypass IPS inspectrion, if you will.

Thats one thing to try and install policy, test. If that fails, I would generate fw monitor as per below.

Lets pretend user's IP is 1.1.1.1, zendesk is 2.2.2.2 and port is 4434

idea is srcip,srcport,dstip,dstport, protocol

so it would be like this (just use right IPs and ports, of course, though for the context, ONLY dst port matters)

fw monitor -F "1.1.1.1,4434,2.2.2.2,443,0" -F 2.2.2.2,443,1.1.1.1,443,0"

0 is for any protocol

Once you have that, send, so we can analyze.

Best,

Andy