SIP Based VoIP

Supported SIP Deployments and NAT Support

The table shows a list of supported SIP deployments. NAT (Hide or Static) can be configured for:

• Phones on the internal network
• The proxy in the internal network

The Proxy refers to a SIP proxy and/or registrar. If there is more than one proxy device, signaling passes through one or more Proxies or Registrars. After the call has been set up, the media passes from endpoint to endpoint, directly or through one or more Proxies.

Additional Conditions for Using NAT in SIP Networks

You can use SIP with Network Address Translation but:

• NAT is not supported on IP addresses behind an external Check Point gateway interface.
• Manual NAT rules are only supported for proxy in DMZ deployments. (Use Automatic NAT as an alternative.)
• Calls cannot be made from an external source to two endpoints on the trusted side of a gateway if one of the endpoints is NATed and the other is not.

Hide NAT for SIP Traffic

In IPS > Protections > By Type > Engine Settings > SIP - General Settings, enabling the Hide NAT changes source port for SIP over UDP option configures the gateway to do Hide NAT on the:

• IP address of the SIP endpoint phones
• Source port of the SIP endpoint phones

For SIP over TCP, the source port is always translated if there is Hide NAT. With this option disabled, the gateway performs Hide NAT only on the IP address of the SIP endpoint phones.

This option must be enabled in environments where:

• (On the NAT tab of the related Network Object: node or network) the gateway is configured to do Hide NAT on the internal IP addresses of the endpoints and:
• The SIP server can register only one endpoint with a given IP address and port combination. (As with the Cisco Unified Communications Manager).

  Note - For all internal phones to be registered successfully on the server, the source port of the REGISTER message sent by the phone must be the same as the port in the Contact header of the REGISTER message. In Cisco IP Phones, for example, this is done by selecting the "NAT Enabled" option.

This section covers changes in SIP packets if the Hide NAT changes source port for SIP over UDP option is selected.

SIP Packet Before NAT

The packet capture shown here shows a SIP packet from a phone with IP address 192.168.3.40, and source port 5060 (the default SIP port). The phone's extension is 4321.

Packet after Hide NAT when option is disabled

The packet capture shown here shows the SIP packet after Hide NAT, with the Hide NAT changes source port for SIP over UDP option disabled. The IP address is translated to the Hide NAT address of 172.16.8.232, but the source port 5060 is unchanged.

Here, all the internal phones are registered with the same Source IP: port combination, for example: sip:4321@172.16.8.232:5060. A different phone with extension 8765 would register as sip:8765@172.16.8.232:5060.

Some SIP servers can register a phone only one IP address and port combination. As a result, only one of the phones behind that IP address will be registered successfully on the server.

Packet after Hide NAT when option is enabled

This packet capture shows the SIP packet after Hide NAT, with the Hide NAT changes source port for SIP over UDP option enabled. The IP address is translated to the Hide NAT address of 172.16.8.232, and the source port is also translated to an allocated port of 10015.

Here, a different port is allocated for each internal phone. Each phone is registered with a different Source IP: port combination. For example: one phone is registered as sip:4321@172.16.8.232:10015 (as shown in the packet capture). A different phone with extension 8765 is registered as (for example) sip:8765@172.16.8.232:10016.

As a result, all of the internal phones are registered successfully on the server.

SIP-Specific services

These predefined SIP services are available:

These legacy SIP services are available for gateways of version R75.40 and below:

For details on how to use these services, see the Securing Voice Over IP (VoIP) chapter of the R75.40 Firewall Administration Guide.

Legacy Solution for SIP TLS Support

If using the TCP:sip_tls_authentication service is not possible (for example if connections are encrypted by TLS, or NAT must be done on the connections) add these two rules instead:

• A rule that uses the udp-high-ports service to open all high UDP ports for the entities sending data, and
• A rule that uses the sip_tls_not_inspected service to open TCP port 5061 for the entities sending signaling

  Important - Opening all high UDP ports is very insecure. SIP signaling and data is not inspected.

To configure support for SIP TLS in environments where a secure solution is not available:

1. Define Network objects in SmartDashboard for the SIP phones.
2. Define a Network object for the SIP proxy.
3. Configure a rule that opens all high UDP ports and TCP port 5061.

   A typical rule that assumes the phones send data directly to each other, and not through the proxy, looks like this:

Important Guidelines for SIP Security Rule Configuration

• Anti-spoofing must be configured on the Check Point gateway interfaces. SIP entities on which NAT is configured must reside behind the gateway's internal interfaces.
• Do not define special Network objects to allow SIP signaling. Use regular Network objects. The firewall dynamically opens pinholes for data connections (RTP/RTCP and other). The R76 security gateway supports up to four different media channels per SIP SDP message.
• When using Hide NAT for SIP over UDP, do not include the hiding IP in the destination of the SIP rule.
• When using Hide NAT for SIP over TCP, you must include the hiding IP in the destination of the SIP rule. Doing this allows the initiation of TCP handshake from the external network to the hiding IP.
• For NAT on SIP entities, it is strongly recommended that you enable the IPS protection Strict SIP Protocol Flow Enforcement.

  To enable the protection:

  1. Enable the IPS Software Blade on the gateway.
  2. In IPS > Protections > By Protocol > IPS Software Blade > VoIP > SIP > Protocol Anomaly > Strict SIP Protocol Flow Enforcement set the Action to Prevent.
• Security rules can be defined that allow bidirectional calls, or only incoming or outgoing calls. The examples in the next sections explain how to define bidirectional rules.

SIP Rules for a Peer-to-Peer No-Proxy Topology

To configure SIP rules for this type of peer-to-peer topology.

1. Define a rule that allows IP phones in Net_A to call Net_B and, and vice versa:

or

The SIP over TCP services are:

• TCP:sip-tcp
• TCP:sip_tls_authentication
• TCP:sip_tls_not_inspected

1. Define Hide NAT (or Static NAT) for the phones in the internal network by editing the Network object for Net_A.
   • In the NAT tab of the Network object:
     • Select Add Automatic Address Translation Rules
     • Select the Translation method (Hide or Static)

     If you define Hide NAT:

     (i) Create a node object with the Hide NAT IP address.

     (ii) Add the node object to the Destination of the SIP over TCP rule.

2. Install the security Policy.

SIP Rules for a Proxy in an External Network

The figure illustrates a SIP topology with a Proxy in an external network.

To allow bidirectional calls between SIP phones in internal and external networks (Net_A and Net_B), and to define NAT for the internal phones:

1. Define Network objects (nodes or networks) for IP Phones that are:
   • Managed by the SIP Proxy or Registrar
   • Permitted to make calls, and those calls inspected by the gateway. In the figure, these are Net_A.
2. Define the Network object for the SIP Proxy or Registrar (SIP_Proxy).

   If the Proxy and Registrar are on a server that has one IP address, define only one object. If the Proxy and server are on the same server but have different IP addresses, define an object for each IP address.

3. Define one of these Security rules:

or

The SIP over TCP services are:

• TCP:sip-tcp
• TCP:sip_tls_authentication
• TCP:sip_tls_not_inspected

1. Define Hide NAT (or Static NAT) for the phones in the internal network by editing the Network object for Net_A.
   • In the NAT tab, select Add Automatic Address Translation Rules, and then the Translation method (Hide or Static).
   • If Hide NAT is defined:

     (i) Create a node object with the Hide NAT IP address.

     (ii) Add the node object to the Destination of the SIP over TCP rule.

     (iii) Consider enabling the Hide NAT changes source port for SIP over UDP option under IPS > Protections > By Type > Engine Settings > SIP - General Settings.

2. Install the security Policy.

SIP Rules for a Proxy-to-Proxy Topology

The figure illustrates a Proxy-to-Proxy topology with Net_A and Net_B on opposite sides of the gateway.

To enable bidirectional calls between phones:

• In the internal network and the external networks (Net_A and Net_B) and
• To define NAT for the internal phones and the internal Proxy (GW_A)

1. Define the Network objects (nodes or networks) for the phones permitted to make calls, and the calls subject to gateway inspection.

   In the figure, Net_A represents these phones.

2. Define the Network object for the Proxy objects (Proxy_A and Proxy_B).
3. Define this Security rule:

or

The SIP over TCP services are:

• TCP:sip-tcp
• TCP:sip_tls_authentication
• TCP:sip_tls_not_inspected

1. Define Hide NAT (or Static NAT) for the phones in the internal network.

   Do this by editing the Network object for the internal network (Net_A).

   • In the NAT tab, select Add Automatic Address Translation Rules and then the Translation method (Hide or Static).
   • If Hide NAT is defined: add a node object with the Hide NAT IP address object to the Destination of the SIP over TCP rule.
2. Define Static NAT for the Proxy in the internal network by repeating step 4 for the Proxy object (Proxy_A).
3. Install the security policy.

SIP Rules for a Proxy in DMZ Topology

The figure illustrates a SIP-based VoIP topology where a Proxy is installed in the DMZ.

To allow bidirectional calls between phones in internal and external networks (Net_A and Net_B) and to define NAT for the internal phones and the Proxy in the DMZ (Proxy_DMZ):

1. Define Network objects (nodes or networks) for phones that are permitted to make calls and the calls inspected by the gateway. These are Net_A and Net_B.
2. Define the Network object for the Proxy (Proxy_DMZ).
3. Define one of these security rules:

or

The SIP over TCP services are:

• TCP:sip-tcp
• TCP:sip_tls_authentication
• TCP:sip_tls_not_inspected

1. Define Hide NAT (or Static NAT) for the phones in the internal network:
   1. To edit the Network object for Net_A:
      • In the NAT tab, select Add Automatic Address Translation Rules
      • Select the Translation method (Hide or Static)
   2. To configure Hide NAT:
      • Select the Hide behind IP address option
      • Enter the IP address of the Hiding address of the phones in the internal network

      If Hide NAT is defined:

      (i) Create a node object with the Hide NAT IP address

      (ii) Add the object to the Destination of the SIP over TCP rule defined in step 3.

Static NAT on Proxy in the DMZ

Static NAT on the proxy in the DMZ can be configured with manual NAT rules or with automatic NAT (simpler) if all internal endpoints for which NAT is defined:

• Use SIP over UDP to communicate with the proxy in DMZ and:
• Do not send the data (e.g., voice) through the proxy but directly to other endpoints

If one of these conditions is not true, NAT on the proxy in the DMZ can be configured only with manual NAT rules.

To define static NAT for the proxy in the DMZ using manual NAT rules:

1. Create a node object for the Static address of the Proxy (for example, Proxy_DMZ_NATed)
2. Add Proxy_DMZ_NATed to the Destination of the Rule Base rule for sip services and sip-tcp services.
3. Add these manual NAT rules:

1. As for all manual NAT rules, configure Proxy-ARP.

   To associate the translated IP address with the MAC address of the gateway interface that is on the same network as the translated addresses:

   • Use the local.arp file in UNIX or
   • The arp command in Windows

   The fw ctl arp command displays the proxy ARP table on gateways that run on UNIX. On Windows, use the arp -a command.

   On UNIX-based (including SecurePlatform) gateways:

   1. Create a file $FWDIR/conf/local.arp
   2. Add the related entry, such as:

      192.168.6.145 00:0D:60:83:B3:74

      Where 192.168.6.145 is the static address, and 00:0D:60:83:B3:74 is the address of the external interface.

   3. From the SmartDashboard File menu, select Policy > Global Properties, and in the NAT page, select Merge Manual Proxy ARP Configuration.
   4. Install the security policy.
   5. Make sure that the fw ctl arp command shows the new entry in the proxy ARP table.

To define static NAT for the proxy in the DMZ using automatic NAT rules:

You can define Static NAT for the Proxy in the DMZ by using automatic NAT rules. To use automatic NAT rules, edit the Network object for the proxy (Proxy_DMZ).

On the NAT page of the General Properties window:

1. Select Add Automatic Address Translation Rules.
2. Select Static as the Translation method.

Using SIP on a Non-Default Port

By default, SIP uses the UDP port 5060. However, SIP phones and SIP Proxies can be configured to use a different port. The gateway will enforce security on the port specified for SIP.

To configure a new port, a new UDP service must be defined in SmartDashboard. You can use the newly defined service and the predefined service (sip) in the same Security Rule Base rule.

To configure a new SIP service:

For UDP:

1. From the SmartDashboard File menu, select Manage > Services > New > UDP.
2. In the UDP Service Properties window, name the new service and specify the new SIP port.
3. Click Advanced….
4. In the Advanced UDP Service Properties window, select the Protocol Type: SIP_UDP
5. Click OK.
6. Define a rule in the Security Rule Base that uses the new service.

For TCP:

1. From the SmartDashboard main menu, select Manage > Services > New > TCP.
2. In the TCP Service Properties window, name the new service and specify the new SIP port.
3. Click Advanced….
4. In the Advanced TCP Service Properties window, select the Protocol Type: SIP_TCP_PROTO
5. Click OK.
6. Define a rule in the Security Rule Base that uses the new service.

Enabling Dynamic Opening of Ports for SIP Signaling

The sip_dynamic_ports service enables the dynamic opening of ports in the gateway for SIP signaling.

• By default, port:
  • 5060 is defined for SIP over UDP and TCP services,
  • 5061 is defined for SIP over TLS services.
• SIP services can be defined for non-default ports.

The service is used to enable the dynamic opening of ports that are not defined by one of the SIP services (default and non-default). Opening such ports allows the establishment of SIP connections. The Check Point gateway opens and closes ports based on the inspection of SIP signaling messages.

Add the sip_dynamic_ports service to the rule when:

1. The phones register themselves at a SIP server by associating their phone number with a port other than 5060 or 5061. For example, a registration request for phone number 2001 with IP address 172.16.8.3 port 3000. An example of such a Contact header field is as follows:

   Contact: <sip:2001@172.16.8.3:3000;rinstance=64d25786c64e7975>;expires=3600

2. The "rport" parameter is used in the Via header field. For example:

   Via: SIP/2.0/TCP 172.16.8.3:5060;branch=z9hG4bK-1193792f8039818cd82e34eec4112ae8;rport=4039

   (see RFC 3581 - An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing)

   Note - Use the sip_dynamic_ports service in a rule together with at least one other SIP service (over TCP or UDP).

Example Rule With the sip_dynamic_ports Service

Example SIP UDP rule:

• SIP_phone is the IP address of the SIP phone.
• SIP_server is the IP address of the SIP server.