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

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

Tunnels
72
both AH and ESP protection to encapsulated packets; AH authentication with ESP encryption can provide
marginally better authentication but is rarely used. To configure this, set up a manually-keyed ESP tunnel with
just encryption, and set up a separate manually-keyed AH IPsec entry in transport mode. Each must have their
own separate SPIs, and the ESP entry should have the outer-spi field set to the local-spi of the AH entry. The
AH entry should have no IPs, routing, graph or speed set.
11.1.2.5.5. Other parameters
Other IPsec manually-keyed parameters have the same meaning as their IKE counterparts.
11.1.3. Using EAP with IPsec/IKE
EAP is typically used in conjunction with certificates to authenticate a Road Warrior connection. The FireBrick
can act as a Road Warrior server, and uses EAP methods to authenticate the clients. During the authentication
process the client sends a user identity (typically a username) and an encoded password to the FireBrick, and the
FireBrick checks the username/password combination is valid. The FireBrick would normally be configured
to use a certificate to authenticate itself to the client. A single Road Warrior ike connection item can support
multiple clients connecting at the same time; each client will be dynamically allocated a different IP address.
Each user should be given a separate EAP username/password entry.
EAP usernames and passwords are configured under the top-level User Access Control section of the config.
Select Users icon on the config web edit page, and enter the required details under the section User access
control via EAP. Currently two EAP methods are supported - MD5 and MSChapV2; at least one of these is
normally supported by Road Warrior clients. Note that MSChapV2 is more secure than MD5, and is the most
commonly used, though it is rather an arcane method with known weaknesses. The subsystem item in the EAP
config should be set to IPsec.
Note
The EAP authentication process involves a number of interchanges between the client and server.
These take place using the IKE control channel, so although at this stage the server does not yet know
the identity of the client connecting (indeed it is purpose of the EAP interchange to achieve this), the
path to the client is secure and encrypted so a third party cannot snoop on the authentication.
11.1.4. Using certificates with IPsec/IKE
The FireBrick IPsec/IKE implementation supports authentication of tunnel endpoints using X.509 certificates.
The FireBrick may authenticate itself to its peer using a certificate and private key installed on the FireBrick,
and similarly the peer may authenticate itself to the FireBrick using a certificate trusted by the FireBrick.
The FireBrick has an internal secure storage area for holding certificates and private keys. This is held separately
from the main FireBrick configuration, and is managed through the UI by selecting the Certificates section in
the Config menu. Certificates may be uploaded to the FireBrick, downloaded and deleted, and private keys
may be uploaded and deleted. Note that, for security, it is not possible to download a private key once installed;
the only use to which a private key can be put is to allow an end-entity certificate to sign data - in particular
the IPsec/IKE authentication data payloads.
When a certificate is installed on the FireBrick, a short local name must be chosen to accompany it. This name
appears in the certificate store contents list but need bear no relation to the actual certificate identity. The local
names are displayed on the UI certificate configuration page, and are also used to form the filename (with .pem
or .crt appended) when downloading the certificate from the FireBrick. The local names can also be used if
desired in the IKE connection certlist and peer-certlist items to select the certificates to be used for a specific
connection.
As the FireBrick does not yet support secure (https) web connections, uploading a private key should only be
done from a locally-connected device where the security of the connection can be guaranteed - ideally using
a direct ethernet cable or possibly a secure encrypted WiFi link - as the key data is transmitted in the clear.