Fortinet FortiRecorder 400D, Administration Manual

Page: 133 / 169

Troubleshooting Page 133 FortiRecorder 2.4.2 Administration Guide
You may need to verify that there are no misconfigured DNS records, and otherwise rule out
problems at the physical, network, and transport layer.
If these tests succeed , a route exists, but you cannot receive video feeds or use
FortiRecorder to update the camera’s network settings, an application-layer problem is
preventing connectivity.
4. For application-layer problems, on the FortiRecorder, examine the:
• camera network settings (these may have become out-of-sync if you modified them while
the camera was disabled)
• certificates (if connecting via HTTPS)
On routers and firewalls between the host and the FortiRecorder appliance, verify that they
permit HTTP, HTTPS, and RTP connectivity between them.
Relatedly, if the computer’s DNS query cannot resolve the host name, output similar to the
following appears:
example.lab: Name or service not known
Cannot handle "host" cmdline arg `example.lab' on position 1 (argc 1)
See also
• NVR configuration
Facilitating discovery
Discovery of the cameras by the FortiRecorder NVR uses mDNS. For it to work, cameras
usually must be on the same IP subnet as the NVR, and must not be impeded by firewalls or
other network filtering. If cameras are
not on the same subnet, you may still be able to facilitate
discovery traffic by configuring your FortiGate or other device with multicast forwarding.
If you do not know which device is impeding discovery, you can either:
• Temporarily attach the cameras to a closer point on the network, such as a local switch or
directly to the FortiRecorder NVR, so that discovery is not blocked.
• Manually add the camera to the FortiRecorder NVR’s list of known cameras, skipping
discovery.
DHCP issues
The FortiRecorder appliance has a built-in DHCP server. By default, it is disabled.
If you enable it and your network has another DHCP server (e.g. your ISP’s cable modem, a
router, or a Windows or Linux server), verify that:
• both are not serving requests on the same network segment (which could create a race
condition)
• both are not using the same pool of IP addresses (which could lead to IP address conflicts
— see “Resolving IP address conflicts” )
To verify that your appliance and cameras are sending and receiving lease requests, you can
perform a packet trace (see
“Packet capture” ) and/or use the event log to look for:
•
DHCPDISCOVER
(destination IP is broadcast, not FortiRecorder’s)
•
DHCPOFFER
•
DHCPREQUEST
•
DHCPACK