In our network our 3rd party handsets register with our Call Manager after connecting to our network via VPN. Our network does a good job of only allowing specific IP addresses in our network. However, our handset has two applications that allow it to connect (VPN app, SIP app). What happens is the two apps are configured to connect upon start of the device. We cannot control which app connects first. Unfortunately, in order for the handset to register to the CUCM it must first be connected to our VPN. When the VPN connects first, followed by the SIP client connecting our registration process works like a charm. However, if the VPN connection is delayed, the SIP app doesn't care and attempts to connect to the CUCM with its non-vpn address and keeps attempting. Once it finally gets its vpn address the ip of the handset changes to its vpn ip address, but it continues trying to send the previous sip messages containing the non-vpn IP. The registration process still works as we can see that device is registered to the CUCM, however the IP address listed is not from within our network. In addition communication to/from the handset is affected due to it having an incorrect ip address. My question is, Is there a way to control the registration (filter) it in such a way that only devices with specific ip address in the SIP message (sip contact) can register. My hope is that when the devices attempts to register with the CUCM that it will fail and cause the device to reset and the device app will re-generate a new sip session with the correct IP address in the SIP contact field. I have seen some controls (IP registration control in Call Manager Express), but I believe that filter is applied at layer 3, which our ACLs already prevent. Our issue is happening higher up the stack. Any assistance you can provide on the matter is greatly appreciated.
CUCM v 10.5.2
Unfortunately, UCM does not have the ability to deny registration based on IP address. UCM does allow you to register the device to a specific device pool based on the IP Address through the Device Mobility feature, but we cannot outright deny a device based on the source IP.
I am not an IP Routing expert, but you should be able to set up an access list that allows SIP/SCCP registration messages (TCP) from defined IP's to reach UCM. If the IP does not match the VPN IP address range or your voice VLAN or your data VLAN (for PC/MAC based softclient), the you drop the packet. That should prevent the non-VPN connections from establishing until the VPN client is up. This would solve the problem at L3 in the network instead of L7 on UCM.
Technical Marketing Engineer
Thanks for your response. Unfortunately, we are only permitting specific IP addresses from reaching our CUCM for registration. The issue here is that the handset SIP application is encapsulating a sip packet and attempting to send it out via the CUCM prior to getting a VPN address. At this point the device does not have connectivity to the CUCM. However, once he finally does connect to the VPN and gets a new address, the SIP app does not re-initialize the TCP stack and submit a new SIP registration packet. Instead the SIP app continues to use the previous SiP message and he sends it out via the new VPN ip address. The packet eventually makes it to the CUCM (because all rules allow the VPN address) but the encapsulated packet contains a sip registration with an old (non-vpn) address. I wanted to know if the CUCM can see this sip registration and filter the registration based on the sip contact field (If you are not one of these "known addresses" you cannot register)and cause the device to "reset" the sip app and reattempt to connect with a new sip message. My hope is that the sip app on our device will generate a new sip message which will contain the correct IP in the sip contact field. Hope this explains the issue a bit better thanks.
I understand the situation, but the answer is the same. UCM cannot block registration based on the IP address. We can assign the device to a mobile device pool that can eliminate all dialing rights, but we cannot outright block the registration based on IP. Even if UCM could identify the non-VPN IP, there is no directive to 'reset' the device based on an external stimulus.
Technical Marketing Engineer