
Tunnels
76
connection is used, AH is incompatible with NAT. A NAT device usually requires regular traffic to ensure
dynamic address and port mappings are maintained. Additionally, some NAT devices incorrectly attempt to
modify IPsec traffic en route. IKE attempts to work around these problems, by detecting whether there are any
NAT devices in the transmission path, and modifying its behaviour accordingly. IKE ESP traffic is encapsulated
in UDP packets using port numbers which faulty NAT devices should not treat specially, and keepalive packets
are sent. Additionally, IKE will notice if a peer behind a NAT suddenly changes its IP address (as would happen
eg if a NAT device was rebooted and lost its NAT mappings). This mechanism, known as NAT Traversal,
is normally automatic if it is supported by the IKE implementations at both ends of the connection. There
is a global IKE option force-NAT which can be used to specify IP ranges which should be assumed to have
intervening NAT which can be used when the remote peer does not support NAT Traversal.
11.1.7. Configuring a Road Warrior server
A Road Warrior server connection provides the ability for a number of remote clients to set up VPNs to
the server dynamically. When each client connects, it is allocated its own IP addresses (IPv4 and/or IPv6)
from a pool maintained by the server. Most Road Warrior clients expect the server to authenticate itself
using a certificate, and authenticate themselves with a username/password using EAP. Note that the FireBrick
connection can be configured as a Road Warrior server, but not as a Road Warrior client.
There are a number of considerations when configuring a connection as a Road Warrior server The following
assumes the common certEAP authentication setup:
• local-ID: The connection local-ID should be set to a suitable identification for the server. Clients may need
to be configured with this name. It is recommended that the FQDN: form of ID is used, and the domain name
of the FireBrick is an obvious choice here (though not mandatory).
• peer-ID: Leave this unset in order to allow connections from any client.
• Certificates: An end-entity certificate identifying the FireBrick should be created, along with its private
key, and signed with a suitable CA certificate, as described earlier. Both certificates and the private key are
installed on the FireBrick, and the CA certificate should be installed on any clients wishing to connect. The
end-entity certificate should have a SubjectAltName setting maching the local-ID chosen above.
• IP pool: A roaming pool should be configured for use by the connection, and included in the connection
roaming-pool setting. Consideration should be given when choosing the IP addresses to ensure they do not
clash with other uses of the same address range, and to ensure external traffic destined for these addresses
will get routed to the FireBrick so it can be sent over the VPN. One of three methods is typically used:
• Use a range in private address space - eg 10.42.42.1-100. As these are not internet-routable, if the clients
require internet access through the VPN, incoming sessions from the client should be NATed by the
FireBrick. Set the nat option in the roaming pool to achieve this.
• Use a portion of a subnet already routed to the FireBrick (eg by your service provider) but not currently
in use.
• Use a portion of a LAN subnet. Care is needed with this approach; the range chosen must not clash with
the addresses of any devices in use on the LAN - in particular ensure the range will not be allocated by
a DHCP server. Additionally, if devices on the LAN need to communicate with the remote clients, the
proxy-arp option should be set on the LAN interface/subnet config so that the FireBrick will announce
itself on the LAN for the client addresses. This method has the advantage that the remote clients will act as
if they are LAN-connected devices, so routing/firewalling etc already set up for the LAN will also apply
to the clients.
Addresses of DNS servers and optionally NBNS servers which the clients should use should also be
configured in the roaming pool.
• Authentication: Set the auth-method to certificate and the peer-auth-method to EAP.
• Users and Passwords: Set up user/password entries under the EAP section in the top-level User Access
Control section of the FireBrick config.
Содержание FB6402
Страница 1: ...FireBrick FB6402 User Manual FB6000 Versatile Network Appliance...
Страница 2: ......