Tunnels
69
11.1.2.4.3. Authentication and IKE identities
The FireBrick supports three authentication methods:
• Secret: (AKA pre-shared key, or PSK) A secret key is entered in the local configuration and the same key
is set up in the peer's configuration
• Certificate: an X.509 certificate is used (see below for full details)
• EAP: the Extensible Authentication Protocol is used. This is currently only supported for peer authentication.
The auth-method setting specifies how the FireBrick authenticates itself to the peer, and the peer-auth-method
setting specifies how the peer authenticates itself to the FireBrick. Note that the authentication of each peer
to the other is performed independently, and need not use the same method - eg one may authenticate using a
certificate and the other using a pre-shared secret or EAP. Common arrangements are for both to use the per-
shared key method, for both to use certificates or (typically for Road Warrior setups) for one (the server) to
use a certificate and the other to use EAP.
IKE authenticates each end of a connection using the connection's IKE identity. The identity is chosen when
configuring each end, and can be specified in different ways, using the following syntax:
• IP:ip-address : an IPv4 or IPv6 address (eg IP:123.45.67.8)
• FQDN:domain : a dot-separated domain (eg FQDN:firebrick.co.uk)
• EMAIL:email-address : an email address (eg EMAIL:[email protected])
• KEYID:string : any unstructured string (eg KEYID:This is my IKE ID)
DOMAIN or DNS are also accepted as alternatives for FQDN, and MAILADDR, MAIL or RFC822 are
accepted as alternatives for EMAIL.
It is common to use a peer's real IP address as its IKE ID, and to avoid repetition the ID can be specified in
the form "IP:" (ie omitting the IP address) to use the actual IP address. Note that if an IP address is specified
there is no requirement for it to actually be the real IP address - it is used solely for identification. Similarly, if
the FQDN or EMAIL forms of ID are used there is no requirement for the domain or email address to actually
be associated with the peer or even to exist at all.
If the prefix (IP:, FQDN: etc) is omitted in the identity, the FireBrick chooses the most appropriate type, based
on the syntax of the identity used.
During the connection setup phase, these IDs are used to authenticate the two ends to each other. Each peer
passes its ID to the other end of the connection, in an encrypted and signed form. On receiving an ID it is
checked (a) to confirm that it is the expected ID and (b) to confirm that the signature is valid.
If auth-method is Secret, the secret option should be set to the required secret using a free-form text string
of arbitrary length. Note that the usual guidelines when choosing passwords should be followed to reduce the
chance of the secret becoming compromised; a long string is recommended. If peer-auth-method is Secret the
peer-secret option should be set to the secret used by the peer for authentication, or may be left blank in the
common case where the local and peer secrets are the same. If certificate-based authentication is used, the
certlist and peer-certlist options can be used to specify which certificates are to be used, or may be left blank
in which case the the FireBrick looks for any suitable certificate in its certificate store. The use of certificates
is discussed further below. If EAP authentication is used the EAP details (usernames, passwords etc) must be
specified elsewhere in the EAP configuration section of the FireBrick config under the top-level User Access
Control tem. The query-eap-id flag can be set to determine whether the client's IPsec identity should be used
as the EAP identity or the client will provide a separate EAP identity when queried. The default setting is true,
indicating that a separate EAP identity will be requested. Some EAP clients may require this to be set to false.
11.1.2.4.4. IP addresses
The peer-ips item is normally set to the IP of the peer when this is known. It must be a single IP when the
connection mode is Immediate or On-Demand, but for a mode Wait connection this may be left blank or
