DNS is the tool which associate an IP Address with a name, an URL. So using name instead IP Address can also introduce failures because if your DNS down , you can’t resolve anymore IP addresses. But it can be very helpful in the case of a DR mode ( where you need to point the server to a different IP address)
To work correctly with your voice flows, a NAT device must inspect Layer3 and Layer4 protocol ,port information and sometimes the embedded payload.
Cisco IOS NAT ALG can support the following voip protocols :
- H323v2
- H225
- H245
- RAS
- SIP
- SCCP
So if you change the default port number of these protocols, then you have to change it also in the configuration with the following command ip nat service <<protocol>> tcp port <<port-number>>.
Pay attention also that NAT doesn’t support voice signaling encryption
Firewalls are commonly used to protect networks, including those that transport voice traffic. Firewalls inspect the header and sometimes can inspect also the payload of packets. Stateful firewalls also maintain state information so that they know which traffic forms part of permitted flows and should be allowed.
For voice traffic, mandatory traffic are required as MGCP,H323,SIP,SCCP,RTP and RTCP. In case of RTP and RTCP, the amount of ports must be larger as it represents thousands ports.
Be also cautious where you put your VPN gateway because if the VPN gateway is placed in front of a firewall, the VPN IPSec will be added or removed so then you can inspect your traffic. But in the case where your VPN gateway is behind the firewall, this one can’t inspect anymore the traffic so it could be a backdoor for intruder.Same thing for the placement of NAT in your firewall.
Note also that ALG doesn’t work with signaling encryption
So pay attention that by default, Cisco firewalls/ALG don’t support in native Unity, IPCC Express, IPCC Enterprise, Attendant Console and SCCP video. It is then require to configure manually your firewall manually to authorize the traffic for these ports.
Here is as a reminder a collection of TCP/ UDP Ports used in an IP Telephony network:
| PORT | PURPOSE |
| TCP/1433 | SQL |
| TCP/2552 | Call Manager database change notifications |
| TCP/2555 | RIS database server |
| TCP/2556 | RIS database client |
| UDP/3000 | Receive change notification from Call Manager database |
| UDP/3001 | Database change notification from publisher to applications |
| UDP/3020 | Dialed Number Analyzer plug-in database |
| TCP/3372 | SQL Distributed Transaction Coordinator |
| TCP/7727 | Application database change notification, CTI, voicemail, and so on |
| TCP/8001 | Client database change notification |
| TCP/8002 | Intracluster Communication Service |
| TCP/8003 | Intracluster Communication Service |
| TCP/8009 | Internal Tomcat requests |
| TCP/8111 | IPMA Web requests |
| TCP/8222 | Extension Mobility web requests |
| TCP/8333 | Webdialer web requests |
| TCP/8444 | Extension Mobility service requests |
| TCP/8555 | Apache-SOAP web requests |
| TCP/8666 | IPMA web requests for nondefault locales |
| TCP/8777 | Tomcat manager web requests |
| TCP/9007 | CDR Aalysis and Recording web requests |
| TCP/102 | Directory Access Protocol (DAP) for DC Directory |
| TCP/8404 | Local Directory Access Protocol (LDAP) for DC Directory |
| TCP/8405 | LDAPS for DC Directory |
| TCP/389 | LDAP query to external directory (AD, Netscape) |
| TCP/636 | LDAPS query to external directory (AD, Netscape) |
| TCP/2000 | SCCP |
| TCP/2443 | Secure SCCP (SCCPS) |
| TCP/3804 | CAPF |
| UDP/16384 – 32768 | RTP,SRTP |
| TCP/4224 | Cisco VT Advantage |
| UDP/1718 | Gatekeeper H225 Discovery |
| UDP/1719 | Gatekeeper H225 RAS |
| TCP/1720 | H225 signaling services for H323 gateways and Inter-Cluster Trunk (ICT) |
| UDP/2427 | MGCP gateway control |
| TCP/2428 | MGCP gateway backhaul |
| TCP/UDP/5060 | SIP Gateway and Inter-Cluster Trunk |
| TCP/2444 | CTL Provider |
| TCP/2748 | CTI Application Server |
| TCP/2789 | JTAPI Application Server |
| TCP/2912 | IPMA Server |
| TCP/1099-1129 | Attendant Console |
| UDP/3223 | Attendant Console |
| UDP/4321 | Attendant Console |
There is two types of security that you can enable with Call Manager
- Mixed mode : In this mode, depending the security configured on each phone, you can have secure calls when both devices are security-enabled and when one of the phones is missing security, your call will be nonsecure.
- Nonsecure mode : As all phones are not set up with security (default configuration), all calls are nonsecure.
When you device to put security on phones , they can support the three following levels:
- Nonsecure mode : secure calls are not supported
- Authenticated mode : the phone will be able to authenticate calls
- Encrypted mode : the phone will be able to support encrypted calls
If you enable the authentication and the encrytion on your network , you are then able to secure the media traffic as well the voice signaling.
If you want to have security on the media flow, it is then mandatory to secure also the signaling as the keys which are used to secure the media traffic are exchanged during the signaling phase.
SCCP messages sent by IP Phones and Call Manager can be secured using TLS, it is the signaling part. Then for the protection of the media traffic so the RTP packets , you will use the Secure RTP which is providing a framework for encryption and authentications of your stream.
SRTP will be also use between your MGCP gateway and your IP Phone but you need to know that your SRTP keys are exchanged in cleartext session between the MGCP gateway and the Call Manager.
Typically , in a PKI, there is a singme Certificate Authority (CA) or hierarchy of CA to issue certificates. However, several other elements can play this role too:
- Self-signed certificates : These are certificates self-signed by the Call Manager,TFTP and the Certificate Authority Proxy Function (CAPF)
- Certificates signed by the CAPF or external CA : These are issued as Locally Significant Certificates (LSC) to IP phones
- Certificates signed by the Cisco CA : Some IP phones models are shipped with manufacturing installed certificates (MIC)
All these certificates types are necessary to carry out functions such as authentication and encryption of voice signaling and media traffic, authentication of images and authentication of configurations files.
To facilitate the distribution of the certificates to IP Phones, you can create a Cisco Trust List (CTL) which is created by a plugin that you install on a Windows server or a desktop. This CTL client will collapse all informations of trusted certificates entities to be issue in a file.This file will be signed by the Cisco Site Administrator Security Token (SAST). Then once the phone will initiate their boot-up sequence , they will be able to use this CTL list from the TFTP to validate server certificates and security tokens. This will also enabled secure communications and file authentications. Here are what you can find as elements in your CTL file:
- Call Manager or TFTP
- Co-resident Call Manager and TFTP
- CAPF
- Alternate TFTP server
- SAST
So the informations that you will find for these entries will be
- PKI
- Server function
- IP Address
- …
As we have already mentioned it , don’t forget that new IP Phones models come with an existing certificates , it is installed at the factory , this is called MIC. So even if these certificates are good, it is recommended to replace them by LSC so that you ensure a global solution for all your phones and not a mixed solution. LSC can be issued by the CAPF or an external CA with a transiting CAPF as it will act as a proxy when phones enroll.
Recent Comments