![]() If you, for example, have a custom application that uses TCP Port 23, but traffic passing through the firewall is identified as temenos-T24, and the misidentification causes confusion about the traffic, then an Application Override can be implemented to correctly identify the traffic. Let's look at a typical scenario where you might use an Application Override policy. In such cases, we recommended creating an application override to allow easier identification and reporting, and to prevent confusion. For these applications, we may not have signatures to properly identify the expected behavior and identify the traffic with a known application. In some cases, customers build their own custom applications to address specific needs unique to the company. You might ask why we'd ever need to override the normal application identification process. As soon as the Application Override policy takes effect, all further App-ID inspection of the traffic is stopped and the session is identified with the custom application. 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.Application Override is where the Palo Alto Networks firewall is configured to override the normal Application Identification (App-ID) of specific traffic passing through the firewall. 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. ![]() 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. Verify the firewalls timeout for sip ports (5060/5061) to be higher than 15 minutes.Īnother 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. 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. 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. 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). Please rate replies and mark question(s) as "answered" if applicable. 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. This means any SIP client can still call the address as per normal, but the VCS-E will interwork it to H.323. 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). ![]() 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.Īnother good resource is the Palo Alto Community - they might be able to get some expert help there. 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 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |