IP address ranges for smartreceiver.cisco.com

[Daniel-nl]

Hi colleagues,

my IOS-XE Routing and Switching devices configured for "Smart Licensing Using policy" communicate directly with CSSM, which is smartreceiver.cisco.com.

As I'm securing my devices with an Infrastructure ACL, I'm wondering if there is any documentation which IP addresses and ports from CSSM have to communicate with my devices, as I was not able to find any.

From different ping checks and packet captures, I was able to see the following Cisco IPs with port 443 incoming:

72.163.10.105
173.37.149.105
64.101.38.11

Are these the only 3 IPs which have to communicate with my devices? Or are there others as well? Any public documentation about this?

Thanks for your help in advance.

[balaji.bandi]

CSSM  - is this onpremises VM  you have ?

Smart License use like any other https services, the activation service will be contacting always their Loadbalance and redirecting to based on the location or region some time ( as per i know)

Since this outgoing only to register with smartnet portal for License.

here is the process :

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-9500-series-switches/214484-cisco-smart-licensing-troubleshooting.html

[Daniel-nl]

Hello Balaji,

no, as I mentioned my devices are connecting directly to the Cisco Cloud, which is https://smartreceiver.cisco.com/licservice/license. There is no on-premise VM.

"SL Using Policy" needs to push license reports to the Cisco Cloud, and needs to receive push ACKs as well. The question is, which IPs do I have to permit in my iACL to receive this push ACKs and not discard them?

[Georg Pauwen]

Hello,

in addition to the IP addresses you have already captured, according the Cisco Live presentation linked below (page 18), CSSM uses these DNS names and ports:

Authorized Backends

Cisco Smart Software Manager (CSSM) (cisco.com)
HTTPS: tools.cisco.com (Port 443)
HTTP: www.cisco.com (Port 80) (Cert Downloads)

Satellite

User Interface: HTTPS (Port 8443)
Products: HTTPS (Port 443), HTTP (Port 80)
CSSM: HTTPS (tools.cisco.com, api.cisco.com, cloudsso.cisco.com)

These names resolve to the following IP addresses:

cloudsso.cisco.com 72.163.4.74
cloudsso2.cisco.com 173.37.144.211
cloudsso3.cisco.com 173.38.127.38
tools.cisco.com 72.163.4.38
api.cisco.com 173.37.145.221

cisco.com 72.163.4.185 --> this might be different depending on which country you are in

https://www.ciscolive.com/c/dam/r/ciscolive/latam/docs/2018/pdf/BRKARC-2034.pdf

So I guess if you keep the three ports (80,443,8443) open for these IP addresses, Smart Licensing should be able to communicate with the CSSM server(s).

[Daniel-nl]

Hello Georg,

thanks for your reply. Unfortunately this is only applicable to legacy "Smart Licensing", not to "Smart Licensing Using Policy". "SLUP" uses
"smartreceiver.cisco.com" instead of "tools.cisco.com", and it seems that "Smart Licensing Using Policy" uses different IP addresses to communicate.

It is a bit weird that there is (almost) no public documentation from Cisco regarding this, as so many devices need to communicate to the Cisco cloud. For now it seems fine if I permit the whole supernets from Cisco (72.163.0.0/16, 173.36.0.0/14, 64.101.0.0/17) Port 443 incoming. But there should be something official and public about this important topic (I hope that I'm not the only one with iACLs deployed).

[Georg Pauwen]

Hello,

odd indeed that there is hardly any public information to be found. I can imagine, though, that Cisco is reluctant to publish these IP addresses, as they can be used for DDOS attacks, or some other exploits.

cae-xprp-rcdn-vip.cisco.com [72.163.10.105]
cae-xprp-alln-vip.cisco.com [173.37.149.105]
cae-xprp-rtp-vip.cisco.com [64.101.38.11]

I guess if you allow the supernets, that is the most you can do.

[balaji.bandi]

i done some random lookup they always resolve as per your results :

72.163.10.105
173.37.149.105
64.101.38.11

[Daniel-nl]

Thanks guys for your replies.

[Georg Pauwen]

Hello,

just out of curiosity, what sites/IP addresses do you want to allow/block ? The public Internet is huge, I haven't found a comprehensive ACL example yet that blocks proven malicious external sites.

[Daniel-nl]

Hello Georg,

the iACL is used as a Control Plane Protection, it is not about blocking specific websites. It is just a whitelist to permit specific IPs TO the device (like NTP server, specific management subnets, specific BGP neighbors, ...) and drop everything else TO the device. And then permit all transit traffic afterwards.

[balaji.bandi]

Until there is an inttellegent device grab the IP address from RBL or any other source of IP Block lists, its hard to get work to be done.

that is the reason if the device behind proxy or any other content filter you can easy to allow or deny. (just thought)

[Cesare]

Be aware for a new IP: 192.133.220.90

I opened a case with Cisco to ask if any static IP is available, but the answer was no.

[Daniel-nl]

Thank you for the hint. It is really unbelievable that Cisco is not providing any documentation for the used public IPs.

[Nuno Melo]

Sadly this issue is still relevant in 2023

However there is workaround if you are using a ios x.e device:

1 - create an object-group i.e

     object-group network URL_DNS_HOSTS
2 - create an eem script to update the object group regularly

   event manager applet URL_DNS_UPDATE authorization bypass
   event timer watchdog time 250
   action 0.1 cli command "enable"
   action 0.2 cli command "conf t"
   action 2.1 cli command "object-group network URL_DNS_HOSTS"
   action 2.3 cli command "host smartreceiver.cisco.com"

   action 2.4 syslog priority informational msg "DNS object-group has been updated via EEM"

3 - Apply the object-group to an acl that is applied on the internet facing device interface

The object group will update the host ips of smartreciever since the object group is added to an ACL, the ACL will update regularly with any new ip

72.163.15.137
192.133.220.120
173.36.127.32

AFIK, there are only 3 valid ip's for the smartreceiver.cisco.com, regardless this method will automatically update if any new one appears.

Its incredible that in 2023 the IOS X.E ACL still cannot handle dns names, and instead just resolves the url into  the 1st ip it resolves, this might have been acceptable 20years ago but now its just strange how this never got improved.