Device Level AutoKey IKE VPN: Using Gateway Configuration Overview
Creating device-level AutoKey IKE VPNs is a four stage process.
Configure Routes (Route-based only)
Configure VPN on the Device
Add VPN rules to Security Policy
A gateway is an interface on your security device that sends and receives traffic; a remote gateway is an interface on another device that handles traffic for that device. Each security device member has a remote gateway that it sends and receives VPN traffic to and from. To configure a gateway for a VPN member, you need to define the local gateway (the interface on the VPN member that handles VPN traffic) and the remote gateway (the interface on the other VPN member that handles VPN traffic). The interface can be physical or virtual.
For remote gateways that use static IP addresses, specify the IP address or host name of the remote device.
For remote gateways that use dynamic IP addresses, configure an IKE ID for the remote device.
For remote gateways that are RAS users, specify a local user object as a remote gateway to enable RAS user access.
To add a gateway to a security device, open the device configuration, select VPN Settings, and click the Add icon to display the New Gateway dialog box. Configure the gateway as detailed in the following topics.
ScreenOS Devices Gateway Properties
Enter a name for the new gateway, and then specify the following gateway values as described in Table 1:
Table 1: Gateway Properties
The mode determines how Phase 1 negotiations occur.
The remote gateway is the VPN gateway on the receiving VPN node, and can be an interface with a static or dynamic IP address, or local or external user object. From ScreenOS 6.3, Remote Gateway supports IPv6.
Authenticated by EAP
This option provides IKEv2 EAP pass-through. You can enable a ScreenOS 6.1 device to use EAP to authenticate a client with a RADIUS authentication server. The device acts as a proxy (authenticator) and passes the EAP messages between the client (supplicant) and the RADIUS (authentication) server.
During EAP exchanges, the device decapsulates the EAP messages in IKEv2 messages from the peer, encapsulates them into RADIUS messages, and sends them to the RADIUS server. When the RADIUS server responds to the authentication requests, the device decapsulates the EAP messages, encapsulates them into IKEv2 messages, and sends them to the peer. After the RADIUS server has authenticated the client, if there is a shared secret generated during the exchange, the security device extracts the shared secret from the RADIUS Access-Accept message and uses it to generate the AUTH payload. In this way, the device passes the EAP messages between a client and an authentication server.
The outgoing interface (also known as the termination interface) is the interface on the security device that sends and receives VPN traffic. Typically, the outgoing interface is in the untrust zone.
Heartbeats are used to enable redundant gateways. You can use the default or set your own thresholds:
Dead Peer Detection
Dead Peer Detection (DPD) is a protocol used by network devices to verify the current existence and availability of other peer devices. You can use DPD as an alternative to the IKE heartbeat but you cannot use both features simultaneously. You can configure the following DPD parameters:
Because NAT obscures the IP address in some IPsec packet headers, a VPN node cannot receive VPN traffic that passes through an external NAT device. To enable VPN traffic to traverse a NAT device, you can use NAT Traversal (NAT-T) to encapsulate the VPN packets in UDP. If a VPN node with NAT-T enabled detects an external NAT device, it checks every VPN packet to determine if NAT-T is necessary. Because checking every packet impacts VPN performance, you should only use NAT-T for remote users that must connect to the VPN over an external NAT device.
You do not need to enable NAT-T for your internal security device nodes that use NAT; each VPN node knows the correct address translations for VPN traffic and does not need to encapsulate the traffic.
To use NAT-T, enable NAT-T and specify:
The authentication method specified for this proposal. When the user does not specify the authentication method in the proposal, preshared key authentication will be used as the default authentication method. This is in line with the behavior of IKEv2.
In ScreenOS 6.1 or later, NSM allows users to configure IKEv2. The remote gateway type for IKEv2 can be an interface with either a static IP address type or a RAS type.
ScreenOS Devices IKE IDs or XAuth Identification Number
Every VPN member has a unique identification number, known as an IKE ID. During Phase 1 negotiations, the IKE protocol uses the ID to authenticate the VPN member. You must select and configure an ID type for the VPN members at each end of the tunnel. However, the ID type can be different for each member. Table 2 describes the different ID type for each member.
Table 2: IKE IDs/XAuth Types
Abstract Syntax Notation, version 1 is a data representation format that is non-platform specific; Distinguished Name is the name of the computer. Use ASN1-DN to create a group ID that enables multiple RAS users to connect to the VPN tunnel concurrently.
Use a fully qualified domain name when the VPN member uses a dynamic IP address. FQDN is a name that identifies (qualifies) a computer to the DNS protocol using the computer name and the domain name; for example, server1.colorado.mycompany.com.
Use an IP address when the VPN member uses a static IP address.
Use a user fully qualified domain name when the VPN member uses a dynamic IP address (such as a RAS user). A U-FQDN is an e-mail address, such as email@example.com.
Use the default server to use the default XAuthentication server for the device. To change or assign a default XAuthentication server, edit the VPN settings > Defaults > Xauth settings.
Use to specify the authentication server that assigns TCP/IP settings to the remote gateway.
Use when the remote gateway is a RAS user that you want to authenticate.
Use to permit VPN traffic from this VPN member to pass unauthenticated by the Auth server.
Use the XAuth protocol to authenticate RAS users with an authentication token (such as SecureID) and to make TCP/IP settings (IP address, DNS server, and WINS server) for the peer gateway.
Security Methods for ScreenOS Devices
Select the authentication method you want to use in the VPN:
Preshared Key—Use if your VPN includes security devices and/or RAS users. VPN nodes use the preshared key during Phase 1 negotiations to authenticate each other; because each node knows the key in advance, negotiations use fewer messages and are quicker.
To generate a random key, enter a value for the seed, and then click Generate Key. NSM uses the seed value to generate a random key, which is used to authenticate VPN members.
Using a random key can generate a value in excess of 255 characters, which exceeds ScreenOS limits and might not be accepted by the security device during update. To reduce the key size, shorten the autogenerated key value by deleting characters.
To use a predefined value for the key, enter a value for the Preshared Key.
PKI—Use if your VPN includes extranet devices or you require the additional security provided by certificates (PKI uses certificates for VPN member authentication).
For Phase 1 negotiations, select a proposal or proposal set. You can select from predefined or user-defined proposals:
To use a predefined proposal set, select one of the following:
Basic (nopfs-esp-des-sha, nopfs-esp-des-md5)
Compatible (nopfs-esp-3des-sha, nopfs-esp-3des-md5, nopfs-esp-des-sha, nopfs-esp-des-md5)
Standard (gs-esp-3des-sha, gs-esp-aes128-sha)
You cannot use a predefined proposal set with certificates—you must select a user-defined proposal or change the authentication method to Preshared Key.
To use a user-defined proposal, select a single proposal from the list of predefined and custom IKE Phase 1 proposals. For details on custom IKE proposals, see “Configuring IKE Proposals” in the Network and Security Manager Administration Guide.
If your VPN includes only security devices, you can specify one predefined or custom proposal that NSM propagates to all nodes in the VPN. If your VPN includes extranet devices, you should use multiple proposals to increase security and ensure compatibility.
In ScreenOS 6.1 or later, the user can set the following IKEv2 parameters:
Half opened IKE session threshold for triggering stateless cookie exchange.
Initiator sending dummy IPsec packet.
IKE SA softlifetime.