Device Level AutoKey IKE VPN: Using Gateway Configuration Overview

Creating device-level AutoKey IKE VPNs is a four stage process.

Configure Gateway
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 53:

Table 53: Gateway Properties

Gateway Options	Description
Mode	The mode determines how Phase 1 negotiations occur. In Main mode, the IKE identity of each node is protected. Each node sends three two-way messages (six messages total); the first two messages negotiate encryption and authentication algorithms that protect subsequent messages, including the IKE identity exchange between the nodes. Depending on the speed of your network connection and the encryption and authentication algorithms you use, main mode negotiations can take a long time to complete. Use Main mode when security is more important. In Aggressive mode, the IKE identity of each node is not protected. The initiating node sends two messages and the receiving node sends one (three messages total); all messages are sent in the clear, including the IKE identity exchange between the nodes. Because Aggressive mode is typically faster but less secure than Main mode, use Aggressive mode when speed is more important than security. However, you must use Aggressive mode for VPNs that include RAS users.
Remote Gateway	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. Static IP Address—For remote gateways that use a static IP address, enter the IP address and mask. RAS User/Group—For remote gateways that are users, select the user object or user group object that represents the RAS user. Dynamic IP Address—For remote gateways that use a dynamic IP address, select dynamic IP address.
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.
Outgoing Interface	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	Heartbeats are used to enable redundant gateways. You can use the default or set your own thresholds: Hello—Enter the number of seconds the security device waits between sending hello pulses. Reconnect—Enter the maximum number of seconds the security device waits for a reply to the hello pulse. Threshold—Enter the number of seconds that the security device waits before attempting to reconnect.
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: Interval(Seconds) — Specifies the DPD interval. This interval is the time (in seconds) that the device allows to pass before considering a peer to be dead. Always Send Switch — Instructs the device to send DPD requests regardless of whether there is IPsec traffic with the peer or not. Retry Times — Specifies the maximum number of times to send the response request before considering the peer to be dead. Reconnect(Seconds) — Specifies the reconnect interval. The parameter renegotiates the tunnel at configured intervals after it is cleaned up because of a dead peer detected.
NAT Traversal	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: UDP Checksum—A 2-byte value (calculated from the UDP header, footer, and other UDP message fields) that verifies packet integrity. You must enable this option for NAT devices that require UDP checksum verification; however, most NAT devices (including security devices) do not require it. Keepalive Frequency—The number of seconds a VPN node waits between sending empty UDP packets through the NAT device. A NAT device keeps translated IP addresses active only during traffic flow, and invalidates unused IP addresses. To ensure that the VPN tunnel remains open, you can configure the VPN node to send empty “keep alive” packets through the NAT device.
Auth-Method	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. Authentication method for this device—Select any of the authentication method you want to use. You can use certificates or preshared objects. With certificates, IKE uses a trusted authority defined in your network for the certificate server. You must define this trusted certificate authority by creating a certificate authority object. With preshared secrets, IKE generates an ephemeral secret and propagates it to each VPN node. This is secure because it propagates only within the VPN. Peer’s authentication type—Both phases use proposals when they negotiate a connection. Both peers must use the same authentication and encryption algorithms to establish communication.

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 54 describes the different ID type for each member.

Table 54: IKE IDs/XAuth Types

ID Types	Description
ASN1-DN	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. At the peer ID, specify values for the Container Match and Wildcard Match. At the local ID, specify the value. Using a group ID can make configuring and maintaining your VPN quicker and easier. For details on how group IKE IDs work, see, Configuring Group IKE IDS section inPolicy-Based VPN Creation Using Remote Access Server Users Overview. For details on determining the ASN1-DN container and wildcard values for group IKE IDs, see the Juniper Networks ScreenOS 5.x Concepts and Examples Guide.
FQDN	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.
IP Address	Use an IP address when the VPN member uses a static IP address.
U-FQDN	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 user1@mycompany.com.
Default Server	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.
XAuth Server	Use to specify the authentication server that assigns TCP/IP settings to the remote gateway. XAuth Server Name—Select a preconfigured authentication server object. For details on creating authentication server objects, see Device Administrator Authentication Overview. Allowed Authentication Type—Select generic or Challenge Handshake Authentication Protocol (CHAP) (password is sent in the clear) to authenticate the remote gateway. Query Remote Setting—Enable this option to query the remote settings object for DNS and WINS information. Users and Groups—Authenticate XAuth RAS users using the authentication server, by enabling User or User Group and selecting a preconfigured user object.
XAuth Client	Use when the remote gateway is a RAS user that you want to authenticate. Allowed Authentication Type—Select Any or Challenge Handshake Authentication Protocol (CHAP) for authentication (password is sent in the clear). User Name and Password—Enter the username and password that the RAS user must provide for authentication. Note: All passwords handled by NSM are case-sensitive.
Bypass Authentication	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.

Note: 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)
  Note: 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.

Device Level AutoKey IKE VPN: Using Gateway Configuration Overview

ScreenOS Devices Gateway Properties

ScreenOS Devices IKE IDs or XAuth Identification Number

Security Methods for ScreenOS Devices

Related Documentation