The placement of Voice Infrastructure devices on the network presents some challenges to voice engineers. They must satisfy the security requirements of the Enterprise while providing simple and uninterrupted access to external systems such as PSTN SIP trunks and internal systems such as VoIP phones and servers. In this article, we discuss Voice security from a Routing and Switching point of view. This article is not about internal Voice security mechanisms such as authentication and encryption.
Obviously, we do not recommend terminating external SIP trunks on Unified Communications Manager servers directly. Therefore, in this article, we will talk about the placement of Voice Gateways on the network and the interaction between the various Voice components. We consider the Voice Gateway to be a CUBE that terminates all media streams.
Placing a Voice Gateway on the internal network is a major security risk. It exposes your entire enterprise to an external entity even if that entity is your trusted voice carrier. Therefore, all our designs require placing the Voice Gateway on a DMZ behind a NextGen firewall such as Cisco ASA with Firepower services. First, the ASA does SIP inspection and can deploy security ACLs to filter inbound traffic and only allow connections from specific IPs such as your Voice Gateway SIP signaling and media IP. Second, NextGen firewalls can detect and protect against malware embedded in the data stream.
The following scenarios are based on some very common WAN designs that we have seen deployed at our customer sites of various sizes.
I. Dedicated PSTN SIP trunk via a dedicated Voice Gateway.
This is the simplest setup. A primary dedicated SIP trunk over a private T1 or Ethernet WAN connection and an optional backup SIP trunk via the Internet. Note that the backup SIP trunk can be hosted on a separate Voice Gateway too to provide hardware redundancy. The following diagram illustrates this design.
In this scenario, the Voice Gateway is on a dedicated DMZ behind the NextGen firewall. The firewall has SIP inspection turned on and only allows inbound SIP control traffic sourced from the inside IP of the Voice Gateway to the CUCM. Similarly, an outbound ACL controls SIP signaling traffic from CUCM to the Voice Gateway. SIP media traffic will be automatically allowed based on the negotiated RTP ports.
II. Voice Gateway is co-located with your MPLS router
Today’s most common WAN designs utilize MPLS as the underlay infrastructure for Enterprise WAN connectivity. It is also not uncommon for an MPLS carrier to provide PSTN SIP trunks over the same physical fiber or copper cable. Therefore, to save on hardware your Voice Gateway might be co-located with your WAN ISR router. If your MPLS/SIP provider separates the two functions and terminates each on a separate VLAN, then it is possible to use VRF (Virtual Routing and Forwarding) to virtualize your router: The Voice portion can use the Global Routing table while the MPLS portion can use a VRF. Otherwise, both technologies can use the Global routing table. The following diagram illustrates this former scenario:
In the above diagram, we go a step further by separating MPLS and Voice Routing tables. Note that we are only discussing Voice Security. You still need to configure Quality of Service (QoS) to prioritize your VoIP traffic whether you are using a VRF or not. QoS is outside the scope of this article.
As in the previous scenario, the security ACLs, firewall inspection, and Firepower services protect the Enterprise Voice Infrastructure from external attacks.
III. Dedicated Voice Gateway and a shared MPLS/SIP connection
This is a very common design in which the customer orders an MPLS and a SIP trunk from the same carrier as in the 2nd scenario above. However, the customer is using a dedicated Voice Gateway with an optional backup SIP trunk to the same carrier via the Internet.
The following diagram illustrates this solution:
In this scenario, a single Voice Gateway sits behind a NAT firewall. The VG communicates with the SIP provider via the “out_voice” interface and communicates to CUCM and the IP Phones via the “in_voice” interface. NAT is only used when communicating over the backup SIP trunk via the Internet connection. With recent firewall firmware, we see no issues in NAT’ing SIP control and media traffic. As in all previous scenarios, the Voice Gateway sits on a DMZ segment and the CUCM sits on a dedicated internal VLAN. Note that the “in_voice” interface can be connected directly to the internal LAN without going through the firewall.
While there are many ways to protect your Voice Infrastructure, we have highlighted three common scenarios and listed the advantages of having Voice control and media traffic inspected by a NextGen firewall. Other more complicated designs can be derived from the above scenarios especially if you combine your DMVPN, MPLS, or iWAN technologies into a single device.