This document describes the Nx Networks implementation of IPSec. For examples on how to configure IPSec, see Setting Up IPSec.

This document has the following topics:

Introducing IPSec

This document describes the IPSec component of OpenROUTE software. A related document, Managing Certificates, describes the process of handling the certificate requirements for IKE and IPSec.

Terminology

Anti-replay	There is a form of attack called man-in-the-middle, where someone intercepts packets between two parties. These attackers may then resend, or replay, duplicate packets. Since these packets would contain correct authentication information, the receiver may accept the traffic as legitimate. Anti-replay prevents this by using sequence numbers to detect duplicate traffic.
Authentication Header (AH) Protocol	This protocol authenticates the origin of the communication and the integrity of data, including portions of the IP header.
Diffie-Hellman	The Diffie-Hellman protocol provides a simple, secure way for peers to exchange public keys without requiring a third-party Certificate Authority (CA).
Encapsulating Security Payload (ESP)	By encrypting the data, this protocol ensures the confidentiality of information. You can also use ESP to authenticate the origin of the communication.
IKE	Internet Key Exchange. Formerly called ISAKMP/Oakley. IKE authenticates that you are communicating with the desired party. It also negotiates the exchange of session keys and security policies.
IKE Transform	In the IPSec software the IKE transform is where you set IKE phase 1 parameters.
Initiator/Responder	When using IKE, one peer must initiate an IKE negotiation. The peer that sends a packet first becomes the initiator. The other peer becomes the responder. You do not need to set up a peer as an initiator. It is an on-demand concept, where the peer that needs to establish an IKE session in order to send a protected packet becomes the initiator.
Opaque	When IPSec compares its security policies against packets, it sometimes cannot view protocols or ports because they are encrypted or compressed. Setting the matching rules for protocol or ports to opaque causes IPSec to ignore the matching rules for protocol or ports if they are encrypted or compressed.
Peer	Another IPSec-standard device at the other end of the IPSec tunnel.
Perfect Forward Secrecy (PFS)	Protocols that ensure that each key used to protect data or to generate keys are not used to derive further keys are said to have Perfect Forward Secrecy. This means that if a single key is compromised, only one key's worth of data is compromised.
Policy	The criteria that describe the types of packets IPSec recognizes, and the action IPSec takes when it recognizes a packet.
Profile	A way of grouping policies. You attach profiles to interfaces.
Road Warrior	A road warrior (RW) is an IPSec peer whose IP address is not known in advance, such as a mobile user or telecommuting user. Another example is an IPSec router at a branch office whose ISP dynamically assigns its IP address.
Security Association (SA)	Security Association defines the type of protection to use for certain types of traffic or certain locations. It controls things like the type of authentication or encryption to provide and which algorithms to use.
Security Parameter Index (SPI)	An IPSec internal number that identifies a Security Association. AH, ESP, and IPCOMP protocols carry an SPI in their headers. The receiver uses the SPI to distinguish among different SAs sent to the same destination using the same IPSec protocol. This lets the receiver select the correct SA to use to process the packet. For IKE negotiated SAs, the software automatically derives SPIs. For manual SAs you need to enter SPIs for all Security Associations, inbound and outbound. Manual SPIs are an arbitrary number you assign. Note: Inbound SPIs for each protocol type (AH, ESP, or Comp) must be unique for each SA proposal on this router. At the same time, two peers at either end of an IPSec connection must have matching SPIs.
Security Policy Database (SPD)	This is a database that you establish. IPSec matches packets against entries in the database. When IPSec finds a match, it either applies IPSec protection, discards the packet, or allows the packet to pass without IPSec security being applied.

Features

• Authentication, which includes data authentication (integrity) and origin authentication.

  • Data authentication verifies that data is not altered during transmission. This includes Anti-replay service, which OpenROUTE software automatically provides if you are using IKE.

  • Origin authentication ensures that you are actually communicating with the individual or organization you believe you are communicating with.

• Encryption, makes your data confidential by making it unreadable to everyone but you.

• Compression, to compress data before encrypting it.

Security and Compression Protocols Supported

• Authentication Header (AH) Protocol uses packets headers to authenticate the origin of traffic, as well as the integrity of data.

• Encapsulating Security Payload (ESP) uses packets headers to encrypt user data. You can also use ESP to authenticate the origin of traffic.

• IPCOMP (IP Compression) compresses data.

Exporting Algorithms from the United States

United States (U.S.) government encryption export policy limits the key size, and hence the strength, of encryption equipment exported outside of the U.S., with the exception of Canada. Nx Networks provides different software for domestic and export-controlled use.

The following table shows the algorithms and key lengths provided in these two versions of software.

Algorithm	U.S. and Canada Key Lengths	Export-controlled Key Lengths
DES	56	56
Triple DES	168 (Three 56-bit keys)	Not Exportable
Blowfish	56 to 256	56
Diffie-Hellman Modulus	768, 1024, 1536	768, 1024

RFCs Supported

• The ESP CBC-Mode Cipher Algorithms (RFC 2451)

• The ESP DES-CBC Cipher Algorithm With Explicit IV (RFC 2405)

• The ESP DES-CBC Transform (RFC 1829)

• HMAC: Keyed-Hashing for Message Authentication (RFC 2104)

• The Internet IP Security Domain of Interpretation for ISAKMP (RFC 2407)

• The Internet Key Exchange (IKE) (RFC 2409)

• Internet Security Association and Key Management Protocol (ISAKMP) (RFC 2408)

• IP Authentication Header (RFC 2402)

• IP Encapsulating Security Payload (ESP) (RFC 2406)

• IP Payload Compression Protocol (IPComp) (RFC 2393)

• IP Security Document Roadmap (RFC 2411)

• The NULL Encryption Algorithm and Its Use With IPSec (RFC 2410)

• IP Payload Compression Using LZS (RFC 2395)

• Security Architecture for the Internet Protocol (RFC 2401)

• The Use of HMAC-MD5-96 within ESP and AH (RFC 2403)

• The Use of HMAC-SHA-1-96 within ESP and AH (RFC 2404)

These policies let you protect different classes of traffic, such as traffic from different hosts, protocols or ports, independently of others. It prevents traffic from unnecessarily receiving cryptographic protection, and it prevents unwanted traffic from being passed on at all.

The following diagram shows the components that make up the OpenROUTE IPSec software, and it shows the relationships of the components. The next sections describe these components in detail.

Peer Definitions

IP Addressing for IPSec

• You are using dynamic addressing on your WAN connection.

• You are running IPSec with multiple WAN interfaces. If one WAN interface goes down, IPSec traffic could be routed through the second WAN interface, as long as you have set up routing accordingly.

IKE Transforms

IKE uses two phases

• IKE phase 1 establishes the exchange of session keys using the information you specify in IKE Transforms. IKE then uses these keys to protect IKE phase 2 negotiations.

• IKE phase 2 establishes IPSec-level security associations, which are then used to protect user data. IKE phase 2 uses the parameters in SA proposals to negotiate security associations.

You can create multiple IKE transforms that have different settings, but the same name. To differentiate them, you assign a sequence number to each transform. The sequence number reflects the order of preference for the transforms, with the lower number having first preference.

During IKE phase 1, the IKE initiator peer sends all of its IKE transforms to the responder peer. The responder then compares the parameters in the proposal it receives to its own proposal.

• If it finds a match, it accepts the matching IKE transform proposal.

• If it does not find a match, it rejects the request, and the session is not established.

• The responder considers only the first proposal from the initiator; it ignores any subsequent proposals.

• Within a proposal, the responder considers only the first authentication, encryption, or compression algorithms. It ignores any subsequent algorithms in a proposal.

The main differences are

• Main mode uses a series of six messages to negotiate security settings, while aggressive mode uses three messages.

• Main mode provides identity protection, while aggressive mode does not provide identity protection.

• Main mode negotiates the Diffie-Hellman group, while aggressive mode does not negotiate the Diffie-Hellman group.

Typically, you would use aggressive mode for remote users dialing in to a corporate network. In OpenROUTE 5.3 and later releases, you must use aggressive mode for a road warrior client.

IKE Phase 2

IKE Parameters

Table 2 IKE Transform Parameters

Parameter	Options	Description
hash	hmac_sha hmac_md5	Algorithm IKE uses to derive keys and to authenticate the peer.
encrypt	3des des	Encryption algorithm IKE uses to encrypt IKE data.
auth	Pre_Shared_key DSA_Signatures RSA_Signatures	Method IKE uses to identify and authenticate the peer.
dh_group	768_bit_(group_1) 1024_bit_(group_2) 1536_bit_(group_5)	Key size Diffie-Hellman uses to derive public/private key pairs.
lifesecs	#-of-seconds	Duration of the IKE transform measured in seconds.
lifeKB	#-of-kilobytes	Duration of the IKE transform measured in the amount of data sent.
rename	newname	Renames the IKE transform.
change_priority_number	number	Changes order preference of IKE transforms.

SA Proposals

SA proposals control what this router proposes to the IPSec peer when creating a new IPSec security association via IKE. You may specify an ordered sequence of SA proposals in one IPSec policy to provide the IPSec peer with several choices.

When you set up IKE-negotiated SAs, all authentication and encryption methods and algorithms, as well as other SA parameters, must match exactly at each peer or IKE negotiations fail and the SA is not established. IKE does not establish an SA where protection would not be equal for both peers.

Selecting Algorithms

• authentication method and algorithm

• encryption method and algorithm

• compression algorithm

• On the positive side, more choices mean a better chance at interoperability with the IPSec peer.

• On the negative side, more choices mean that the IPSec peer might not choose the algorithm you really prefer.

ESP provides a narrower scope of authentication than AH because ESP does not protect the outside IP headers.

Nx Networks recommends using AH unless you only need to authenticate the upper layer protocols. In this case, ESP is an appropriate choice and is more space efficient than using AH to encapsulate ESP.

Note: If you are using IKE to negotiate SAs and you want to use ESP as the authentication method, you must also use ESP encryption. This restriction does not apply to manual SAs.

• both ESP encryption and authentication

  Or

• AH authentication

• ESP encryption only

  Or

• manual SA proposals

• one SA for AH header

• one SA for ESP header

• one SA for compression

For example, if you select both AH and ESP, IPSec creates four SAs, two for each direction.

To see the actual SA bundles that IPSec creates, enter show sa at the IPSec> prompt.

Expiration of SAs

In addition to these settings, if after one minute an SA has sent at least three outbound packets to the peer, but has received no inbound packets from the peer, the SA automatically expires. You can adjust the length of this inactivity timer.

Overlap Rekeying of SAs

There can be a short overlap of SA bundles between the time the new SA is created and the old SA expires. The router always uses the new SA when sending packets. Once the peer begins sending packets using the new SA, the router deletes the older SAs, if they have not already expired.

Manual SA Proposals

IPSec peers do not negotiate via IKE Phase 2 when you use a manual SA proposal. IPSec creates the SA proposal using whatever the SA proposal indicates as its preferred choice.

Notes:

• The peer determines whether to use IKE or manual SAs. When you set up a peer, you can set the peer type to manual or IKE.

• If you set up a peer to use manual SA proposals, you need to enter manual inbound and outbound keys.

• Timeout parameters in manual SA proposals do not apply because manual SAs do not time out.

• The Anti-replay feature is always off in manually-created SAs.

• You cannot share manual SA proposals in multiple policies. The reason is that inbound SPIs for each protocol type (AH, ESP, or Comp) must be unique for each SA proposal on this router. At the same time, two peers at either end of an IPSec connection must have matching SPIs.

Table 3 SA Proposal Parameters

Parameter	Options	Description
AH_auth_method	hmac_sha hmac_md5 none	Use the Authentication Header (AH) Protocol to authenticate that data was not altered during transmission and to authenticate the origin of communication.
ESP_auth_method	hmac_sha hmac_md5 none	Use Encapsulating Security Payload (ESP) to authenticate that data was not altered during transmission and to authenticate the origin of communication.
ESP_encr_method	3des des blowfish none	Select the ESP encryption algorithm, if any, used to encrypt user data.
compression_method	lzs none	Select whether or not to compress user data using the LZS algorithm.
lifesecs	#-of-seconds	Duration of the SA measured in seconds.
lifeKB	#-of-kilobytes	Duration of the SA measured in amount of data sent.
pfs_group	768_bit_(group_1) 1024_bit_(group_2) 1536_bit_(group_5) none	Type of Perfect Forward Secrecy (PFS), if any, the SA proposal uses to generate new keys.
key_alg_detail	what_algorithm keysize	Key length for algorithms that have adjustable key lengths.
outbound_manual_keying	ah_spi esp_spi comp_spi ah_auth_key esp_auth_key esp_encr_key	If this is a manually-created SA proposal, enter the appropriate SPIs and manual keys for outbound traffic.
inbound_manual_keying	ah_spi esp_spi comp_spi ah_auth_key esp_auth_key esp_encr_key	If this is a manually-created SA proposal, enter the appropriate SPIs and manual keys for inbound traffic.
rename	newname	Lets you rename the SA proposal.

Policies

The policy lets you protect different classes of traffic, such as traffic from different hosts, protocols, or ports, independently of others.

You can set up a policy to take one of the following actions when it matches a packet. This prevents traffic from unnecessarily receiving cryptographic protection, and it prevents unwanted traffic from being passed on at all.

• protect traffic by applying IPSec encryption and authentication

• pass traffic without applying IPSec protection

• discard traffic

You can change the order of your policies using the after option with the add policy or set policy commands.

Detecting Incoming Traffic That Should Have Been Encrypted

Policy Criteria

If a packet matches the criteria in a policy, IPSec applies the action that you selected for the policy.

Table 4 Policy Criteria

Parameter	Options	Description
action	discard pass protect	The action to take when packets match the criteria in this policy.
after	policy name *	The position of the policy within the profile.
direction	both outbound inbound	Sets whether to apply this policy to inbound traffic, outbound traffic or both inbound and outbound. Only in rare cases would you use anything except both.
peer	peername	Where to send protected traffic that matches this policy. See Peer Definitions.
rename	newname	Renames the policy.
sa_proposal	sa proposal name	The desired IPSec protection for the packet. See SA Proposals.
destination	ipaddress ipaddress&mask ipaddress-ipaddress myipaddr	Applies the policy to traffic sent to this destination. You can create a policy for a single address, a subnet, or a group of hosts within a range of addresses.
source	ipaddress ipaddress&mask ipaddress-ipaddress myipaddr	Applies the policy to traffic that originates from this source. You can create a policy for a single address, a subnet, or a group of hosts within a range of addresses.
protocol	name number any	Applies the policy to certain protocols. This lets you protect or discard certain types of traffic, while allowing other traffic to pass unprotected.
opaque_protocol	on off	Set to On to cause IPSec to ignore the matching rules for protocols that are encrypted or compressed. See Opaque.
dport and sport	=name =number -=name -=number	Applies the policy to certain ports. This lets you protect or discard certain types of traffic, while allowing other traffic to pass unprotected.
opaque_ports	on off	Set to On to cause IPSec to ignore the matching rules for ports that are encrypted or compressed. See Opaque.

Profiles

You can set up profiles to provide access to specific resources in a private network for a user or group of users. You can also set up profiles that let users inside your private network have access to public networks, while keeping your private network secure.

Profiles are associated with an interface in an ordered sequence. The interface consults the policies in its associated profiles on each incoming and outgoing packet.

Profile Criteria

Table 5 Profile Criteria

Parameter	Options	Description
rename	newname	Renames the profile.
type	spd roadwarrior_client roadwarrior_gateway	Defines the type of peer that uses this profile.

Interfaces

Table 6 Interface Parameters

Parameter	Options	Description
ipsec_enable	on off	Turns IPSec on or off on an interface.
profile	+= profile name -= profile name	Attaches profiles to or removes profiles from an interface.
df_bit_handling	set clear copy	Sets the DF (Don't Fragment) bit in the encapsulating IPSec header.
path_mtu_ageout	interface# path_mtu_ageout = #-of-seconds	Ageout timer for MTU values in SA bundles on this interface.

IPSec Road Warriors

There are two types of road warriors.

• Road Warrior Clients

  An example is a PC client, such as a mobile or telecommuting user, dialing into an ISP. The ISP dynamically assigns an IP address to the PC. This dynamic IP address serves as the IP address of the IPSec tunnel endpoint in the IPSec outer IP header, and application IP address in the application IP header.

• Road Warrior Gateways

  An example is an IPSec router at a branch whose ISP dynamically assigns its IP address. This dynamic IP address serves as the IPSec tunnel endpoint IP address in the IPSec outer IP header, but the application IP addresses may be other IP addresses.

• If you set up an IPSec router to work with a RW peer, you set Peer IDs in your peer definition so that when the RW peer dials in, the IPSec router can identify the peer and apply the correct policies.

  Since the IPSec router does not know the RW peer's IP address in advance, the RW peer must always be the initiator.

• If you set up an IPSec router to be the RW, you set My ID in the IPSec global configuration using the set global command.

• Road warrior policies are not active policies in the Security Policy Database (SPD). They are template policies. Once IKE phase 2 negotiation begins, IPSec creates a dynamic policy using the information in the SA proposal along with the actual IP addresses that the RW is using. IPSec instantiates this dynamic policy in the SPD.

• Road warrior policies are never used to initiate communication, since only the road warrior can initiate sessions.

• Pass/discard policies are completely ignored in road warrior profiles; that is, profiles of type=roadwarrior_client or roadwarrior_gateway. If you want to permit other traffic to pass at the headquarters, ensure that you have another separate profile of type=spd that has a pass policy in it and attach it to the interface.

Using IPSec With NAT, IP Filters and Other IP Protocols

Using IPSec With NAT

However, if IPSec is not running on the same interface as NAT, you need to set up NAT to allow IKE traffic, which runs on UDP port 500, through NAT.

NAT Config>add service
Service table involved is the global table([Yes] or No): [yes]?
Service name ([CR] to get a list of well-known-services)? ike
Server's IP address [0.0.0.0]? 10.1.1.1
Server's local port (0 = no port translation) [0]?
Enter protocol [TCP]? udp
Enter starting port number ([CR] for all) [-1]? 500
Enter ending port number [500]? 500

To set whether or not to apply NAT to IPSec traffic, use the nat_usage option with the add peer or set peer commands.

Using IPSec With IP Filters

By default, the router does not apply IP filters to IPSec traffic. However in your IPSec configuration you can set whether or not to apply filters to IPSec-protect traffic to or from select peers. To do this, use the ip_filter_usage option with the add peer or set peer commands.

If you do set up IPSec to apply IP filters to a peer, the router applies filters to the application IP header, which is the inner IP header, and not to IPSec headers. IPSec and IP filters work together in this way,

• For inbound traffic, IPSec processes the traffic first so that filters are applied to IPSec traffic after IPSec encapsulation is removed.

• For outbound traffic, IP filters are applied to a packet before IPSec processes the packet. Thus, IPSec protection is wrapped around packets.

RIP, OSPF, DHCP, BOOTP, DVMP, and IGMP.

IPSec also automatically passes ARP packets without applying IPSec protection to them.

Entering IPSec Commands

If you are using the OpenROUTE command line interface to set up IPSec, this section provides information on entering IPSec commands. It covers the following topics:

• Tips on Entering Commands

• How IPSec Commands Work

• Using IPSec Configuration and Monitoring Prompts

• Simplified Configuration Tasks

• Default Definitions

For more information, see the document called Using the Command Line Interface in the online library.

Command Completion

IPSec Config> add sa_proposal headquarters AH_auth_method =
 AH authentication method

The choices/prefixes are (a complete list):

 hmac_sha
 hmac_md5
 none

IPSec Config> add sa_proposal headquarters AH_auth_method = 

How IPSec Commands Work

For example,

IPSec Config> add ike_transform newike 12 <SPACE>
 Adds IKE-transforms.

The choices/prefixes are (a complete list):

 hash                   (optional)  -- hash algorithm
 encrypt                (optional)  -- encryption algorithm
 auth                   (optional)  -- authentication method
 dh_group               (optional)  -- Diffie-Hellman Group
 lifesecs               (optional)  -- lifetime in seconds, 
                                         or 0 for no limit
 lifeKB                 (optional)  -- lifetime in Kilobytes 
                                          of traffic, or 0 for no limit.
 rename                 (optional)  -- Specifies the new name of the 
                                         IKE transform.
 change_priority_number (optional)  -- Orders the IKE-transforms.

IPSec Config> add ike_transform newike 12 auth = RSA_Signatures 
hash = hmac_sha encrypt = 3des lifesecs = 600 

IPSec Configuration Prompt

To display the IPSec Config> prompt,

1. At the Config> prompt, enter protocol ip.

Config>protocol ip 
Internet protocol user configuration
IP config>

2. Enter ipsec.

IP config>ipsec 
IPSec Config>

To display the IPSec> prompt,

1. At the Monitor> prompt, enter protocol ip.

Monitor>PROTOCOL ip

2. Enter ipsec.

IP>ipsec
IPSec>

• If you add a definition, such as a peer or policy, that requires another definition, IPSec automatically creates the required definition and names it default. See Default Definitions.

• You can attach the same IPSec profile to multiple interfaces.

• Multiple IPSec policies can reference the same SA proposal or peer definition. (The exception is manual SA proposals. Since each manual SA proposal must have unique SPIs, you cannot share them.)

• Multiple IPSec peers can reference the same IKE transform.

• You need to define the IP address of IPSec peers only once, in the peer definition.

• You define all certificates under the Certificate Management configuration.

For example, a Policy with the action set to protect requires a Peer and an SA proposal. In this case, the policy references a Peer called default and an SA proposal called default. You can use the name default, rename them, or create new peers or proposals and add them to the policy.

IPSec makes sure that a default Peer, SA-proposal, and IKE transform always exist if they are needed. You may delete default definitions that are not being used.

IPSec Commands

Press Space twice after you type a command to display the available parameters for each command. Enter help for information about using the command line interface.

[C] means the command is available at the IPSec Config> prompt.

[M] means the command is available at the IPSec> prompt.

Table 7 IPSec Commands

Command	Description
Add Peer [C]	Adds and defines IPSec peers.
Add sa_proposal [C]	Adds and defines an SA proposal.
Add Profile [C]	Adds a profile.
Add Policy [C]	Adds and defines a security policy.
Add IKE_transform [C]	Adds and defines an IKE transform.
Delete [C] [M]	Deletes IPSec peers, profiles, policies, SA proposals, or IKE transforms. Note that at the Monitor> prompt, you can delete only IKE transforms.
List [C] [M]	Lists different configuration properties of IPSec.
Set Peer [C]	Changes your peer definitions.
Set sa_proposal [C]	Changes your SA proposal definitions.
Set Profile [C]	Lets you rename a profile.
Set Policy [C]	Changes your policy definitions.
Set IKE_transform [C]	Changes your IKE transform definitions.
Set Interface [C] [M]	Enables or disables IPSec. Attaches profiles to or removes profiles from interfaces. Sets MTU values.
Set Global [C] [M]	Sets timeouts for IKE Phase 1 negotiations, as well as an inactivity timer for SA sessions that were negotiated using IKE Phase 2. For road warrior routers, you can also use this command to set the ID that identifies this router to its peer.
Show IKE_SA [M]	Displays the current status of active IKE SA sessions and IPSec SA sessions.
Show Policies [M]	Displays policies that are currently being used on the router.
Show SA [M]	Displays SAs that IKE has negotiated and are running on the router.

Add Peer [C]

The remainder of this section describes the parameters you can define when you add a peer. You can add to or change the peer definition using the set peer command.

Syntax: add peer peername

The default destination address is 10.10.10.10.

Syntax: ip_address =

ipaddress

peer_id_type

Notes:

• If you use a peer ID type other than IP address, you also need to set the actual ID using the peer_id_value option.

• If you use the peer's IP address as peer ID type, IPSec uses the IP address you set using the ip_address option.

ip_address

domain_name_(Fully_Qualified_Domain_Name)

email_(User_Fully_Qualified_Domain_Name)

keyID

Entry	Description
ip_address	IPSec identifies the peer using the peer's IP address. This is the default setting. If you select IP address, IPSec uses the IP address you set using the ip_address option. IPSec does not use the peer_id_value option.
domain_name	Also called Fully Qualified Domain Name (FQDN). IPSec identifies the peer using the domain name you enter in the peer_id_value option.
email	Also called User FQDN. IPSec identifies the peer using the e-mail address you enter in the peer_id_value option.
KeyID	IPSec identifies the peer using the key ID you enter in the peer_id_value option.

peer_id_value

In the case where the router is a road warrior, the peer type and value must match the IKE-ID that the responder is configured to accept.

Before you enter a peer ID value, you need to select the peer_id_type, which tells IPSec the type of peer ID value you are going to add. The following table shows what IPSec expects as a value for each peer ID type.

Syntax: peer_id_value

ascii_for_peer_id = value

hex_for_peer_id = value

Value	Description
domain name	If you selected domain name in the peer_id_type option, enter the domain name that identifies this peer. For example, nxnetworks.com.
e-mail address	If you selected email in the peer_id_type option, enter the e-mail address that identifies this peer. For example, abc@nxnetworks.com.
Key ID	If you selected KeyID in the peer_id_type option, enter the key ID that identifies this peer. A Key ID is a string of characters assigned to the peer at each end of the IPSec connection.

Before you enter the peer ID value, you need to specify whether you are entering the value in ASCII or hex format.

rw_profile

Note: It is not necessary to make a separate road warrior profile for each road warrior. RW peers that have the same access rights to HQ can use the same road warrior profile.

profile name

ike_mode

Note: If you set up the router as a road warrior and you are using preshared key authentication, the router always initiates IKE in aggressive mode, even if you set the IKE mode to main.

If your router is the responder, the router behaves as follows:

• The responder considers only the first proposal from the initiator; it ignores any subsequent proposals.

• Within a proposal, the responder considers only the first authentication, encryption, or compression algorithms. It ignores any subsequent algorithms in a proposal.

aggressive

main

Example: add peer chicago ike_mode=aggressive

peer_type

Syntax: peer_type =

ike

manual

Entry	Description
ike	IPSec uses the settings in SA proposal(s) associated with this peer for IKE phase 2 negotiations. The default is to use IKE.
manual	Use a manual proposal if you are not using IKE. See Manual SA Proposals. If you select manual, you need to enter outbound_manual_keying and inbound_manual_keying in the SA proposal associated with this peer.

ike_transform

Syntax: ike_transform =

default

transform name

Example: add peer chicago ike_transform =

pre_shared_key

By default, the router is set up to use preshared keys, and it comes with a default preshared key of 1234. When you first set up two routers to run OpenROUTE IPSec software, the routers can easily negotiate IKE using the default settings because the preshared keys match. Of course, you need to change 1234 to your own preshared key as soon as possible.

You can add the shared key in either ASCII or hexadecimal format, and the key can be up to 128 bytes. Hexadecimal format requires two hex characters (0-9 or a-f) for each password byte.

Nx Networks recommends using random sequences. For ASCII keys, use a random sequence of upper- and lower-case characters with many numbers also included.

Syntax: pre_shared_key

ascii = ascii characters

hex = hex digits

Example: add peer chicago pre_shared_key ascii_for_preshared_key =SiH67HuRtyP5902WmLKJgfdUiphw895KkSdfGgLhW2JVgcg

Example: add peer chicago pre_shared_key hex_for_preshared_key =87b49ef8359730c2c4dd8a29b4b9a688405195869367040602041895b6c5afce

preferred_ca

When IKE negotiates with this peer, IKE requests the peer to send a certificate that a trusted CA has signed. If you have multiple CAs set up in the Certificate Management software, this router requests the peer to send a certificate for each CA configured in the Certificate Management software. If you set a preferred CA, IKE requests a certificate only for the preferred CA.

If you enter a preferred CA name, the name must match a CA name you added using the add ca command at the CertMgmt Config> prompt.

If you do not set a preferred CA, the IKE software negotiates with the peer which CA to use.

Syntax: preferred_ca =

name

source_ip_address

The default setting of 0.0.0.0 causes IPSec to use the IP address of the router's IPSec interface.

You need to set this address only in special situations. For example, in cases of setting up redundant connections, you may have two IPSec interfaces connected to the Internet, but you want to present only one address to the IPSec peer.

Another case is if you are using dynamic addressing for your IPSec interface, but the IPSec peer needs to know your address in advance, or the peer requires that you present a constant address. In this case, you may want to use the router's internal IP address as the source or destination address in your peer definitions.

Syntax: source_ip_address =

ipaddress

rename

When you rename a peer, the IPSec software automatically changes the peer name in any policy that references the peer.

Syntax: rename =

newname

ip_filter_usage

Syntax: ip_filter_usage =

none

same_as_interface

Example: add peer chicago ip_filter_usage = same_as_interface

nat_usage

Syntax: nat_usage =

none

same_as_interface

Example: add peer chicago nat_usage = same_as_interface

hardware_assist

Note: Using hardware rather than software to perform these tasks greatly increases the speed of IPSec.

Example: add peer chicago hardware_assist = on

On	Router hardware performs compression, encryption, and authentication. This is the default setting.
Off	Router software performs compression, encryption, and authentication.

send_cert_id

On	The local IKE peer uses the SubAltName as its ID in its certificate when it negotiates IKE phase 1 with this peer.
Off	The local IKE peer does not use the SubAltName in its certificate as its ID when it negotiates IKE phase 1 with this peer. Instead, IKE uses the my_id_value as the ID. This is the default setting.

Example: add peer chicago send_cert_id = on

match_id

On	IKE checks the peer ID during IKE negotiations. If you are using certificates, IKE also checks that the peer ID matches the SubAltName in the peer's certificate.
Off	IKE does not check the SubAltName in the peer's certificate. This is the default setting.

Example: add peer chicago match_id = on

Add sa_proposal [C]

When you set up IKE-negotiated SAs, all authentication and encryption methods and algorithms, as well as other SA parameters, must match exactly at each peer or IKE negotiations fail and the SA is not established. IKE does not establish an SA where protection would not be equal for both peers.

The remainder of this section describes the parameters you can define when you add an SA proposal. You can add to or change the SA definition using the set sa_proposal command.

AH_auth_method

By default, the SA proposal uses AH as the authentication method with HMAC-SHA as the default algorithm.

Syntax: AH_auth_method =

hmac_sha

hmac_md5

none

Example: add sa_proposal sa2 AH_auth_method = hmac_sha

ESP_auth_method

Notes:

• Nx Networks recommends using the AH protocol for authentication because ESP does not protect the outer IP header.

• If you are using IKE to negotiate SAs and you are using ESP as the authentication method, you must also use ESP encryption. This restriction does not apply to manual SAs.

hmac_sha

hmac_md5

none

Example: add sa_proposal sa2 esp_auth_method=hmac_sha

ESP_encr_method

Syntax: ESP_encr_method =

3des

des

blowfish

none

Example: add sa_proposal sa2 ESP_encr_method = blowfish

compression_method

Syntax: compression_method=

lzs

none

Example: add sa_proposal sa2 compression_method=lzs

lifesecs

If you are using manual SAs rather than using IKE to negotiate SAs, this setting does not apply because manual SAs do not time out.

Enter 0 for no limit, which is the default. The range is 0 to 4294967295 seconds. You can also set the duration in amount of data using the lifeKB option. If you set both options, the SA expires when the SA first reaches one of the maximum values.

Note: If there is still application traffic running through an SA when the SA session expires, IKE negotiates a new SA. To prevent the router from dropping packets while IKE negotiates the new SA, IPSec begins negotiating the new SA before the existing SA expires.

#-of-seconds

lifeKB

If you are using manual SAs rather than using IKE to negotiate SAs, this setting does not apply because manual SAs do not time out.

Enter the amount of data in Kilobytes. Enter 0 for no limit, which is the default. You can also set the duration in number of seconds using the lifesecs option. If you set both options, the SA expires when the SA first reaches one of the maximum values.

Note: If there is still application traffic running through an SA when the SA session expires, IKE negotiates a new SA. To prevent the router from dropping packets while IKE negotiates the new SA, IPSec begins negotiating the new SA before the existing SA expires.

#-of-kilobytes

pfs_group

Note: There is a performance cost to using PFS. Each new SA negotiation involves a new Diffie-Hellman calculation. You may need to turn off this feature if your SAs are created often.

768_bit_(group_1)

1024_bit_(group_2)

1536_bit_(group_5)

none

key_alg_detail

Currently, Blowfish is the only algorithm for which you can change the key length.

Syntax: key_alg_detail

what_algorithm = algorithm

keysize = number-of bits

Example: add sa_proposal sa2 key_alg_detail what_algorithm = esp_encr_blowfish

outbound_manual_keying

You need to enter keys that correspond to the authentication and encryption methods and algorithms you chose for this SA. For example,

• If you are using AH as the authentication method and MD5 as the authentication algorithm, enter an MD5 key using the ah_auth_key = option.

• If you are using ESP as the encryption method and 3DES as the encryption algorithm, enter a 3DES key using the esp_encr_key = option.

ah_spi=2 to 8 hex digits

esp_spi=2 to 8 hex digits

comp_spi=2 to 4 hex digits

ah_auth_key=32 to 40 hex digits

esp_auth_key=32 to 40 hex digits

esp_encr_key=14 to 64 hex digits

Example: add sa_proposal sa3 outbound_manual_keying esp_auth_key = 12903748243909384923472827609154098279

inbound_manual_keying

CAUTION:
In order for IPSec to run correctly, each inbound SA proposal must have unique SPIs within each IPSec protocol (AH, ESP, or IPComp).

You need to enter keys that correspond to the authentication and encryption methods and algorithms you chose for this SA. For example,

• If you are using AH as the authentication method and MD5 as the authentication algorithm, enter an MD5 key using the ah_auth_key = option.

• If you are using ESP as the encryption method and 3DES as the encryption algorithm, enter a 3DES key using the esp_encr_key = option.

ah_spi=2 to 8 hex digits

esp_spi=2 to 8 hex digits

comp_spi=2 to 4 hex digits

ah_auth_key=32 to 40 hex digits

esp_auth_key=32 to 40 hex digits

esp_encr_key=14 to 64 hex digits

Example: add sa_proposal sa2 inbound_manual_keying ah_spi = 3368

rename

When you rename an SA proposal, the IPSec software automatically changes the proposal name in any policy that references the proposal.

Syntax: rename =

newname

Add Profile [C]

Syntax: add profile name

rename

newname

type

Syntax: type =

spd

roadwarrior_client

roadwarrior_gateway

Add Policy [C]

The remainder of this section describes the parameters you can define when you add a policy. You can add to or change the policy later using the set policy command.

For an overview of the options you can set for policies, see Policy Criteria.

When you enter a policy name, you always need to type its profile name first, followed by a period (.) and then type the policy name. For example,

Syntax: add policy profilename.policyname

action

Syntax: action =

protect

discard

pass

Example: add policy branch.finance action = protect

after

As the default, the software adds new policies to the end of the list.

Syntax: after =

policy name

*

Example: add policy branch.finance
add policy branch.sales
add policy branch.telecommuter after = finance

This example results in the following list.

IPSec Config> list policy branch
                                            -- *=opaque allowed --
Name                  Dir  Address          Port       Protocol  Action
-----------------------------------------------------------------------
branch.finance        both                  Any       protect
  sa_proposal=default, peer=default

branch.telecommuter   both                  Any       protect
  sa_proposal=default, peer=default

branch.sales          both                  Any       protect
  sa_proposal=default, peer=default 

By default IPSec creates SA proposals in both directions. If your SA proposals use IKE rather than manual proposals, you need to always set the direction to both.

The only situation where you may need a one-way policy is for applications that generate one-way traffic, such as multicast applications, where a router only receives or only sends broadcasts.

Syntax: direction =

both

outbound

inbound

Example: add policy branch.finance direction =outbound

peer

Syntax: peer =

peername

rename

When you rename a policy, the IPSec software automatically changes the policy name in any profile that references the policy.

Syntax: rename =

newname

sa_proposal

To add more than one SA proposal to a policy, type a comma (,) after the proposal name.

Syntax: sa_proposal =

sa proposal name

This example adds three SA proposals to the policy

Example: add policy branch.finance sa_proposal =sa2,sa3,default

destination

Note: When you are using a policy that applies to traffic in both directions, add source and destination addresses as they relate to inbound packets.

ipaddress

ipaddress&mask

ipaddress-ipaddress

myipaddr

The following example adds a range of IP addresses.

Example: add policy branch.finance destination =128.185.22.0-
128.185.25.0

The following example adds an IP address with a mask.

Example: add policy branch.finance destination =
128.185.25.0&255.255.255.0

source

Note: When you are using a policy that applies to traffic in both directions, add source and destination addresses as they relate to inbound packets.

ipaddress

ipaddress&mask

ipaddress-ipaddress

myipaddr