RC-E User Manual
Management Client (RC-E Manager)
Enabling Public Access
To enable public access, select the
Network
tab's
Enable public
access box.
Defining Public Address and Port
When public access is enabled, you are able to define the recording server's public address and public port number in
the
Public address
and
Public port
fields respectively.
As public address, use the address of the firewall or NAT router which clients accessing the surveillance system from
the internet must go through in order to reach recording servers.
Specifying a public port number is compulsory; it is always a good idea that port numbers used on the firewall or NAT
router are different from the ones used locally.
When using public access, the firewall or NAT router used must be configured so requests sent to the public address
and port are forwarded to the local address and port of relevant recording servers.
Local IP Ranges
There are cases when the recording server's public address should not be used: When clients connect from the local
network, the surveillance system should reply with local addresses and port numbers. The surveillance system must
therefore be able to determine whether a client belongs on a local IP range or on the internet.
For this purpose, you are able to define a list of IP ranges which the surveillance system should recognize as coming
from a local network. You do this by clicking
Configure...
on the
Network
tab. See Manage Local IP Address Ranges
(on page 171) for more information.
Servers and Clients Require Time-Synchronization
Part of the security surrounding the use of remote clients with RC-E is based on time-based tokens.
Why Servers Require Time-Synchronization
When a client logs in to the surveillance system, the client receives a token from the management server. The token
contains important security-related time information.
The management server also sends a similar token to the required recording server(s). This is partly due to the fact
that recording servers may be located all around the world; each recording server thus uses the token to validate the
client's token against the local time in the recording server's own time zone.
The validity of a token expires after a while. It is therefore important that time on your management server and all of
your organization's recording servers is synchronized (minute and second-wise; hours may of course be different in
different locations around the world). If time on the servers is not synchronized, you may experience that a recording
server is ahead of the management server's time.
When a recording server is ahead of the management server's time, it may result in a client's token expiring on the
recording server earlier than intended by the management server. Under unfortunate circumstances you might even
experience that a recording server claims that a client's token has already expired when it receives it; effectively
preventing the client from viewing recordings from the recording server.
How to synchronize time on your organization's servers depends on your network configuration, internet access, use
of domain controllers, etc. Often, servers on a domain are already time-synchronized against the domain controller. If
so, you should be fine as long as all required servers belong to the domain in question.
If your servers are not already time-synchronized, it will be necessary to synchronize the servers' time against a time
server, preferably the same time server.
On-Net Surveillance Systems, Inc.
73
