TelePresence through PaloAlto having problems

[RICHARD MESSINGER]

Have a customer that has a Telepresence configuration and is having some strange issues with Video through their PaloAlto Firewall.

Installed a VCS Control / Expressway Pair with the Expressway in a DMZ with dal interfaces configuration to the PaloAlto

They can make and receive calls to most places without any issues, but one location that they call SIP via an IP address is having problems where the call will be extablished but that 15 minutes into the call, the call is dropped.

Has anyone seen or heard of this type of behavior?  I am told that htey are running the latest code on the PaloAlto.

Thanks

[Jens Didriksen]

I doubt very much it is the PaloAlto if it only happens when calling a specific site, however, that needs to be proven. So, does it happen with all SIP calls or just this one as this sounds very much like a SIP timer issue?

I have come across similar issue with one specific site, and we are using PaloAlto firewall as well, but the PA was in my case, innocent. :)

/jens

Please rate replies and mark question(s) as "answered" if applicable.

[RICHARD MESSINGER]

This seems to be a SIP only issue.  if they make the call as h.323 they are not having the issue.

[Jens Didriksen]

Yes, but is it happening to all SIP calls to all sites, or, as was in my case, with SIP calls to one specific site?

/jens

Please rate replies and mark question(s) as "answered" if applicable.

[RICHARD MESSINGER]

they say all calls but since I do not have easy access to the vcs expressway it is hard to tell.

[Jens Didriksen · Accepted solution]

It's definitely a SIP timer issue. The default setting on the VCS-E SIP config (Configuration/Protocols/SIP) for "Minimum session refresh interval (seconds)" is 500, this particular timeout happens at 900 (15 minutes), would be interesting to know if the default setting has been changed from 500 to 900 - not that it matters much, just curious, as if it hasn't then the TTL is being overridden.

If this happens to every single SIP call to/from external sites, then this points very much to a local SIP timer issue, and yes, this would point to the PA.

The following might be of some help; "Palo Alto Firewall and Cisco SIP issues" - either way, they would need to do a log trace on these calls to confirm the timer issue, but it's pretty clear that the "keep alives" is not getting through.

Another good resource is the Palo Alto Community - they might be able to get some expert help there.

If this is happening with only one specific site, well, then the issue is with the external site, and the work-around would be to force H.323 by creating a separate neighbour zone for this particular address with SIP disabled - (would be even better if they fixed it of-course).

This means any SIP client can still call the address as per normal, but the VCS-E will interwork it to H.323. So for all intent and purpose, the SIP client thinks it's connecting using SIP, and, in fact, it is, but only for a very small part of the call-leg. :)

/jens

Please rate replies and mark question(s) as "answered" if applicable.

[d.leshock]

; "Palo Alto Firewall and Cisco SIP issues" - talks about 5060 what about 5061

[Randy Valverde Rojas]

Hello,

We get plenty of these at tac, 15 minutes is the default SIP refresh timer (by default the timeout on the VCS is set to 1800 seconds, 30 minutes, and it will try to refresh every 15).

When a call is established, signaling ports (5060/5061) will stop being used because media is passed through other ports negotiated on the initial conversation.

This is usually a problem for firewalls since they are normally configured to drop a session after a few minutes without traffic, if this time is less than 15 minutes, the session will be dropped and once you reach the 15 minute mark, if the refresh cannot be send (because the TCP session was dropped) the call will be disconnected.

Verify the firewalls timeout for sip ports (5060/5061) to be higher than 15 minutes.

Another thing I have noticed, is that Cisco ASAs will consider 1 or 2 packets enough to refresh a session, meaning that if the timer is set to 18 minutes for example, every 15 minutes (when the refresh is done) another 18 minutes will be added to the timer, allowing the endpoint to refresh again and again without limitation.

On Palo Alto firewalls, the packet count necessary to refresh a session is 16, the sip refresh process is around 2 or 4 packets every time, meaning the timer on the firewall needs to be set to much a higher time instead of only higher than 15 minutes. Doing a bit of math, 2 packets every 15 minutes means 8 packets per hour so the timer would need to be higher than 2 hours.

Take this last one with a grain of salt as this information was provided by a Palo Alto engineer on a previous service request but it is not something I found documentation for.

Hope this helps

[msuhre]

This just solved a problem my customer was having with a Spark Board talking to Spark Room kit through a Palo Alto firewall. Increasing the TCP/UDP timeout timer to 3600 seconds (1 hour) from 15 minutes fixed the problem. Thanks everyone! Took a week to figure it out and then I came across this response.

[charles huang]

I know this is an old post, but we run into several weird problems between Cisco Spark/DX80/WebEx behind Palo Alto firewall.

Question:

"Increasing the TCP/UDP timeout timer to 3600 seconds (1 hour) from 15 minutes fixed the problem."

TCP default timeout is 3600 seconds, UDP default timeout is 30 seconds on PA firewall.

What timer did you adjust to 3600?

[Dennis Mink]

richard,

did you ever get this fixed?