Support Center > Search Results > SecureKnowledge Details
How to configure VoIP on Locally Managed 600 / 700 / 910 / 1100 / 1200R / 1400 / 1500 appliances Technical Level
Solution

To correctly configure VoIP to work on Locally Managed 600 / 700 / 910 / 1100 / 1200R / 1400 / 1500 appliances, the topology of the VoIP/SIP environment must be understood first.

Below are the most common topologies deployed with Locally Managed 600 / 700 / 910 / 1100 / 1200R / 1400 / 1500 appliances:

  1. Only IP-Phones behind the firewall that register to an external[cloud] PBX/VoIP Provider.
  2. IP-Phones and an Internal PBX that register/use an external[cloud] PBX/VoIP Provider.
  3. IP-Phones and Internal PBX(s) behind multiple sites connected through VPN.
  4. Soft-Phones and Internal PBX behind multiple sites connected through Client-to-Site VPN.
  5. External IP-Phones that register to an internal PBX.

IMPORTANT: Read the important notes at the end of this article. The configuration below is not enough to ensure a flawless SIP deployment.

 

Configuration details for each case:

First Case: Only IP-Phones behind the firewall that register to an external (cloud) PBX/VoIP Provider

  • Topology

  • Configuration

    Configure the following:

    • VoIP Provider IP range (if it has several signaling IP ranges - configure them all as Network Objects, then assign them all to a new network object group, ex. VoIP-Provider)
    • Phones IP range (configure it as Network Object, ex. IP-Phones)
    • Create 1 Incoming Rule: From VoIP-Provider To IP-Phones at service SIP_UDP (depends on the VoIP Provider Specification - this is the most common) action allow.

    In Gaia Portal: Access Policy -> Policy, under 'Incoming, Internal and VPN traffic'

 

 

Second Case: IP-Phones and an Internal PBX that register/use an external (cloud) PBX/VoIP Provider

  • Topology

  • Configuration

    Configure the following:

    • VoIP Provider IP range (if it has several signaling IP ranges - configure them all as Network Objects, then assign then all to a new network object group , ex. VoIP-Provider )
    • Create a Network object for the PBX (ex. Internal_PBX).
    • Create 1 Incoming Rule: From VoIP-Provider To This Gateway at service SIP_UDP (depends on the VoIP Provider Specification - this is the most common) action allow.
    • Create 1 NAT Rule:
      • Original Src IP: Any
      • Original Dst IP: This Gateway
      • Original Service: SIP_UDP
      • Translated Src: Original
      • Translated Dst: Internal_PBX
      • Translates Service: Original

    Incoming Rule: In Gaia Portal: Access Policy -> Policy, under 'Incoming, Internal and VPN traffic'

     

    NAT Rule: In Gaia Portal: Access Policy -> NAT

 

 

Third Case: IP-Phones and Internal PBX(s) behind multiple sites connected through VPN.

  • Topology

  • Configuration

    No Access or NAT rules are needed in this case as long as VPN traffic between the sites is allowed.

    Make sure you are aligned to firmware R77.20.80 and above for Site-to-Site VPN cases.

 

 

Fourth Case: Soft-Phones and Internal PBX behind multiple sites connected through Client-to-Site VPN

  • Topology

  • Configuration

    Clients in this topology are located behind a normal ISP router/modem and are using a VPN client [ Check Point Endpoint Security VPN client] or other L2TP connection that ensures a VPN office mode network assignment from the firewall's side.

    Configure the following on the site's firewall:

    • Enable 'VPN Remote Access - Back connections enable' parameter from Device -> Advanced Settings.
    • Create a Network object for the PBX (ex. Internal_PBX).
    • VPN Office Mode IP range (configure the office mode network assigned in VPN -> Remote Access Advanced as Network Object, ex. office)
    • Create 1 NAT Rule:
      • Original Src IP: Internal_PBX
      • Original Dst IP: office
      • Original Service: Any
      • Translated Src: Original
      • Translated Dst: original
      • Translates Service: Original

    Back Connection parameter, from Device -> Advanced Settings:

     

    NAT Rule: In Gaia Portal: Access Policy -> NAT

 

 

Fifth Case: External IP-Phones that register to an internal PBX

  • Topology

    Note: Such topology is not supported if the external IP-Phones use the external public IP of the firewall in order to register to the internal PBX.

  • Configuration

    For this to work, use one of the below:

    • An additional external public IP [other than the firewall's external public IP] and assign it to the internal PBX.
    • Encrypted traffic [VPN]:
      • Through site-to-site connectivity, in which the phones are behind another site that has a VPN tunnel with the site hosting the internal PBX [third scenario in this article].
      • Through client-to-site connectivity, in which the phones have VPN remote access to the site hosting the internal PBX [fourth scenario in this article].

 

Important Notes relevant to all cases:

  • Make sure you're running firmware version R77.20.80 or higher.

  • Make sure that you're using standard RFC SIP ports (5060 UDP for source and destination ports) especially in clear text cases (not crucial in VPN cases).

  • If the source port the VoIP setup is using [local SIP port] is something other than 5060, make sure to modify the system defined SIP_UDP/SIP_TCP service to include this port, from Gaia Portal -> Users & Objects -> Services, search for SIP_UDP/SIP_TCP then edit 'Ports' field.

  • In case the destination port the VoIP setup is using is something other than 5060, then please make sure you are aligned to firmware version R77.20.80 or higher.

  • In case the service group 'SIP' [which contains both SIP_TCP & SIP_UDP] is used in the access rules while the standard ports were modified [ports used other than 5060] , then please make sure you are aligned to firmware version R77.20.80 or higher.

  • Disable STUN server or remove any external IP configured on the phones/PBX/trunk.

  • Make sure SIP inspection is enabled: from Gaia Portal -> Users & Objects -> Services, search for SIP_UDP (make sure that the 'Disable inspection for this service' checkbox is cleared).

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.
Applies To:
  • 02304496 , 02305439 , 02097909

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment