ICSP -USB scanner unreachable from remote location

Products

• Industrial Control System Protection

Issue/Introduction

Problem Scenario:

1. The administrator of ICSP devices must open a VPN connection to communicate with Neural devices. 
2. The administrator is able to access all of the many ICSP devices on the same network except for one device which is up and running.

Details:

Note: All addresses below are made up but represent the same problem scenario that existed at the problem installation.

1. The device is on an oil drilling rig out in the ocean. 
2. The administrator cannot access the device via web browser.    Results in "page timed out"
3. The administrator cannot ping the address of the ICSP device although the other devices do respond.
4. The problem device has a static address assigned to it that is in the same range, subnet and mask as the other devices that can be accessed.
5. The administrator was able to RDP to another computer that exists on the subnet where the ICSP device resides e.g: (10.31.162.102) wherein he can then open a web browser to communicate with the device. This is not required for the other devices.

The ICMP device configuration is as follows:

Running a trace route (tracert.exe) to the address of the ICSP returns the following results:

Tracert 10.31.162.55  

Note: {The first instance of traceroute in the following screenshot is to the ICSP device from his computer via VPN.  The second instance, in the following screenshot, is traceroute directed to the Windows computer on the same subnet with the ICSP device.}

1. As per the above screenshot-- the attempted requests via trace route to the ICSP device never resolved to an entire route but seemed to die at route 10.61.0.1
2. The same attempt to trace the route to their Windows computer on the same subnet (that was accessed viaRDP) passed through 10.61.0.1 and completed.

Environment

Release : 5.4.x

Component : Default-Sym

Cause

Based on the symptoms and the eventual solution it would seem that somewhere along the way certain routing tables had become corrupted or stale on the device with address 10.61.0.1, to the point that resolving a path to the one address was not possible.

Resolution

1. As a test the address to the device was changed from 10.31.162.55 to 10.31.162.55.
2. After changing the address and waiting for a few moments for the routing tables to propagate the changes, the device was accessible again via VPN. The problem corrected.
3. When the address was changed back to its original address the problem was still resolved. The device was still accessible.

The conventional wisdom is that changing the address to another and then back again caused the device at 10.61.0.1, where the trace route attempts were dying, caused the device to flush/refresh its routing tables and properly function again.