Sentry administrators may find that the Sentry WebAdmin and CLI (via SSH) interfaces for their appliances are not accessible. At the same time, the CLI comes up when connected via serial console (physical connection) to the appliance. Rebooting the device may resolve the issue temporarily.
This problem may appear as a hardware issue because it is intermittent and a manual reboot resolves the issue.
Incorrect network settings in Sentry can cause the device to be unreachable across the network. There are 2 common Sentry network configuration issues that can lead to the system being unreachable across the network.
1. A network loop which may intermittently make the device inaccessible via SSH or WebAdmin due to bad ARP caches.
The issue clears after a restart because rebooting the server clears the ARP cache table, and then the correct interface is then added to the ARP table. However, a remote system could cause this at any time by accessing the Sentry from the wrong interface thereby caching the bad ARP entry.
2. The MGMT and WAN IP Addresses are in the same subnet, with the MGMT Filter enabled. Forum Systems recommends using different subnets for the MGMT and WAN interfaces. However, it is possible to have both in the same subnet if the MGMT filter is disabled. The MGMT Filter is designed to segment the 2 interfaces. If they are both in the same subnet, Sentry can use either to send and/or receive data for the WebAdmin and CLI.
Troubleshooting and Resolution
1. Access the CLI via Serial port (physical connection) - To diagnose the issue, whenever the WebAdmin and CLI interfaces are unreachable, it is important to try to access the ForumOS CLI via the serial port on the device while the problem is occurring.
If the CLI comes up via serial and the device appears to be functioning normally, the problem is likely an issue with the network settings or the network path between the admin's browser and the device.
2. Diagnosing and resolving a network loop. Use the following CLI commands to check the network settings (note that you can also view the network settings via the WebAdmin interface if you have access):
To diagnose the network loop check the routes for conflicts. A conflict is two routes pointing to different interfaces for the same network segment.
For example, eth1 is using:
10.127.140.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
but there is a network route pointing to eth2 as well for the same segment
10.127.0.0 10.126.0.254 255.255.0.0 UG 0 0 0 eth2
To resolve the problem, remove the route that is in conflict.
3. Check the MGMT Filter - if the MGMT and WAN IPs are in the same subnet, disable the MGMT Filter with the CLI command "network config mgmt-filter" or through the WebAdmin interface on the System>>Settings>>Network page.
Note that if the MGMT and WAN interfaces are in different subnets, a single client system should not be able to reach both interfaces. If this is possible, there is a loop somewhere in the environment.