Technical Documentation

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.

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.