The Network Diagnostics page serves as a basic front-end for common network troubleshooting utilities such as
traceroute. These utilities can be used to confirm the filter's Internet connectivity and network configuration:
The automatic diagnostic tests the filter's configuration, the reachability of various network/Internet hosts, and DNS resolution all at once, providing a simple, human-readable conclusion as to where network problems may lie.
The ping diagnostic tests the reachability and latency between the filter and another host using ICMP (a layer-3 protocol). Pinging a well-known public site like google.com can confirm Internet access or problems with DNS resolution.
The arping diagnostic tests the reachability and latency between the filter and another host using ARP (a layer-2 protocol). This tool is primarily useful for testing the local network; in particular, it can be used to determine if an IP address is currently in use, check for duplicate IPs, or resolve an IP to a MAC address.
The traceroute diagnostic displays the routing paths taken to reach the specified host. It additionally displays the latency to each "hop" along the route. This tool is useful primarily for confirming routing problems (usually caused by an upstream ISP or firewall).
The various dig diagnostics query a host for the specified DNS records.
tcpdump is a more advanced diagnostic which provides a capture of the packets flowing across the filter's network interfaces. For example, by providing the filter expression
port 80 or port 443, one can examine all HTTP traffic going through the filter. The capture file may be opened using an external tool like Wireshark.
lldpctl displays LLDP neighbor data. LLDP is a protocol that allows devices to advertise information about their identity and capabilities (MAC addresses, host names, etc.).
The emergency support tunnel feature establishes a reverse tunnel to Cipafilter technical support, allowing techs to access the filter's console and Web interface securely and without having to re-configure customer-side inbound firewall and port-forwarding rules. This feature is normally initiated manually by the customer, but may also be activated remotely by support personnel, if required.