IPSec Virtual Private Networks

  

Figure 4.59: The IPSec VPNs Setup Screen

The IPSec VPNs Setup Screen (Figure 4.59) lets you choose whether you want to configure static SAs (security associations) for IPSec tunnels, or, if you want to use Internet Key Exchange (IKE), you can configure either tunnel-mode VPNs (gateway-to-gateway) or transport-mode VPNs (host-to-gateway).

It is beyond the scope of this manual to describe the details of VPNs and IPSec. The reader who requires more background material is referred to the excellent IBM redbook on this topic, which is available online at http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg245201.pdf.

Most IPSec software these days supports IKE, which is easier to configure than static SAs, so you will almost certainly want to use this option. You would configure tunnels if you wanted encryption between firewalls and/or gateways, and wanted to allow hosts behind the firewalls and/or gateways to communicate securely over the non-private network connecting the firewalls or gateways. This requires you to know the IP addresses of the relevant firewalls, gateways, and networks. Alternatively, if you have roaming hosts that have dynamic IP addresses assigned to them, you can still have encrypted connections between such hosts and any TCP proxies that you have configured that are accessible on the external interface of your firewall, by configuring transport-mode IPSec policies. Unlike tunnel-mode, which secures communications between routers, gateways or firewalls, transport-mode is for end-to-end host security.

  

Figure 4.60: The IPSec Host Pairs Setup Screen

If the remote gateway, firewall or router does not support IKE, you will need to set up statically configured Security Associations, which you do in the IPSec Host Pairs Setup Screen (Figure 4.60).

Packets received on the inside that match an IPSec address pair will be encrypted and encapsulated using IPSec. For hosts on the public network that are connecting to the internal network, you should specify 32 bits for the remote address, and use the same address for the remote host and the remote gateway; for CEQURUX-to-CEQURUX IPSec, you can specify any number of bits, and should specify the remote firewall as the remote gateway.

You also need to specify the incoming and outgoing encryption and authentication algorithms and keys, and the Security Parameter Indices (SPIs) for incoming and outgoing access. The keys should be either text strings in single quotes, or unquoted strings of hexadecimal digits. The lengths of the keys are also important; Figure 4.61 summarises the allowed ranges.

  

Figure 4.61: Allowed Key Length Ranges (Hex or Character String Mode).

For the IPSec connections to work, the remote side must be configured in a symmetrical fashion, with incoming entries matching the other side's outgoing entries and vice-versa.

  

Figure 4.62: The IKE Transport Mode Key Setup Screen

If the remote host that you wish to use IPsec with supports the Internet Key Exchange protocol (IKE; formerly known as ISAKMP/Oakley), then you can use this to establish security associations. The configuration in this case is much simpler than for static SAs.

Transport mode (host-to-host) IPsec and IKE are configured from the IKE Transport Mode Key Setup Screen (Figure 4.62). The fields in this screen are:

FQDN

The `fully-qualified domain name' of the remote host. This does not actually need to be the FQDN of the host, but should be some string which the remote host uses as its FQDN in its IPsec setup. When then remote host connects to the firewall, it will send the FQDN identity string, which the firewall will use to determine which shared secret key to expect. In turn, the remote host should specify the IP address of the firewall as the remote identifier for use in IKE phase 1 negotiation.

Protocols

Whether to use the AH (authentication header) protocol for data integrity, and/or the ESP (encapsulating security payload) protocol for data confidentiality.

Authentication Algorithm

The algorithm to use for data integrity.

Encryption Algorithm

The algorithm to use for data confidentiality.

Group

The Diffie-Hellman group to use for session key establishment during the phase 1 negotiations.

Phase 1 Lifetime (secs)

The lifetime of the phase 1 session keys in seconds.

Phase 1 Lifetime (KBytes)

The lifetime of the phase 1 session keys in kilobytes of traffic transferred.

Phase 2 Lifetime (secs)

The lifetime of the phase 2 encryption keys in seconds.

Phase 2 Lifetime (KBytes)

The lifetime of the phase 2 encryption keys in kilobytes of traffic transferred.

Shared Secret

The shared secret that must be supplied by the remote. The shared secret and FQDN together uniquely identify a remote host (or a set of hosts sharing a common identity). The shared secret should not contain any whitespace.

The following limitations apply:

• IPsec transport mode works only with TCP proxies attached to the outside interface of the firewall. The relevant TCP ports must be configured with the `IPsec Only' flag in the TCP Proxy Setup Screen.

• TCP ports used for IPsec transport mode cannot also be used for non-IPsec connections.

• Services that use more than one port (such as FTP) do not work with IPsec transport mode.

• The protocol must be ESP. AH or both AH+ESP do not work.

• The same authentication and encryption algorithms are used for both phase 1 and phase 2. The Diffie-Hellman group is used only in phase 1.

• If there is more than one IPsec transport mode configuration entry, then they may differ only in the FQDN identifier and shared secrets. They must all use the same algorithms and lifetimes.

• In IKE phase 1, the client uses the firewall's external IP address as an identifier, while the firewall uses the client's FQDN as an identifier. Both the firewall and the client must use the same shared secret.

  

Figure 4.63: The IKE Tunnel Mode Key Setup Screen

Tunnel mode (gateway-to-gateway) IPSec and IKE are configured from the IKE Tunnel Mode Key Setup Screen (Figure 4.63). The fields in this screen are the same as for transport mode, except that there are a few additional fields, namely:

Local Network

The local network behind this firewall or VPN gateway. Traffic from this network destined for the remote network will be tunneled through the IPSec-secured connection.

Bits

The number of bits in the local network bitmask.

Remote Gateway

The IP address of the remote IPSec gateway, router or firewall.

Remote Network

The remote network on the far side of the remote IPSec gateway, router or firewall. Traffic from the local network destined for this remote network will be tunneled through the IPSec-secured connection.

Bits

The number of bits in the remote network bitmask.

Level

This can be set to `Use' or `Require'. If set to `Use', then traffic will be sent via IPSec if IKE negotiation has already occured, but in the clear otherwise (put another way, your firewall will never initiate IKE, but will respond to IKE if initiated by the remote). If set to `Require', then the traffic will never be sent in the clear. Instead, the arrival of traffic on the internal interface destined for the remote network will cause the firewall to initiate IKE negotiation with the remote if this hasn't been done already.

Unless you always want the remote to initiate IKE, you should normally set this to `Require'.

Also, the FQDN field is not present. The IKE tunnels use the IP addresses to identify each other and determine which pre-shared key should be used. The remote host must thus be configured to use IP addresses as identities for tunnel mode, as opposed to FQDN for transport mode.