Tunnels
67
11.1.1.6. Identities and the Authentication Mechanism
To fully appreciate the mechanism of authentication, it is necessary to understand the concept of IKE Identities.
Each end of an IPsec/IKE peering has an identity, and the purpose of the IKE authentication process is to
establish the identity to the peer - ie prove to the peer that you are the identity you proclaim to be. An IKE
identity can take one of a variety of forms - it may be an IP address (IPv4 or IPv6), an email address, a domain
name or a key identifier. It is important to understand that these forms are, in a sense, notional - you do not have
to actually be addressable using a particular IP to proclaim it as your identity, nor do you have to be contactable
by an email address if that form is used, nor does a domain name need to be resolvable to your IP address (or,
indeed, resolvable at all). This is not unlike the use of personal names, at least in the UK, where you do not
have to use your official birth certificate name - you can use any name provided that you can prove that you
are associated with that name.
Each end of an IKE connection authenticates itself to its peer by signing a block of data which includes its
identity along with other connection-specific data. Depending on the authentication method, the signature is
generated using a pre-shared secret, a private key associated with an X.509 end-entity certificate, or a key
determined by an EAP exchange.
If a peer authenticates using a pre-shared secret, you trust he is who he says he is simply by virtue of his
knowledge of the secret. With certificates the situation is more complex: a successful signature verification
using a certificate simply proves that the peer has the private key associated with the certificate used. To accept
the authentication you also need to trust the certificate - ie you need to believe that the certificate does indeed
belong to the peer. One way to do this is to use a self-signed end-entity certificate - in this case your peer gives
you a copy of his certificate in advance, and you choose to trust it on this basis. To avoid needing to install a
separate certificate for every peer you may need to authenticate with, it is more normal to have a chain of trust
- you elect to trust a certificate from a certificate authority (CA), and you then implicitly trust any certificates
which have been signed by that authority using that certificate (and in turn any subordinate certificates signed
by these) without needing to explicitly install any of them beforehand. In other words, you are trusting that the
CA (and any intermediates) who issued the certificate checked that the intended owner was entitled to use the
certificate before issuing it. A certificate includes various data items including the identity of the owner, so the
final step in the authentication check using a certificate is to confirm that the certificate used is valid, and its
owner identity matches the IKE identity claimed by the peer.
11.1.2. Setting up IPsec connections
First, an IPsec configuration section needs to be added to the configuration if not already present, or edited if
present. Select "Add: New: IPsec connection settings" or edit the exiting entry on the tunnel setup page.
11.1.2.1. Global IPsec parameters
There are some global parameters affecting all connections which can be set on the main IPsec entry.
The logging options log, log-error, and log-debug can be used to steer logging information which is not specific
to a particular connection to a selected logging target.
The allow and trusted entries can be used to restrict IKE connections to particular IPs and/or IP ranges. An
IKE connection setup request can potentially be received from any device, and setting up a connection involves
some CPU-intensive calculations. The IKE implementation attempts to guard against the possibility of Denial-
of-Service attacks from rogue devices requesting bogus connections by limiting the initial connection rate, but
for added security allow and trusted settings are also provided. Connections from IPs in either of the two lists
are always accepted, and those in the trusted list are processed at higher priority. If an allow list has been set,
connection attempts from IPs not in the allow or trusted lists are not accepted.
There is also a Force-NAT option which will force the FireBrick to assume that remote devices on the list are
behind NAT boxes. IKE has built-in NAT detection so this option is rarely needed. See the separate section
on NAT Traversal for more details.
