Failed Security on 4XXX ISRs

[refram]

We are running CUCM 11.5(SU7) and a number of 4XXX ISR voice gateway routers running version 16.3.8.  We have SIP trunks between CUCM and the routers and we are securing the trunks with TLS.  The majority of the SIP trunks work, but there are others that do not.  In have checked and re-checked the configurations on CUCM and on the IRSs.  I have also re-installed the certificates.  Interestingly, the certificates work for secure conference bridges. 

Conversely I have a different group of ISRs where the secure SIP trunks work, but the secure conference bridges will not register.

Does anyone know of a bug for the 4XXX ISRs that I might not have been able to find?

[cmarva]

not sure about specific bugs, but 16.3.8 is a pretty old version so there very well could be. I would look at picking one of the problematic ones and upgrading to something more recent, (16.12.5 is one of the current recommended versions) and see if that makes a difference. It's easy enough to reboot back into the old version if it doesn't. But looking at the larger picture I would definitely think about an upgrade cycle for the whole inventory of VGs.

[refram · Accepted solution]

I finally got a workaround for both of the issues.  I don't think you can call them "fixes" because of the 500+ 4XXX-series routers we have only a handful were having the problems.  However, when Cisco managed to find something that made them work they closed the book on the TAC case and we probably will never know why one set of configurations work on most routers but a different set of configurations are required for other routers of the SAME MODEL.  At least until an official bug is released.

Anyway, for the secure SIP trunk problem we had to start binding http to a specific interface.  The command we are using is:

ip http client source-interface Loopback0

For the secure conference bridge problem we had to remove the name of the specific trustpoint that we had bound to sccp and allow the protocol to discover the trustpoint that it wanted to use.  So instead of something like:

sccp ccm <IP_of_CUCM> identifier 1 version 7.0 <name_of_trustpoint>

...we now do something like:

sccp ccm <IP_of_CUCM> identifier 1 version 7.0