Sites utilizing Broadband internet or Dedicated Internet Access (DIA) for connectivity to UniVoIP services must ensure connectivity access requirements are met for provisioning, signaling, and audio communication.
To do so, below we provide three reference configurations that a customer can use to ensure connectivity to UniVoIP Services.

Address Lists

Endpoint Provisioning & Redirection

DNS lookup: ipv4list-provisioning.univoip.net

  • 216.191.234.139/32
  • 216.220.3.126/32
  • 52.0.183.240/32
  • 54.86.39.219/32
  • 199.242.62.167/32
  • 85.214.114.203/32
  • 85.214.114.186/32
  • 162.253.72.103/32
  • 162.253.72.104/32
  • 162.253.72.105/32
  • 162.253.72.108/32

General Service Edge

DNS lookup: ipv4list-service.univoip.net

    • 162.253.72.0/27
    • 162.253.72.160/27
    • 162.253.76.0/27

Enterprise Services

Enterprise Services

New customers will be provided unique URLs and IP addresses. These unique address are in addition to the General Service Edge list above. Enterprise customer addresses will be provided during the on boarding process.


Example Outbound Configuration Options

Examples below are possible outbound configuration methods to support voice services on your network. These are examples and should be reviewed and implemented as required for your specific environment by an IT professional. Every network is different, and the specific configuration implementation complexity must be weighted against the overall security concern of the business along with the maintenance overhead required to implement them.

Note

The access requirements below assume outbound source NAT from the internal LAN voice network to the public IP address of the site firewall. This is the only NAT requirement. There is no requirement to setup any inbound destination NAT rules. 

Example 1 - Allow All Outbound Connections

Permit all outgoing connections and all return traffic. By default, most SMB routers allow outgoing connections and the associated return traffic to those outgoing connections.

Example 2 - Allow UniVoIP Specific Voice Services

Permit all outbound connections to Provisioning and Services addresses


Please Note!

The UniVoIP Networks and any specific TCP and UDP port requirements will change over time. TCP and UDP specific ports are available upon request. Any firewall configurations with static definition of those networks or ports will be subject to change over time. The customer will be responsible to manage those changes.


Other Considerations

UDP Flood Protection 

UDP flooding protection and VoIP applications utilizing RTP do not work well together. It is recommended that UDP flooding protection on firewalls in the voice path be disabled.

SIP-Aware Firewalls 

Many firewall devices today understand the SIP protocol and include some type of NAT traversal or rewriting of SIP packets. When connecting SIP clients to UniVoIP, we recommend turning off any SIP features on your firewall. Our gateways handle any required NAT traversal. At best it is simply redundant to have two devices performing the same job. In worse cases, they interfere with each other, causing call-handling issues. These firewall services are often referred to as “SIP ALG”, “SIP Application Layer Gateway", "SIP Inspect" and “SIP Fix-Up”, among others. Our recommendation is to turn any SIP ALG off. That said, if you are not having any issues with SIP device connectivity, it can likely be left alone. SIP ALGs have no affect on the signaling for MiNet based devices such as the Mitel 5300 and 6900 series desk phones.

Cisco ASA Firewall

  • Disable SIP Inspect
ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# no inspect sip
CODE

PaloAlto Firewall


SonicWall Firewalls

VOIP => Settings:

  • Turn off Consistent NAT
  • Turn off SIP Transformation

State Tables and Connection Timeout

Modern Firewalls are most often stateful devices. Stateful devices keep track of every current inbound and outbound connection traversing the device. Why they do this is outside the scope of this document, but see below for further details. For a device to track connection states, it must allocate resources, usually a type of memory, to maintain the state table. In addition to maintaining the state of every inbound and outbound connection, the device must have a method to cleanup or delete state entries that may not have cleared correctly on their own, and have become stale. Why this happens is again outside the scope of this document, but it does happen, and stateful devices must have a method to handle it. If stale connections were allowed to build up without an automatic cleanup method, the stateful device would eventually fill its state stable to capacity, and and as a result new connections would not be possible through the device.

Connection Timeouts

Firewall State Table Sizing

The state table size of a device needs to be sized appropriately for the traffic patterns the device will be supporting. If the state table is too small, then valid connection states may be dropped by the firewall prematurely to clear space for new connections, resulting in active valid connections being dropped. 

When planning changes on your network that may increase the traffic traversing a stateful device, the device's state table should be reviewed to ensure it is sized appropriately to handle the expected traffic, while still ensuring a safety net of unused state capacity for traffic bursts. Some devices allow the state table to be increased in software, pfSense is one such example. Other devices such as the Cisco ASA Series Firewalls have a predefined maximum and must be replaced if the state table is not sufficient for the traffic load.

Further Reading

Stateful Firewall Fundamentals: A Better, Easier, More Secure Firewall