Configuring a Secure Voice Gateway

This blog is one of five dealing with the encryption of various Cisco UC devices. This particular piece deals with setting up a Secure Gateway. The other blogs in this series are Configuring Calling Encryption Between Cisco IP Phones, Configuring Calling Encryption Between Cisco IP Phones and Cisco Unity Connection, Configuring CUCM with Secure LDAP, and Configuring Secure Hardware Conferencing. The information in the LDAP article stands on its own, but the steps herein must be followed after following the steps in the article dealing with encryption on phones. This is because the CTL client must be run before any of the following steps can be completed.

The operations detailed in these blogs may not be the final word on all of the ins and outs of configuring the items. However, we discovered that there are very few, or no, articles dealing with these subjects written by someone who has actually performed the tasks. We, therefore, felt it would be a service to offer information about the steps that worked for us in our specific set of circumstances (particularly since we, apparently, fell into most of the traps).

Comments are certainly welcome, and we will be happy to update these blogs if need be.

This piece deals with configuring secure calls between phones and MGCP voice gateways. Configuring encryption between phones and H.323 and SIP gateways is also possible, but is beyond the scope of this document.

One thing that’s worth noting here is that the assumed design in this document isn’t necessarily what’s recommended by Cisco.  Signaling between CUCM and the gateway is done with an IPSec tunnel that’s actually terminated on CUCM.  We have been told that there is a fair performance hit to CUCM when this is done and it’s preferable in larger networks to set up IPSec in the infrastructure instead.

It’s important to remember that the security measures described here end at the voice gateway itself. Anything from the gateway out to the PSTN is unencrypted and unsecure.

1. The MGCP gateway must already be configured to send and receive calls.  The CAPF service must be started, the security on the cluster must be set to “Mixed-Mode”, and the phones must be configured as per the instructions in the document entitled “Configuring Calling Encryption Between Cisco IP Phones”.
2. Setting the actual encryption to the voice gateway only requires a single additional configuration. If the above steps have been followed, go into the CLI of the voice gateway and enter the command:
   verybiggw(config)# mgcp package-capability srtp-package
   Then issue a “no mgcp” and an “mgcp”. An encrypted RTP stream between the phone and the voice gateway can be confirmed by the presence of a lock icon next to the caller ID when a call has been placed (and answered).
3. That was the easy part, and the part that seems to be well documented. Unfortunately, a secure RTP stream doesn’t include secure MGCP signaling. If the MGCP information isn’t secured, the encryption keys for the RTP stream will be sent in the clear. For truly secure calls, an IPSec tunnel must also be configured between CUCM and the voice gateway. Realize that the IPSec tunnel will encrypt all communications between CUCM and the voice gateway; it’s not possible to simply send MGCP signals through an IPSec tunnel and nothing else. That’s OK, though, because the information that is exchanged between CUCM and the gateway is just signaling. The secure RTP stream travels directly between the gateway and the phone.
4. At this point a little thought ought to be given to the IPSec Policy Name. It would probably be good to create a naming standard because it’s likely that several policies will have to be defined.
5. Start the process by configuring IPSec on CUCM. Go to the OS Administration GUI on a server running the CallManager service, select Security > IPSEC Configuration and click “Add New”.
6. Type in the IPSec Policy Name generated in step 4. This will also be the Association Name. When we at Netcraftsmen set up IPSec, we did an Authentication Method using a Pre-Shared Key. This is something that will need to be typed into the router and it will appear in clear-text in a “show running-config”, so it will be a good idea to not use a password that is used anywhere else. Type in that Pre-shared Key on the next line. The Peer Type will be “Same”.
7. Type in the Destination address. This will be the IP of the interface on the voice gateway that faces the LAN. Realize that it is not possible to successfully set up an IPSec tunnel to a loopback address on a voice gateway. The tunnel must be created using the IP of a physical interface. This means that if signaling traffic will go to more than one interface on the voice gateway, an IPSec policy will need to be set up for each interface.
8. The “Destination Port” will remain at “Any”. The “Source Address” will be the IP of the CUCM. If two Ethernet ports on the CUMC server are bound together in failover mode, don’t worry about it. The IPSec tunnel will still work.
9. The mode can be either “Transport” or “Tunnel”. We selected “Transport” which only encrypts the payload of the data packets rather than the payload and the header. TAC assured us that this is still totally secure and it creates a little less overhead.
10. The “Remote Port” should remain at “500”. The “Protocol” should be “Any”. This is a pretty big gotcha, because it’s something that even most people in the CUCM team at Cisco TAC don’t know. We changed the “Encryption Algorithm” from “DES” to the more secure “3DES”, and also changed the “ESP Algorithm” to “3DES”. The other gotcha on this page is that there is an insignificant little “Enable Policy” box that must be checked in order to put the policy into effect. When this page is complete, click “Save”.
    Make sure to take note of all of the configurations. It’s a good idea to take a screen shot of them or write them down because they will be needed for the next step. Also, remember that if more than one LAN-facing interface on the voice gateway is configured to take calls, it will be necessary to create another IPSec policy on CUCM for the other interface(s). If you have more than one gateway with more than one interface, there’ll have to be an IPSec policy created for all of them. ALSO, if there are any Subscribers, all of the exact same IPSec policies (with appropriate Source IP Addresses) will have to be configured in the OS Administration GUI on each of them.
11. Sign on to the voice gateway again and configure the IPSec tunnel there. This should mimic what was created in CUCM. The ins-and-outs of the configurations are beyond the scope of this document, but the basic idea is as follows:
    – The gateway will have to be configured with the pre-shared key used to connect to each CUCM server.
    – An access list will have to be created to identify the traffic that needs to be encrypted.
    – The encryption policy will be bound to the appropriate physical interface on the voice gateway. The configurations we used looked like this (remember 192.168.1.2 is the gateway address, 192.168.1.10 is the CUCM address, “ciscopass” is the key we used in this test configuration):
    access-list 130 permit ip host 192.168.1.10 host 192.168.1.2
    !
    crypto isakmp policy 1
    encr 3des
    authentication pre-share
    group 2
    lifetime 3600
    crypto isakmp key ciscopass address 192.168.1.10
    !
    !
    crypto ipsec transform-set cm3 esp-3des esp-sha-hmac
    mode transport
    !
    crypto map cm3 1 ipsec-isakmp
    set peer 192.168.1.10
    set transform-set cm3
    match address 130
    !
    interface GigabitEthernet0/0
    ip address 192.168.1.2 255.255.255.0
    duplex auto
    speed auto
    crypto map cm3
12. Save these configurations. To ensure that the tunnel is working, go to the router and issue a “show crypto isakmp ca”. A connection to CUCM should display. The tunnel can also be checked at the CUCM side. Go to the CUCM OS Administration GUI, navigate to Services > Ping, and try to ping the voice gateway. The trick is to check the box marked “Validate IPSec”. The response should say, “Successfully validated IPSec connection.
13. As was stated earlier, make sure that IPSec policies are configured on every server running the CallManager service and make sure that policies are created for each LAN interface on the voice gateway(s) that will be handling calls. Also, remember that on the gateways themselves, policies must be created for each CUCM server, and an access list must be defined that identifies the traffic flowing between all of the servers and the gateway.