Service Mapping connection discovery fails for targets with multiple IP addresses

[J_rg Matz]

In our setup, the mid server is located in an admin network, that can reach any server via its admin interface. The configuration files for applications usually use the public interface for communications. The public network and admin network are separated, so the admin server cannot reach the public interfaces of the targets.

Both public and admin IP address for the servers are discovered by horizontal discovery. Is there a way to "re-map" the public IP to the Admin IP of the same server before continuing the discovery of the connections.

Example is a SAP CI application linked to a HANA database via the public IP 10.1.2.3, whereas the admin address of the HANA DB server might be 100.4.5.6. Pinging 10.1.2.3 fails from MID-Server, but pinging 100.4.5.6 works. Connection via 100.4.5.6 may allow Mid-Server to gather the necessary information.

[Appli · Accepted solution]

Hi, may be network team can grant access to public IP addresses of concerned CIs? it might be a most straight forward solution.

[Appli]

Hi, thank you for clarification! May be instead of using the public interface for communications (apparently this is a security concern), applications can use an internal one. And instead of IP addresses defined in application configuration files, have DNS names defined there - it will allow changing IPs on DNS level.

[J_rg Matz]

Dear @Appli ,
thanks again for your suggestions. I'm aware of the changes that could be done to accommodate the service discovery. But the delivery organization is reluctant to modify the existing configurations just for the ITOM toolset. There are security and other concerns that target on strict separation between admin network and application network. 
DNS setup is of course used, but always pointing the the public network, not the admin network.
This is strictly used for administrative access. so the same server also has two different names, one used for admin access, and one for "normal" application operations. And the configurations use the "normal" application related name.

I think the question is of a more general manner. Can I - and if yes how - use a kind of admin address to do top-down discovery.

[Sergey12 · Accepted solution]

Hi, thank you for your clarification and detailed feedback! Well, I still believe an approach, where traffic from MID server to public IPs whitelisted on firewall/router level, is a solution here. Network team should be less concerned since Allow rule will have strictly defined src ip (= ip of MID server in Admin zone) and traffic will be routed over loopback interface or so. Not sure if OOTB functionality of ServiceNow ITOM can address the use case you explained, for me it is not.

[J_rg Matz]

@Sergey12, thank you for your reply. I'm afraid this way service discovery will not be usable in our environment. As I explained, it's not only network access to the correct IP, but also SSH restrictions to the admin network. So Top-down discovery would not be able to establish the necessary ssh connection to the public IP, even if the network route is opened. I need to check with our company security team, what we can do here.
Thanks to everyone for your suggestions.

[J_rg Matz]

Just to keep you up to date on the progress.
The limitation we have seen were due to limits imposed in our development MID server. It does not have the complete network access. We moved the discovery to out TEST environment now. Here the MID server has much broader network access. So discovery works much better.

We still have to enable some SUDO commands on the servers, but this is handled by a template and will not be a big issue.

Thank you to everyone for your support and suggestions.