Amer Networks E5Web GUI - Manual (Page 598)

negotiations then take place, resulting in the tunnel becoming established to the remote
endpoint.
Local Initiation of Tunnel Establishment
Alternatively, a user on a protected local network might try and access a resource which is
located at the end of an IPsec tunnel. In this case, cOS Core sees that the route for the IP address
of the resource is through a defined IPsec tunnel and establishment of the tunnel is then
initiated from the local Clavister Security Gateway.
IP Rules Control Decrypted Traffic
Note that an established IPsec tunnel does not automatically mean that all the traffic flowing
from the tunnel is trusted. On the contrary, network traffic that has been decrypted will be
checked against the IP rule set. When doing this IP rule set check, the source interface of the
traffic will be the associated IPsec tunnel since tunnels are treated like interfaces in cOS Core.
In addition, a Route or an Access rule may have to be defined for roaming clients in order for cOS
Core to accept specific source IP addresses from the IPsec tunnel.
Returning Traffic
For network traffic going in the opposite direction, back into an IPsec tunnel, a reverse process
takes place. First, the unencrypted traffic is evaluated by the rule set. If a rule and route matches,
cOS Core tries to find an established IPsec tunnel that matches the criteria. If not found, cOS Core
will try to establish a new tunnel to the remote endpoint specified by a matching IPsec tunnel
definition.
No IP Rules Are Needed for the Enclosing IPsec Traffic
With IPsec tunnels, the administrator usually sets up IPsec rules that allow unencrypted traffic to
flow into the tunnel (the tunnel being treated as an cOS Core interface). However, it is normally
not necessary to set up IP rules that explicitly allow the packets that implement IPsec itself.
IKE and ESP packets are, by default, dealt with by the cOS Core's internal IPsec engine and the IP
rule set is not consulted.
This behavior can be changed in the IPsec advanced settings section with the IPsec Before
Rules setting. An example of why this might be done is if there are a high number of IPsec tunnel
connection attempts coming from a particular IP address or group of addresses. This can
degrade the performance of the cOS Core IPsec engine and explicitly dropping such traffic with
an IP rule is an efficient way of preventing it reaching the engine. In other words, IP rules can be
used for complete control over all traffic related to the tunnel.
Dead Peer Detection
Dead Peer Detection (DPD) can optionally be enabled for an IPsec tunnel. DPD monitors the
aliveness of the tunnel by looking for traffic coming from the peer at the other end of the tunnel.
If no message is seen within a length of time (specified by the advanced setting DPD Metric)
then cOS Core sends DPD-R-U-THERE messages to the peer to determine if it is still reachable and
alive.
If the peer does not respond to these messages during a period of time (specified by the
advanced setting DPD Expire Time) then the peer is considered dead and the tunnel is taken
down. cOS Core will then automatically try to re-establish the tunnel after a period of time
(specified by the advanced setting DPD Keep Time).
Chapter 9: VPN
598