Showing results for 
Search instead for 
Did you mean: 

CUCM-IPSEC Policy Failure between CUCM and MGCP-GWY


CUCM 10.5(2) IPSEC security policy between ISR-G2 (15.5) MGCP GWY establishes ISAKMP SA, but fails to establish IPSEC SA's. 

IPSEC policy matches on CUCM and GWY. 

IKE PHASE 1 Main Mode is successful. I get all 6 MM messages on sniffer trace and a "show crypto isakmp sa" shows QM_IDLE Active.

IKE Phase 2 Fails.  Sniffer shows IKE Phase 1 completing and IKE Phase 2 not completing.  I reduced the IPsec Sec. Parms from AES 256, sha-256 and DH Group 5 down to 3des and Sha1 and Group 2.  I was able to get IKE Phase 2 Quick Mode to work temporarily. Got both unidirectional IPsec SA's to establish ESP spi in both directions momentarily.  Played with lifetime values too.

Prior to reducing the IPSec Sec. Params, I was only seeing the GWY to CUCM IPSec SA come up with a good esp spi.  Then from the GWY using "show crypto ipsec sa", I could see pkts being  encapsulated, encrypted and digest, but no pkts were being decapsulalted, decrypted, or verified.   A ping sourced from the GWY incremented the encrypted packets counters when I did another "show crypto IPsec sa".  It appears the CUCM to GWY IPSec SA is having an issue. Then the whole IKE Phase 1 and Phase 2 process restarts.  I get 6 MM Pkts and only one Quick mode pkt going from the GWY to CUCM.

Cisco BUG  CSCuo53813 talks about the validate IPsec ping failing from CUCM.

From the CUCM OS admin web page, the IPsec policy appears to be inactive.  A validated IPsec always ping fails. Usually I get no response.  This makes sense since IPSEC SA is not up.

The GWY has a transform-set, while I can only assume the CUCM creates its own transform-set from the IPSec policy page.

BTW, my MGCP works perfectly unencrypted and with media encrypting enabled.  MGCP breaks as soon as the IPSec overlay is applied on CUCM and the MGCP GWY.

Integration and Test Lab consists of VMware ESi  Host with CUCM VM's connected to VLAN 100 with SVI enabled on a 3750X MLS switch with routing enabled. The same 3750 has another VLAN 400 with SVI enabled on it and the MGCP GWY is connected to VLAN 400.  InterVLAN routing works fine for all my Voice and Video and CUBE SBC network ITI.  The MGCP GWY can ping the CUCM and the CUCM can ping the MGCP GWY.  Both the CUCM and the GWY can ping all other devices fine.






                  Auth                      = preshared key

     Preshared Key     = cisco123

     Dest addr             =

     Dest port              =  any

     Src Addr              =

     Src port               =  any

     Mode                   = Transport

     Remote port        =  500

     Protocol              = TCP

  Encryption Alg      = aes 256

  hash Alg               = sha256

  ESP alg                = Rijndel , but have tried aes 128 and aes 256, no change

Phase 1 DH Group

 Phase one lifetime  =86400

 Phase one DH Group  =5

Phase 2 DH Group

 Phase one lifetime  =86400

 Phase one DH Group  =5


access-list used is: access-list 101 permit ip host host

crypto isakmp policy 1

 encryption aes 256

 hash sha256

 authentication pre-share

 group 5

 lifetime 86400

crypto isakmp key cisco123 address

crypto IPsec transform-set rtpset esp-aes 256 esp-sha256-hmac

  mode transport

crypto map rtp0 local-address gigabitethernet0/0

crypto map rtp0 1 IPsec-isakmp

set peer

set transform-set rtpset

match address 101

int gi0/0

ip addr

duplex full

speed 1000

crypto map rtp0

ip route

I've built CUCM to MGCP GWY and secured with IPSEC in the past, and don't recall ever having this much trouble getting IPsec it to work.

If anyone can shed some lite on this issue, it will be appreciated.

5 Replies 5

Mohammed al Baqari
VIP Advisor VIP Advisor
VIP Advisor

To summarize, is it working with lower IPSec parameters but not with strong security parameters?

On the GW, can you turn on the debugs 'debug cry isa' and share the output.

Hi Mohammad,

Thanks for your response. 

yes, I lowered the Encrypt/Hash Params. down to 3DES/MD5 DH Group 2 and IPSec works perfectly.   I get the isakmp SA and both IPsec SA's, one in each direction.

BTW, I had a typo on the Initial CUCM IPsec Policy value for Protocol* = TCP,  I have it set to ANY. 

Once I got the solution working with 3des/md5, I went back and began to change the IPSec parms to see if I can increase the security posture of the IPSec policy.  I felt optimistic, so I set everything to AES256/256-HMAC, DH Group 5. and again the GWY to CUCM IPSec SA comes up but the CUCM to GWY SA does not.  CUCM to GWY SPI in not being formed.  I verified that with a Sniffer capture.

I'm wondering if there is a bug.   The CUCM IPsec Ping failed to work even when the 3DES solution was fully functional.   I think this SW needs  improvement.

I'll run a debug and see what I get


Q? When setting the CUCM IPSec encryption Algorithm to AES256, what should the ESP Algorithm be set to.  I've used RJINDAL and AES 256 and both fail the same way. 

Try to lower Group to 2 while keeping hashing and encryption.

Also. what version of CUCM you are running? It might be that CUCM doesn't support this high level encryption.

After AES 256 failed, I went back to the bottom and worked my way up.

I got AES 128, SHA1, DH Group 2  working perfectly.  And now the CUCM IPSec Validate Ping test is continuously successful.  Previously, the ping always failed even when the IPSec tunnel was working properly with 3DES/MD5.

I'm running CUCM 10.5(2) and it supports AES 256. 

I'm beginning to thick the limitation may be associated with the MGCP GWY encryption SW even though the IOS 15.5 CLI supports up to AES 256 and SHA 384+.  SRTP seems to have a threshold of AES-128.  Would the MGCP SRTP-Package used for media encryption be an issue.  Not sure if Cisco is really enhancing their MGCP solution since this technology is giving way to SBC technology.  Thoughts?

Example: When I make an external 9XXXXXXX call from my EX90 to a remote EX90 on another secure CUCM cluster.  My Media security level is limited to AES-CM-128.

I get lock icons on both EX90's and my sniffer shows the MGCP signaling going through the IPSec tunnel and the RTP media stream is encrypted.

At this point, I'm happy with AES-128 encryption for this configuration, but would like to secure the entire system and endpoints using AES-256 and a higher HMAC hash at least sha256.

I'll check to see if the EX90 has an AES-128 encryption limitation as well.


I have determined that the EX90 has an AES-128 encryption limitation.  Found verbiage in the EX90 admin Guide stating this. Confirmed it in lab testing.

CUCM to MGCP GWY running AES-128 IPsec is running solid, and the CUCM Validate Ping executed successful Pin.   Just can't get AES-256 to work. Appear to be sourced from CUCM since its SA fails to establish, while the GWY to CUCM SA establishes and remains active.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers