Troubleshooting Nebula Devices that have gone offline

It is imperative to make sure that the Nebula devices can reach out to the following Domains, IPs and Ports:
 

Once you have made sure that access to those are allowed, consider checking the following:

1. Cable and Port

In most cases, if there is an issue with the Physical Layer, you would often see CRC errors, Collisions, or even mismatched speed and duplex negotiations. For scenarios like these, you can try switching the cable first and see if the issue occurs. Check the port settings as well on both the Nebula device and the device that it is connecting to.

2. IP address issues

If your device is set to DHCP, check your DHCP server if the device has leased an IP address. If the device does not appear in the DHCP client list, It is advisable to perhaps reboot the device and monitor the logs of your DHCP server if the Nebula device tried to acquire an IP.

If your device has a Static IP, make sure that there are no other devices that have this IP. Check the DHCP server as well if by any chance the IP was leased to another client.

3. Issues with the Layer 2

Check if the device is able to talk to your local gateway. Accessing the diagnostics tool on the unit's Web GUI or through SSH. If access to these are not available, you can also verify if the device is reachable by another device on the same network. Please take note that this will only work if there are no other security settings on Layer 2 are applied such as Port Isolation.

4. Internet access issues

Aside from making sure that the outbound access to the domains and ports are allowed, please make sure that the device can reach your Public Gateway, DNS Servers or anything outside of the internet. Another thing to watch out for is any thing that can manipulate or change the Certificates in the TLS negotiation. Such things can occur when there is a SSL Inspection or Deep Packet Inspection applied by a gateway


Other things to check for:

CPU Usage

If the unit has high CPU usage, this can happen on various scenarios. One of the common scenario is that the device is overloaded due to it serving too many clients. Please consult with a sales engineer to ensure that the model that you are using is able to accommodate the number of clients and the workload that you are expecting.

Another common scenario that could cause a high CPU usage is Broadcast Storms/Multicast Storms. If such things are occurring it is imperative to identify what could be causing this. A Packet Capture on the firewall through it's Diagnostics or a Port Mirror on the Switch level may be needed.

Storms can also occur if there is a loop in the network. If you have setup a Link Aggregation or RSTP, it is best to double check your settings.

If you have a Multicast Server for scenarios like video streaming, make sure that IGMP Snooping is setup correctly. This will help reduce flooding on ports that are not joined in the Multicast Group.

DNS Resolution

If you are using an internal DNS Server and the DNS resolution has failed, check the internal DNS server if it is able to resolve an address from its end. Use the chart above to see if the DNS response that you received matches. If you are not getting an answer, a packet Capture on the firewall through it's Diagnostics or a Port Mirror on the Switch level may be needed. Please take note that if the devices are on the same network, the firewall's Packet Capture function will not be able to capture the DNS communication as the firewall can only capture traffic that goes through its gateway. A port mirroring on the switch level will be more appropriate for this matter.