FireBrick FB6402, Руководство пользователя

Страница: 85 / 196

Tunnels
68
11.1.2.2. IKE proposals
When IKE connections are negotiated, a selection of compatible algorithms and keys for integrity checking
and encryption are negotiated. The initiating end of the connection provides proposals of various combinations
of algorithms it is willing to use, and the responding end picks a suitable set. The IKE implementation has
built-in default proposal lists, which are suitable for normal use, but for tighter control further proposals can be
configured. An IPsec IKE connection consists of two separate communication paths - the IKE control security
association, and the IPsec data connection, and these have separate proposals, which are configured using the
Proposal for IKE security association and Proposal for IPsec AH/ESP security association sections. See the
later discussion on algorithms for further details.
11.1.2.3. IKE roaming IP pools
IKE Road Warrior connections provide the ability for users to set up a VPN for remote access to a network.
When a client connects an IPv4 and/or IPv6 address and other network data are allocated and communicated
to the client for the duration of the connection. The details are configured in a roaming pool section, which
can be referenced from one or more IKE connection sections. The pool of IPv4 and/or IPv6 address ranges for
allocation needs to be configured here, and optionally a list of addresses of DNS and/or Windows NetBios name
servers (NBNS) can be configured. If the IP address(es) to be assigned are not fully addressable on the internet,
and the client is to be given internet access in addition to access to the local server network, the nat option can
be given to make the FireBrick perform network address translation on sessions initiated by the client.
Note that there is a restriction on the total number of IPs (both IPv4 and IPv6 combined) of approximately
65536 addresses - ie a single IPv4 range of /16, or a single IPv6 range of /112.
11.1.2.4. IKE connections
To set up a new IKE connection, select "Add: New: IKE connections" on the IPsec configuration page.
There are a large number of options available for configuring a connection, but the majority can usually be
left at their default settings.
11.1.2.4.1. IKE connection mode and type
Three connection modes are currently supported: Wait provides a dormant connection, which will only be set
up when the remote peer initiates the connection; Immediate provides a connection which the local FireBrick
attempts to initiate immediately; On-demand provides a connection which is only set up when the local
FireBrick detects that it has traffic to send over the tunnel.
A Wait-mode connection is useful when the remote IP is not known - for example when it may change if the
remote device moves to a different network or is behind a NAT device. Road Warrior connections must be Wait-
mode; other connections may use any mode. It is permissible (and common) to set both ends to Immediate-
mode - IKE will happily allow the connection to be initiated by either end, and will close a duplicate connection
if set up simultaneously by both ends.
The IKE connection type is AH or ESP. ESP is by far the most commonly used, as it provides both integrity
checking and encryption of traffic. AH provides integrity cheecking only, so data is transmitted in plaintext.
AH does provide a very slight extra level of security, as the IP addresses of the tunnel encapsulation packets
are also integrity checked. However, this is (a) incompatible with usage over NAT and (b) rather illusory, as
with IKE the whole connection is authenticated at setup, so the remote peer is already known to be valid.
11.1.2.4.2. IKE and IPsec proposal lists
Algorithms and proposals are discussed in more detail below. Normally, these can be left blank causing the
default proposals to be used. If required, the IKE proposal list and/or the IPsec proposal list can configured. Each
consists of a list of names of proposals which have been configured under the top IPsec configuration section.