How to Configure the 'sip-trunk' App-ID

Note: Customers are not required to modify firewall policies unless the conditions outlined below are in use.

Issue: Firewalls are typically required to act as an ALG to create pinholes for SIP sessions and provide address translation capabilities. The "sip" App-ID creates such pinholes that allow the protocol to function seamlessly when it encounters the firewall. When a SIP server communicating using static NAT in one zone (source) emits traffic that is destined to a SIP server in another zone (destination), the firewall creates a pinhole that consequently allows a host using SIP within destination zone to communicate with the SIP server in the source zone. For example, a SIP server P.Q.R.S in the source zone static NAT-ed to D.E.F.G:5060, dispatches a SIP REGISTER message to an external SIP server A.B.C.D:5060 in the destination zone. This results in the firewall creating a pinhole that accepts incoming connections from hosts in the destination zone addressed to D.E.F.G:5060.

Resolution: The "sip-trunk" App-ID disables the creation of such a pinhole when used in conjunction with an Application Override. This App-ID is meant to be used between known SIP servers. The source and destination addresses of these servers must be specified, with their SIP traffic overridden to the new "sip-trunk" App-ID. In addition, given the lack of a pinhole, administrators are required to configure a Security Policy rule that permits traffic between these servers in the reverse direction. This allows the SIP servers to communicate with each other, and the absence of the pinhole prevents the firewall from accepting inbound connections from other hosts within the destination zone.

Requirements:

• SIP Registrar or Proxy is statically NATed through the firewall
• SIP trunking is being used in the environment
• Content database version 518 or higher

Note that switching to sip-trunk requires clearing all active SIP traffic, so the process will be disruptive to users.  We recommend scheduling an outage or maintenance window after hours to implement these changes.  Also, any ports other than udp/5060 that are in use by your SIP server will need to be added to the new policies accordingly.

How to Implement:

1) Create an Application Override policy with a rule that allows sip-trunk traffic on udp/5060 as well as any other ports that are being used by this application in your environment.  The policy can be limited in scope to only match the desired SIP traffic by specifying source and destination IP addresses as well as zones.

2) Create a Security policy that blocks the “sip” application.

3) Create a Service object that contains udp/5060 as well as any other ports required by your SIP servers.

4) Create Security policies beneath the rule created in the previous step that allows the “sip-trunk” application.  This policy should be limited in scope to only match the desired SIP traffic by specifying source and destination IP addresses as well as zones.

5) Create a static bi-directional source NAT policy.

6) Commit policy.

7) Clear all current SIP sessions from the CLI (NOTE: this command will disrupt all active SIP traffic):

> clear session all filter application sip

8) Clear the application cache from the CLI:

> clear appinfo2ip