sdgtw v.2.00 probe not connecting to SNOW
Document ID : KB000125332
Last Modified Date : 26/01/2019
 Show Technical Document Details
Issue:
sdgtw probe which was previously working would no longer connect to SNOW.
No environment changes known.

According to customer, no firewall was blocking the connection from the specific Primary hub/source machine to SN but the connection failed with the MDR error despite restart/cold start, reinstall, or robot restart. 

Jan 25 21:20:11:654 [Thread-53, sdgtw] Exception in making the connection to MDR:java.lang.NullPointerException 
at com.nimsoft.probe.gateway.sdgtw.SDGtwProbe.initiateAlarmSynchronizer(SDGtwProbe.java:270) 
at com.nimsoft.probe.gateway.sdgtw.SDGtwProbe.initializeAndConfigureNim(SDGtwProbe.java:170) 
at com.nimsoft.probe.gateway.sdgtw.SDGtwProbe.access$000(SDGtwProbe.java:68) 
at com.nimsoft.probe.gateway.sdgtw.SDGtwProbe$1.run(SDGtwProbe.java:130) 
at java.lang.Thread.run(Unknown Source) 

sdgtw Nim.log showed:
[26/01/19 02:20:13:013 MST] [qtp53485142-31] ERROR common.GenericSOAPDispatchService: com.sun.xml.ws.client.ClientTransportException thrown in Invoke With Retry: Exception Message: 'HTTP transport error: java.net.ConnectException: Connection refused: connect': attempting call #2 
[26/01/19 02:20:19:019 MST] [qtp53485142-31] ERROR common.GenericSOAPDispatchService: Type of exception thrown in Invoke Try: 'com.sun.xml.ws.client.ClientTransportException': Unknown problem occurred with message: 'HTTP transport error: java.net.ConnectException: Connection refused: connect' 
[26/01/19 02:20:19:019 MST] [qtp53485142-31] ERROR common.GenericSOAPDispatchService: WebserviceException thrown in Invoke With Retry: Exhausted all retries with exception message 'HTTP transport error: java.net.ConnectException: Connection refused: connect'
Environment:
-UIM v8.5.1
- sdgtw 2.0
Cause:
- Change in Security policy (the previous evening) impacted connectivity
Resolution:
-Observe if your specific REST URL referenced in the above document (last step) is working or not? Please check with SDM team. 
-Once it IS successful, go to probe configuration, verify the credentials again and SAVE it.
-Deactivate and activate once before you validate the credentials. 
-Confirm no firewall is blocking the connection. 

As it turned out, as per the Network team, a Security change was implemented the night before for an entire subnet group and this primary hub (where the sdgtw is installed was impacted by that change). The new Security policy was set to not allow any traffic previously sent over MPLS, from port 80/443, through the proxy unless it was specifically allowed. 

We were told by the Network team that we could try using the proxy so they supplied the proxy settings but the Primary hub could not get TO/through the proxy until the GPO was modified and the Lan settings were changed. After that we were able to verify the SNOW server login page loaded.

Since the policy change now demanded that all http/https traffic be sent through the proxy, we had to configure the sdgtw proxy settings so we tried various combinations working with the customer but to no avail.

Notes:

URL: https://abc.service-now.com 
username: <in our scenario this was required> 
password: <also required> 
Client URL: <https://server.service-now.com> 
Proxy Server: <yourproxy.hosting.net> 
Proxy Port: 8080 
Proxy User: <your_service_user_name> 
Proxy Password: <proxy_password> 
Proxy Protocol: http OR https, but in our case although we were told the proxy doesnt require https connection, it had to be set to https for it to connect.

sdgtw proxy configuration example

sdgtw connection proxy configuration was NOT needed until the security policy change was performed last night.

An internal resource stated the proxy doesn't support https and that we didn't need a username and password for the proxy and various combinations did not work after testing, but after adding a username and password as well as setting the protocol to https, we were able to connect. 

 
Additional Information:
Suggest that the Nim.log MDR Exception error -> when the connection is refused, contain some reference/pointer to options for resolving connection issues like this just in case other customers do similar changes that require proxy configuration to be added to the sdgtw config.