Using IPSec

Introducing IPSec

The IPSec protocol provides secure, interoperable communication across a network, transparent to the application. IPSec is the emerging standard for secure internet applications, such as electronic commerce and corporate VPNs. The OpenROUTE implementation goes beyond other offerings by also implementing the Internet Key Exchange (IKE) protocol for key management at the application level in secure networks.

This document describes the IPSec component of OpenROUTE Networks software.

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

Terminology

This document uses the following 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.

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.

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.
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

OpenROUTE IPSec provides three main functions:

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.

You can set up IPSec to provide you with one, some, or all of the above features. In most situations, you will want both authentication and encryption; you will also want to use compression if it provides extra throughput for your data.

Security and Compression Protocols Supported

The OpenROUTE IPSec implementation supports three IPSec security and compression protocols:

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.

IPSec provides two methods of authentication, the AH header and the ESP authentication header. OpenROUTE Networks recommends using the AH header for authentication because ESP does not protect the outer IP header.

OpenROUTE lets you easily express your IPSec choices for protecting your data in an SA proposal definition.

Exporting Algorithms from the United States

OpenROUTE provides several encryption and authentication algorithms to provide different levels of encryption or authentication strength.

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. OpenROUTE 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

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 OpenROUTE Networks IPSec software implements the following RFCs:

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)

How IPSec Works

IPSec applies security policies to IP packets going in or out a router interface.

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 implementation of IPSec, and it shows the relationships of the components. The next sections describe these components in detail.

Peer Definitions

The two IPSec routers at each end of an IPSec connection are called peers. A peer definition contains the parameters in Table 1.

IP Addressing for IPSec

In cases where you use dynamic addressing on your WAN connection, you may want to use the router's internal IP address as the source or destination address in your peer definitions.

Other situations where you may want to use the router's internal IP address as the source or destination address is in cases where you are using IPSec with multiple WAN interfaces. If one WAN interface is down, IPSec traffic could be routed through the second WAN card, as long as you have set up routing accordingly.

Table 1 Peer Parameters

Parameter Options Description

ip_address ipaddress
Address of the IPSec router at the other end of the IPSec tunnel.

ike_mode aggressive
main
Determines what parameters IKE negotiates during phase 1

peer_type ike
manual
Sets this peer to either use IKE to negotiate SAs or to use SAs that you manually create.

ike_transform default
transform name
Assigns the name of the IKE transform to use for this peer.

pre_shared_key ascii = ascii characters
hex = hex digit
Lets you add a shared key for this peer.

my_certificate default
name
Name of the certificate IKE Phase 1 peer establishment uses to authenticate this peer.

source_ip_address ipaddress
Sets the source IP address this router uses when communicating with this peer.

rename newname
Lets you rename the peer.

ip_filter_usage none
same_as_interface
Sets whether or not to apply IP filters to IPSec-protected traffic for this peer.

nat_usage none
same_as_interface
Sets whether or not to apply NAT settings to IPSec-protected traffic for this peer.

Table 1 Peer Parameters
Parameter	Options	Description
ip_address	ipaddress	Address of the IPSec router at the other end of the IPSec tunnel.
ike_mode	aggressive main	Determines what parameters IKE negotiates during phase 1
peer_type	ike manual	Sets this peer to either use IKE to negotiate SAs or to use SAs that you manually create.
ike_transform	default transform name	Assigns the name of the IKE transform to use for this peer.
pre_shared_key	ascii = ascii characters hex = hex digit	Lets you add a shared key for this peer.
my_certificate	default name	Name of the certificate IKE Phase 1 peer establishment uses to authenticate this peer.
source_ip_address	ipaddress	Sets the source IP address this router uses when communicating with this peer.
rename	newname	Lets you rename the peer.
ip_filter_usage	none same_as_interface	Sets whether or not to apply IP filters to IPSec-protected traffic for this peer.
nat_usage	none same_as_interface	Sets whether or not to apply NAT settings to IPSec-protected traffic for this peer.

IKE Transforms

IKE provides an automated way to securely exchange keys and to negotiate security associations, or policies. IKE identifies the peer and authenticates that you are communicating with the desired party.

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.

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	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

A Security Association (SA) is an agreement between two peers on how they authenticate and protect packets they send to each other. You can manually configure this agreement using Manual SA Proposals. If you are using IKE, the peers negotiate this agreement using an IKE Phase 2 exchange. You set your preferences for this negotiation in 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 a 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

You indicate your preferences for the following IPSec features in your SA proposal definition.

authentication method and algorithm
encryption method and algorithm
compression algorithm

Note: Although both authentication and encryption are optional, you must select at least one of them. You cannot omit both of them.

Creating Multiple SA Proposals

If you want to provide the other peer with multiple authentication or encryption options, you can create multiple SA proposals and attach them to the same policy.

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.

Using AH versus ESP

You can choose between two methods of authentication, AH or ESP.

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

OpenROUTE 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.

Anti-Replay Feature

The IKE software automatically turns on Anti-replay if you are using

both ESP encryption and authentication

Or
AH authentication

The IKE software does not turn on anti-replay if you are using

ESP encryption only

Or
manual SA proposals

SA Bundles

IKE negotiates SAs in a bundle. The IKE software takes the information in your SA proposal and creates up to three SAs for each bundle:

one SA for AH header
one SA for ESP header
one SA for compression

Each SA bundle applies to traffic in one direction. The software automatically creates a bundle for each direction, one for inbound traffic and one for outbound traffic.

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.

Manual SA Proposals

If you are not using IKE, you can set up manual SA proposals. You create the manual proposals the same way as IKE SA proposals, but you need to enter inbound and outbound keys and SPI values for each header (AH, ESP, compression) that you use.

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:

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.

Expiration of SAs

There are two lifetime settings you can use to cause SA sessions to expire and new sessions to be negotiated, lifesecs and lifeKB.

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.

SA Proposal Parameters

SA proposals contain the following parameters.

Table 3 SA Proposal Parameters

Parameter Options Description

AH_auth_method hmac_sha
hmac_md5
none
Use the Authentication Header (AH) Protocol to protect data from being altered during transmission. Selects the algorithm AH uses to authenticate data.

ESP_auth_method hmac_sha
hmac_md5
none
Use Encapsulating Security Payload (ESP) to protect data from being altered during transmission. Selects the algorithm ESP uses to authenticate data.

ESP_encr_method 3des
des
blowfish
none
Select the ESP encryption algorithm, if any, used to encrypt user data.

compression_method lzs
none
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.

Table 3 SA Proposal Parameters
Parameter	Options	Description
AH_auth_method	hmac_sha hmac_md5 none	Use the Authentication Header (AH) Protocol to protect data from being altered during transmission. Selects the algorithm AH uses to authenticate data.
ESP_auth_method	hmac_sha hmac_md5 none	Use Encapsulating Security Payload (ESP) to protect data from being altered during transmission. Selects the algorithm ESP uses to authenticate data.
ESP_encr_method	3des des blowfish none	Select the ESP encryption algorithm, if any, used to encrypt user data.
compression_method	lzs none	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

A policy lets you determine what type of traffic IPSec protects and how it protects that traffic. Like a filter, a policy has criteria that describe the types of packets it recognizes, and it takes action when it recognizes a packet.

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

Ordering Policies

IPSec checks packets against policies in the order in which you place policies in a profile. Once IPSec matches a packet to a policy, it takes the action you defined for the policy and does not check the packet against any further policies. This completes IPSec processing for the packet.

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

This feature is not included in the IPSec documentation.

The router detects and discards inbound application traffic that is not encrypted, but should have been according to the inbound protection policies. The router compares nonencrypted application traffic to inbound protection policies. If the router finds a match, it discards the packet.

Policy Criteria

A policy contains the properties in the following table. It includes the peer and SA proposal definitions that you set up.

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
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
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.

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	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	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

A profile contains one or more security policies that control all traffic through an IPSec interface. It determines and authenticates who can send traffic and how traffic is protected.

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.

Interfaces

IPSec does not run until you attach a profile to an interface.

Table 5

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.

Table 5
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.

Entering IPSec Commands

This section covers the following topics.

Tips on Entering Commands

The following are some tips on using the OpenROUTE command line, which will simplify the process of setting up IPSec.

For more information, see Using the Command Line Interface.

Command Completion

Press Space (once or twice) from any prompt and the software lists the possible completions for the present input. For example,

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 =

Command Line Recall

You can display up to the last 10 command lines you entered using the following keys:


Ctrl u or Up arrow	Go up the command list.
Ctrl n or Down arrow	Go down the command list.

How IPSec Commands Work

When you enter an add or set command, you can include options for the parameter on the same command line. Pressing Space at any time lets you see available options.

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.

The following command adds an IKE transform along with its authentication algorithm, hash algorithm, encryption algorithm, and the lifetime of the transform.

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

Using IPSec Configuration and Monitoring Prompts

You enter IPSec commands at the IPSec Config> and the IPSec> prompts. This section explains the differences between these two prompts and shows how to display the prompts.

IPSec Configuration Prompt

At the IPSec Config> prompt, changes you make are saved in the router's configuration memory. These changes do not take effect until you restart the router.

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>

IPSec Monitoring Prompt

At the IPSec> prompt, changes you make take effect immediately. Unless you explicitly save changes using the save command, they are not saved when you restart the router.

To display the IPSec> prompt,

1. At the + prompt, enter protocol ip.

+PROTOCOL ip

2. Enter ipsec.

IP>ipsec
IPSec>

Simplified Configuration Tasks

The OpenROUTE IPSec configuration is designed to reduce repetitive IPSec configuration tasks. Some examples of this are:

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.

Default Definitions

If you create a new definition, such as a Peer, that requires another definition, IPSec automatically creates the required definition and names it default.

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.

You do not have to use the default definition. You can create your own definition, or you can edit and rename the default definition.

Configuring IPSec

This section shows how to set up IPSec to protect traffic between PCs on a subnet at a branch office and a server at a headquarters office, as shown in the following illustration.

The next sections show how to set up IPSec on the headquarters router and then on the branch office router.

Setting Up the Headquarters Router

Setting Up the Peer

Setting Up an IKE Transform

Setting Up the SA Proposal

Adding a Profile

Setting Up a Policy

Attaching Profiles to Interfaces

Setting Up the Branch Office Router

Setting Up The Peer

Setting Up an IKE Transform

Setting Up the SA Proposal

Adding a Profile

Setting Up a Policy

Attaching Profiles to Interfaces

Setting Up the Headquarters Router

As you set up each side of an IPSec connection, keep in mind that all addresses, names, and matching rules must be mirror images of each other. In order to successfully negotiate security associations, each side must agree on authentication and encryption algorithms and methods.

This section walks you through setting up the Headquarters router to protect traffic between the finance server on the headquarters network and the subnet on the branch network.

This configuration assumes that WAN interface 1 is the default route.

Setting Up the Peer

The IPSec peer is the IPSec router interface at the branch office.

1. Add a peer called westboro.

IPSec Config> add peer westboro
IPSec Config> list peer westboro
                                        Source            Peer Type
Peer                     Peer's         IP Address to     IKE or
Name                     IP Address     use with peer     MANUAL
-----------------------------------------------------------------
westboro                 10.10.10.10    <automatic>       IKE
IKE-transform: default                  IKE-mode: main
IP Filters usage: none                  NAT usage: none
Hardware-assist usage: On               My certificate: default
pre-shared key: 1234

By default, this peer uses the IKE transform called default. The peer also uses a preshared key to negotiate sessions. The default value for the preshared key is 1234. When you set up two OpenROUTE routers to run IPSec, you can get up and running using default settings because the preshared keys match. However, you need to replace these values with a secure key.

2. Set the IP address of the peer, westboro, to the address of the IPSec router interface on the branch network.

IPSec Config> set peer westboro ip_address = 128.185.7.3

Setting Up an IKE Transform

When you add a peer, the IPSec software automatically creates an IKE transform called default that has the following properties.

IPSec Config> list ike
IKE             Priority  Auth   Hash  Encr  DH   Lifetime    Lifetime
Transform Name       Seq  Method  Alg   Alg  Grp   Seconds     Kilobytes
-----------------------------------------------------------------------
default              10  preshare  sha  3des  768   28800        0

The settings for authentication and encryption algorithms and the Diffie-Hellman Group must match an IKE transform at the remote peer.

For this example, we will use the default transform as it is. You can change the properties of the default transform using the set ike_transform command, or you can create a new transform using the add ike_transform command.

Setting Up the SA Proposal

Add an SA proposal called sa_branch.

IPSec Config> add sa_proposal sa_branch
IPSec Config> list sa_proposal sa_branch
SA-proposal name: sa_branch             
 AH_auth: hmac_sha                      ESP_auth: none
 ESP_encr: 3des                         Comp_alg: none
 Lifetime in seconds: 0                 Lifetime in kilobytes:  0
 Perfect Forward Secrecy: none
 Outbound Manual SPI and Key Values:
  AH:   SPI: 00000000 auth_key: no key configured
  ESP:  SPI: 00000000 auth_key: no key configured
                      encr_key: no key configured
  COMP: SPI: 0000
 Inbound Manual SPI and Key Values:
  AH:   SPI: 00000000 auth_key: no key configured
  ESP:  SPI: 00000000 auth_key: no key configured
                      encr_key: no key configured
  COMP: SPI: 0000

In this example, we will use the SA proposal's default settings. In particular, the proposal uses

AH authentication with the HMAC-SHA algorithm,
ESP encryption with the 3DES algorithm, and
IKE rather than manual SA proposals, which means you do not need to enter outbound or inbound manual keys.

Adding a Profile

Add a profile called branch.

IPSec Config> add profile branch

Setting Up a Policy

Policies for each peer are mirror images of each other. Source and destination addresses are usually symmetric. My source address is usually your destination address and vice versa.

1. Add a policy called finance to the profile branch.

When you enter a policy name, you must first specify the profile name to which the policy belongs. You do this by entering the profile name followed by the policy name. Separate the names using a period. For example:

IPSec Config> add policy branch.finance

In this example, branch is the profile name, finance is the policy name.

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

2. Set the policy to use the SA Proposal sa_branch and to use the peer westboro.

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

3. Set the source and destination addresses. These are the addresses of the end stations or subnets that are communicating over IPSec.

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

a. Set the destination address to the address of the server on the headquarters network.

IPSec Config> set policy branch.finance destination = 128.185.21.9

b. Set the source address to the address of the subnet at the branch office.

IPSec Config> set policy branch.finance source = 10.2.2.0&255.255.255.0
IPSec Config> list policy branch.finance
                                  -- *=opaque allowed --
Name            Dir  Address       Port        Protocol  Action
---------------------------------------------------------------
branch.finance  both sa=10.2.2.0&255.255.255.0  Any      protect
                     da=128.185.21.9  
  sa_proposal=sa_branch, peer=westboro

Attaching Profiles to Interfaces

IPSec does not run until you attach a profile to an interface.

IPSec checks packets against profiles in the order in which you add profiles to interfaces. Once IPSec matches a packet to a profile, it takes the action you defined for the profile, which completes IPSec processing for the packet.

Use the following command to attach the profile branch to interface 1.

IPSec Config> set interface 1 profile +=branch
IPSec Config> list interface 1

                    Don't     Path
IPSec    Enable     Frag Bit  MTU
Ifc      Status     Handling  Ageout    Attached IPsec Profiles
----------------------------------------------------------------
1        On         Set       600       branch

Setting Up the Branch Office Router

This section walks you through setting up IPSec on the branch office router to protect traffic between the finance server on the headquarters network and the subnet on the branch network.

This configuration assumes that WAN interface 1 is the default route.

Setting Up The Peer

1. Add a peer called chicago.

IPSec Config> add peer chicago  
IPSec Config> list peer chicago  
                                        Source            Peer Type
Peer                     Peer's         IP Address to     IKE or
Name                     IP Address     use with peer     MANUAL
-----------------------------------------------------------------
chicago                  10.10.10.10    <automatic>       IKE
IKE-transform: default                  IKE-mode: main
IP Filters usage: none                  NAT usage: none
Hardware-assist usage: On               My certificate: default
pre-shared key: none

2. Set the IP address of the peer to the address of the IPSec router interface on the headquarters network.

IPSec Config> set peer chicago ip_address = 128.15.3.1

Setting Up an IKE Transform

When you add a peer, the IPSec software automatically creates an IKE transform called default that has the following properties.

IPSec Config> list ike
IKE             Priority  Auth   Hash  Encr  DH   Lifetime    Lifetime
Transform Name       Seq   Method  Alg   Alg  Grp   Seconds     Kilobytes
-----------------------------------------------------------------------
default              10  dsa_sig  sha  3des  768   28800       0

The settings for authentication and encryption algorithms and the Diffie-Hellman Group must match an IKE transform at the remote peer.

Setting Up the SA Proposal

Add an SA proposal called sa_hq.

IPSec Config> add sa_proposal sa_hq 
IPSec Config> list sa_proposal sa_hq
SA-proposal name: sa_hq                 Proposal Type: IKE
 AH_auth: hmac_sha                      ESP_auth: none
 ESP_encr: 3des                         Comp_alg: none
 Lifetime in seconds: 0                 Lifetime in kilobytes:  0
 Perfect Forward Secrecy: none
 Outbound Manual SPI and Key Values:
  AH:   SPI: 00000000 auth_key: no key configured
  ESP:  SPI: 00000000 auth_key: no key configured
                      encr_key: no key configured
  COMP: SPI: 0000
 Inbound Manual SPI and Key Values:
  AH:   SPI: 00000000 auth_key: no key configured
  ESP:  SPI: 00000000 auth_key: no key configured
                      encr_key: no key configured
  COMP: SPI: 0000

In this example, we will use the SA proposal's default settings. In particular, the proposal uses

AH authentication with the HMAC-SHA algorithm,
ESP encryption with the 3DES algorithm, and
IKE rather than manual SA proposals, which means you do not need to enter outbound or inbound manual keys.

Adding a Profile

Add a profile called hq.

IPSec Config> add profile hq

Setting Up a Policy

1. Add a policy called finance to the profile hq.

IPSec Config> add policy hq.finance

In this example, hq is the profile name, finance is the policy name.

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

2. Set the policy to use the SA Proposal called sa_hq and to use the peer chicago.

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

3. Set the source and destination addresses. These are the addresses of the end stations or subnets that are communicating over IPSec.

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

a. Set the destination address to the address of the subnet on the branch network.

IPSec Config> set policy hq.finance destination = 10.2.2.0&255.255.255.0

b. Set the source address to the address of the server on the headquarters network.

IPSec Config> set policy hq.finance source = 128.185.21.9 
IPSec Config> list policy hq.finance 
                                            -- *=opaque allowed --
Name                     Dir  Address         Port         Protocol  Action
----------------------------------------------------------------------
hq.finance             both   sa=128.185.21.9            Any      protect
                             da= 10.2.2.0&255.255.255.0  
  sa_proposal=sa_hq, peer=chicago

Attaching Profiles to Interfaces

IPSec does not run until you attach a profile to an interface.

IPSec Config> set interface 1 profile +=hq
IPSec Config> list interface 1

                    Don't     Path
IPSec    Enable     Frag Bit  MTU
Ifc      Status     Handling  Ageout    Attached IPsec Profiles
------------------------------------------------------------------
1        Enabled     Set       600      hq

Using IPSec With NAT, IP Filters and Other IP Protocols

This section provides information on using IPSec with NAT and with IP Filters. It also shows how IPSec handles other IP protocols.

Using IPSec With NAT

When you use IPSec with Network Address Translation (NAT), on the same router interface as your IPSec peer, you do not need to configure anything special in NAT. In this case, when you attach an IPSec profile to an interface on which NAT is running, the NAT software automatically creates services that let IPSec traffic pass through the NAT interface. These services are UDP port 500 for IKE traffic and the AH, ESP, and IPCOMP protocols.

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

Applying NAT to IPSec-protected Traffic

In your IPSec configuration you can set whether or not to apply NAT to IPSec-protected traffic to or from select peers. By default the router does not apply NAT to IPSec traffic. If you do set up IPSec to apply NAT to a peer, the router applies NAT to the application IP header, which is the inner IP header, and not to IPSec headers.

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

If you are running IPSec and IP filters on the same router interface, no changes in your IP filter configuration are necessary to get IPSec up and running on the same interface.

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.

Using Other IP Protocols With IPSec

IPSec automatically passes the following IP protocols without applying IPSec protection to them:

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

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

IPSec Commands

Table 6 describes the 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 6 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-transform-sequences.

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 policies 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.

Show [M] Displays the current status of active IKE SA sessions and IPSec SA sessions.

Table 6 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-transform-sequences.
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 policies 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.
Show [M]	Displays the current status of active IKE SA sessions and IPSec SA sessions.

Add Peer [C]

Adds and defines IPSec peers. See Peer Parameters for an overview of the options you can set for peers.

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

ip_address

Adds the destination address of the peer. This parameter determines where IPSec sends protected traffic. If the address is dynamic, enter 0.0.0.0.

The default destination address is 10.10.10.10

Syntax: ip_address =

ipaddress

Example: add peer chicago ipaddress=0.0.0.0

ike_mode

Sets the method IKE uses to negotiate phase 1 with this peer to main or aggressive. For more information, see Using Main or Aggressive Mode for IKE Phase 1.

If your router is the initiator, and you are using aggressive mode, make sure the Diffie-Hellman key size in your IKE transform matches the key size of the peer. If they do not match, the peer will reject the IKE proposal.

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.

Syntax: mode =

aggressive
main


Entry	Description
aggressive	For IKE Phase 1 negotiations, IKE performs a more limited negotiation. You would typically use this setting for remote users dialing in to a corporate network.
main	For IKE Phase 1 negotiations, IKE performs a full phase 1 negotiation. This is the default setting.

Example: add peer chicago mode=aggressive

peer_type

Sets whether IPSec uses a manual SA proposal or uses IKE phase 2 to negotiate the security association to use with this peer.

Syntax: peer_type =

ike
manual

Example: add peer chicago peer_type = 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.

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

Assigns the name of the IKE transform to use for this peer. Use the default IKE transform or a sequence that you defined using the add ike_transform command. To see the default IKE transform, enter list ike_transforms default. You can assign the same IKE transform to more than one peer.

Syntax: ike_transform =

default
transform name


Entry	Description
default	The IPSec software automatically creates an IKE transform called default. You can use the default transform as it is, modify the default, or create a new transform. See Default Definitions.
transform name	Enter the name of an IKE transform that you previously created.

Example: add peer chicago ike_transform =

pre_shared_key

Adds a shared key for a peer. If you set up the IKE transform for this peer to use the preshared key authentication method, the router uses this key for IKE Phase 1 peer establishment. You set the authentication method IKE uses with the IKE transform auth option.

By default, the router is set up to use preshared keys, and it comes with a default preshared key of 1234. When you set up two OpenROUTE routers to run IPSec, you can quickly get up and running using 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.

OpenROUTE 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 digit

The following two examples show how to add a key for a peer in ASCII and then in hex format.

Example: add peer chicago pre_shared_key ascii=SiH67HuRtyP5902WmLKJgfdUiphw895KkSdfGgLhW2JVgcg

Example: add peer chicago pre_shared_key hex=87b49ef8359730c2c4dd8a29b4b9a688405195869367040602041895b6c5afce

my_certificate

If IKE is using preshared keys, you do not need a certificate.

This is the name of the certificate IKE Phase 1 peer establishment uses to authenticate this peer. This certificate comes from the Certificate Management software.

When you add a certificate request, the Certificate Management software uses the name default unless you enter a different name. IKE also uses the certificate name default unless you enter a different name here. If you have entered different names, make sure the names in the Certificate Management software and the peer definition match.

Syntax: my_certificate =

default
name

Example: add peer chicago my_certificate = certchicago

Entry Description

default The IPSec software uses the certificate named default.

name If you specifically created a named certificate for this peer in the Certificate Management software, enter that name here.

Entry	Description
default	The IPSec software uses the certificate named default.
name	If you specifically created a named certificate for this peer in the Certificate Management software, enter that name here.

source_ip_address

Explicitly sets the source IP address this router uses when communicating with this peer.

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

Example: add peer chicago source_ip_address = 192.168.32.3

rename

Changes the name of the peer. You can also rename a peer later using the set peer command.

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

Syntax: rename =

newname

Example: add peer chicago rename=boston

ip_filter_usage

If you have IP filters set up on the IPSec interface to which this peer definition is attached, you can set whether or not to apply your filters to the IPSec-protected traffic for this peer.

Syntax: ip_filter_usage =

none
same_as_interface


Entry	Description
none	The router does not apply IP filters to IPSec traffic for this peer. This is the default.
same as interface	If IP filters are configured on the interface, the router applies IP filters to IPSec traffic for this peer. The router applies filters to the application IP header, which is the inner IP header, and not to IPSec headers.

Example: add peer chicago ip_filter_usage = same_as_interface

nat_usage

If you have Network Address Translation (NAT) set up on the IPSec interface to which this peer definition is attached, you can set whether or not to apply NAT to the IPSec-protected traffic for this peer.

Syntax: nat_usage =

none
same_as_interface


Entry	Description
none	The router does not apply NAT to IPSec traffic for this peer. This is the default setting.
same as interface	If NAT is configured on the interface, the router applies NAT to IPSec traffic for this peer. The router applies NAT to the application IP header, which is the inner IP header, and not to IPSec headers.

Example: add peer chicago nat_usage = same_as_interface

hardware_assist

This command applies to router platforms that provide hardware, as well as software, to run compression, encryption, and authentication. It lets you control on a per-peer basis whether the router hardware or software performs these tasks.

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

Some algorithms, such as blowfish, can only run using software. If you use one of these algorithms, IPSec automatically runs the algorithm using software, regardless of this setting.

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.

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

Add sa_proposal [C]

Adds and defines SA proposals. See SA Proposal Parameters for an overview of the options you can set for SA proposals.

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

To use the Authentication Header (AH) protocol as the method of authenticating that data was not altered during transmission and authenticating the origin of communication, use this option to set the algorithm you want AH to use.

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


Entry	Description
hmac_sha	HMAC-Secure Hash Algorithm-1 (SHA)-1. This is the default setting.
hmac_md5	HMAC-MD5 Message-Digest Algorithm (RFC-1828). RSA Data Security, Inc.
none	IPSec does not use the AH protocol method of authentication.

Example: add sa_proposal sa2 AH_auth_method = hmac_sha

ESP_auth_method

If you want to use the Encapsulating Security Payload (ESP) protocol as the method of protecting data from being altered during transmission, use this option to set the algorithm you want ESP to use. The default is HMAC-SHA.

Notes:

OpenROUTE 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.

Syntax: esp_auth_method=

hmac_sha
hmac_md5
none


Entry	Description
hmac_sha	HMAC-Secure Hash Algorithm-1 (SHA)-1.
hmac_md5	RSA Data Security, Inc. HMAC-MD5 Message-Digest Algorithm (RFC-1828).
none	IPSec does not use the ESP protocol method of authentication. This is the default.

Example: add sa_proposal sa2 esp_auth_method=hmac_sha

ESP_encr_method

The ESP encryption algorithm is used to encrypt user data. Select the algorithm you want ESP to use to encrypt the data.

Syntax: ESP_encr_method =

3des
des
blowfish
none


Entry	Description
3des	Triple Data Encryption Standard (3DES). This is the default setting for U.S. versions of IPSec. It performs three DES encryptions on a single block of data. Triple DES is much more secure than DES.
des	Uses a 56-bit key to encrypt data.
blowfish	The default key size for blowfish is 128 for U.S. versions of IPSec and 56 for International versions. For U.S. versions, you can adjust the key size using the key_alg_detail option.
none	Does not encrypt user data.

Example: add sa_proposal sa2 ESP_encr_method = blowfish

compression_method

Sets the compression algorithm used to compress data packets.

Syntax: compression_method=

lzs
none


Entry	Description
lzs	The router uses the STAC-LZS algorithm to compress data.
none	The router does not compress user data to traffic to which this SA proposal applies. This is the default.

Example: add sa_proposal sa2 compression_method=lzs

lifesecs

The duration of the SA measured in seconds. Once IKE phase 2 has negotiated the SA, it remains in affect until this time expires. When this time expires, IKE renegotiates and replaces the SA using IKE phase 2 exchanges.

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 whenever the first limit is reached.

Syntax: lifesecs =

#-of-seconds

Example: add sa_proposal sa2 lifesecs = 32000

lifeKB

The duration of the SA measured in the amount of data sent. Once IKE phase 2 has negotiated the SA, it remains in effect until this amount of data has passed through IPSec. When this lifetime ends, IKE renegotiates and replaces the SA using IKE phase 2 exchanges.

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 whenever the first limit is reached.

Syntax: lifeKB=

#-of-kilobytes

Example: add sa_proposal sa2 lifeKB=329347329834

pfs_group

Sets whether or not IPSec uses Perfect Forward Secrecy (PFS). If IPSec does use PFS, this parameter sets the size of the Diffie-Helman Group IPSec uses to generate future keys. The default is none, which means IPSec does not use PFS.

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.

Syntax: pfs_group =

768_bit_(group_1)
1024_bit_(group_2)
1536_bit_(group_5)
none


Entry	Description
768_bit_(group_1)
1024_bit_(group_2)
1536_bit_(group_5)
none	This is the default.

Example: add sa_proposal sa2 pfs_group = 1024_bit_(group_2)

key_alg_detail

Some algorithms have adjustable key lengths. This option lets you adjust the key length for those algorithms.

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


Entry	Description
what_algorithm	Currently, the only algorithm that has an adjustable key length is the ESP encryption algorithm blowfish. (esp_encr_blowfish)
keysize	Enter the size, in bits, of the key used in a variable key algorithm. Use a multiple of 8 from 56 to 256 (inclusive). Note: International versions of IPSec support only 56-bit key lengths.

Example: add sa_proposal sa2 key_alg_detail what_algorithm = esp_encr_blowfish

outbound_manual_keying

If you are creating a manual SA proposal, use this parameter to enter SPIs and outbound keys.

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.

Syntax: outbound_manual_keying

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


Entry	Description
ah_spi	If you are using AH authentication for this SA, enter an SPI value that the SA carries in the AH header. This AH SPI must match the AH SPI of the peer at the other end of the IPSec connection.
esp_spi	If you are using ESP authentication or encryption for this SA, enter an SPI value that the SA carries in the ESP header. This ESP SPI must match the AH SPI of the peer at the other end of the IPSec connection.
comp_spi	If you are using compression with this SA, enter an SPI value that the SA carries in the compression header. This Comp SPI must match the AH SPI of the peer at the other end of the IPSec connection.
ah_auth_key	If you are using AH authentication for this SA, use this option to enter the key AH uses. The size of the key you enter depends on whether you selected HMAC-MD5 or HMAC-SHA1 for the authentication algorithm. MD5 keys must be 16 bytes (32 hex digits). SHA keys must be 20 bytes (40 hex digits).
esp_auth_key	If you are using ESP authentication for this SA, use this option to enter the key ESP uses. The size of the key you enter depends on whether you selected HMAC-MD5 or HMAC-SHA1 for the authentication algorithm. MD5 keys must be 16 bytes (32 hex digits). SHA keys must be 20 bytes (40 hex digits).
esp_encr_key	If you are using ESP encryption for this SA, use this option to enter the key ESP uses for encryption. DES keys must be 8 bytes (16 hex digits). 3DES keys must be 24 bytes (48 hex digits). If you are using 3DES, note the following about selecting manual keys. The 3DES algorithm performs three DES encryptions on a single block of data using at least two different keys. For 3DES keys, you need to enter 21 bytes, or 42 hex digits. 3DES creates three seven-byte keys using the digits you enter. If the first and second keys or the second and third keys match, the 3DES operation is simply the same as DES. Blowfish keys have a variable key length. To see the key length configured for blowfish, use the list sa_proposal command. To change the key length, use the key_alg_detail option. The following shows what you must enter for each key length. 56-bit keys must be 7 bytes (14 hex digits) 128-bit keys must be 16 bytes (32 hex digits) 256-bit keys must be 32 bytes (64 hex digits.

Example: add sa_proposal sa3 outbound_manual_keying esp_auth_key = 12903748243909384923472827609154098279

inbound_manual_keying

If you are creating a manual SA proposal, use this parameter to enter SPIs and inbound keys.

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.

Syntax: inbound_manual_keying

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


Entry	Description
ah_spi	If you are using AH authentication for this SA, enter an SPI value that the SA carries in the AH header. Inbound AH SPIs must be unique for each SA proposal on this router. At the same time, this AH SPI must match the AH SPI of the peer at the other end of the IPSec connection.
esp_spi	If you are using ESP authentication or encryption for this SA, enter an SPI value that the SA carries in the ESP header. Inbound ESP SPIs must be unique for each SA proposal on this router. At the same time, this ESP SPI must match the ESP SPI of the peer at the other end of the IPSec connection.
comp_spi	If you are using compression with this SA, enter an SPI value that the SA carries in the compression header. Inbound Comp SPIs must be unique for each SA proposal on this router. At the same time, this ESP SPI must match the ESP SPI of the peer at the other end of the IPSec connection.
ah_auth_key	If you are using AH authentication for this SA, use this option to enter the key AH uses. The size of the key you enter depends on whether you selected HMAC-MD5 or HMAC-SHA1 for the authentication algorithm. MD5 keys must be 16 bytes (32 hex digits). SHA keys must be 20 bytes (40 hex digits).
esp_auth_key	If you are using ESP authentication for this SA, use this option to enter the key ESP uses. The size of the key you enter depends on whether you selected HMAC-MD5 or HMAC-SHA1 for the authentication algorithm. MD5 keys must be 16 bytes (32 hex digits). SHA keys must be 20 bytes (40 hex digits).
esp_encr_key	If you are using ESP encryption for this SA, use this option to enter the key ESP uses for encryption. DES keys must be 8 bytes (16 hex digits). 3DES keys must be 24 bytes (48 hex digits). If you are using 3DES, note the following about selecting manual keys. The 3DES algorithm performs three DES encryptions on a single block of data using at least two different keys. For 3DES manual keys, you need to enter 21 bytes, or 42 hex digits. 3DES creates three seven-byte keys using the digits you enter. If the first and second keys or the second and third keys match, the 3DES operation is simply the same as DES. Blowfish keys have a variable key length. To see the key length configured for blowfish, use the list sa_proposal command. To change the key length, use the key_alg_detail option. The following shows what you must enter for each key length. 56-bit keys must be 7 bytes (14 hex digits) 128-bit keys must be 16 bytes (32 hex digits) 256-bit keys must be 32 bytes (64 hex digits.

Example: add sa_proposal sa2 inbound_manual_keying ah_spi = 3368

rename

Changes the name of the SA proposal. You can also rename an SA proposal later using the set sa_proposal command.

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

Syntax: rename =

newname

Example: add sa_proposal sa2 rename=sa3

Add Profile [C]

Adds a profile to your configuration. You then add policies to profiles and attach profiles to interfaces.

Syntax: add profile name

Example: add profile branch

Add Policy [C]

Creates a new policy and lets you define the properties of the policy. Before you use this command, you need to add a profile.

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

Example: add policy branch.finance

action

Defines the action that the policy takes when it recognizes a packet. Most policies use the action protect, which is the default.

Syntax: action =

protect
discard
pass


Entry	Description
protect	Applies the security association to the packet. Protect, for the outbound direction, means to 1. Perform IPSec security transforms (authentication, encryption, compression) on the packet, based on the security defined in the SA proposal for this policy. 2. Send the packet to the IPSec Peer defined in this policy.
discard	Drops the packet and does not compare the packet to any other policies.
pass	Forwards the packet without performing encryption or authentication.

Example: add policy branch.finance action = protect

after

Specifies the position of the policy within the profile. You can place the policy after a specific policy or at the top of the policy list.

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

Syntax: after =

policy name
*


Entry	Description
policy name	Places the policy after this policy.
*	Places the policy at the top of the list.

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

direction

Specifies the direction of the traffic to which the policy applies.

By default IPSec creates SA proposals 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


Entry	Description
both	Recognizes both inbound and outbound traffic. This is the default and recommended setting. If you are using IKE, you must set the direction to both.
outbound	Recognizes outbound traffic.
inbound	Recognizes inbound traffic.

Example: add policy branch.finance direction =outbound

peer

Adds a peer to the policy. You must have previously added the peer using the add peer command.

Syntax: peer =

peername

Example: add policy branch.finance peer =boston

rename

Changes the name of the policy. You can also rename a policy later using the set policy command.

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

Syntax: rename =

newname

Example: add policy branch.finance rename =sales

sa_proposal

Adds SA proposals to the policy. IPSec software automatically creates an SA proposal named default. You can use default or create SA proposals using the add sa_proposal command.

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

Syntax: sa_proposal =

sa proposal name

Example: add policy branch.finance sa_proposal =sa2

This example adds three SA proposals to the policy

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

destination

Applies the policy to traffic sent to this destination. You can add a single IP address and mask or a range of IP addresses. This lets you create a policy for a subnet or for a group of hosts within a range of addresses.

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.

Syntax: destination =

ipaddress
ipaddress&mask
ipaddress-ipaddress


Entry	Description
ipaddress	One address with a default mask of 255.255.255.255.
ipaddress&mask	One address and a mask.
ipaddress-ipaddress	A range of addresses with a default mask of 255.255.255.255.