[Top] [Prev] [Next] [Bottom]

Using IPSec

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

How IPSec Works

Using IPSec With NAT, IP Filters and Other IP Protocols

Entering IPSec Commands

IPSec Commands

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

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

Nx Networks IPSec provides three main functions:

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 software supports three IPSec security and compression protocols:

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

Exporting Algorithms from the United States

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

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 IPSec software, 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

You may want to use the router's internal IP address as the source or destination address in your peer definitions in the following cases:

Table 1 Peer Parameters
Parameter Options Description
ip_address ipaddress

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

peer_id_type ip_address

domain_name

email

keyID

 Tells IPSec the type of ID value you are using for a peer.

peer_id_value ascii_for_peer_id = value

hex_for_peer_id = value

 Identifies peers that IPSec cannot identify using an IP address.

rw_profile profile name

 If this peer is a road warrior peer, specifies the profile to use to create dynamic policies when the road warrior connects.

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

hex = value

Lets you add a shared key for this peer.

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

hardware_assist on

off

 Specifies whether the router hardware or software performs compression, encryption, and authentication tasks.

send_cert_id on

off

 Specifies whether the local IKE peer uses the SubAltName in its certificate as its ID when it negotiates IKE phase 1 with this peer.

match_id on

off

 Specifies whether IKE must match the peer ID to the SubAltName in the peer's certificate.

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

 IKE Phase 1 uses IKE transforms, or proposals, which define the encryption and authentication algorithms and Diffie-Hellman parameters to propose to the peer.

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.

Responder Role In IKE Negotiations

If the router is acting in the responder role during IKE negotiations, the router behaves as follows:

Using Main or Aggressive Mode for IKE Phase 1

 IKE Phase 1 uses two basic methods to establish an authenticated key exchange, main mode and aggressive mode. Both modes generate authenticated keying material from a Diffie-Hellman exchange.

The main differences are

If you do not need identity protection and you do not need to negotiate the Diffie-Hellman group, you can use aggressive mode to reduce the number of messages used in IKE phase 1.

Typically, you would use aggressive mode for remote users dialing in to a corporate network.

IKE Phase 2

IKE Phase 2 uses the information you define in SA proposals to negotiate with the peer. See SA Proposals.

IKE Parameters

An IKE transform contains the following 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

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

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

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.

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.

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.

Anti-Replay Feature

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

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

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:

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.

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.

Overlap Rekeying of SAs

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. The show sa command shows when the software is scheduled to renegotiate the SA.

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

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:

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

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.

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

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

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.

Profile Criteria

The following table shows the parameters you can set for profiles.

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

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

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

A road warrior (RW) is an IPSec peer whose IP address is not known in advance. Since IPSec cannot identify the peer using its IP address, IPSec identifies the peer using a name.

There are two types of road warriors.

Note: For complete information on configuring IPsec road warriors, see Setting Up IPSec.

How Road Warriors Work

 Since road warriors do not know their IP address in advance, IPSec identifies them using names.

Road Warrior Policies

 The policies for road warrior profiles are different from other policies.

To designate a policy as a road warrior policy, you select a road warrior profile type when you set up your profile. For examples on setting up road warrior clients or gateways, see Setting Up IPSec.

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,

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.

Entering IPSec Commands

Beginning with OpenROUTE software release 5.2, you can set up IPSec on most router platforms using QuickWeb. QuickWeb is a configuration tool that lets you use a Web browser to configure OpenROUTE software on your router.

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

 The following tips on using the OpenROUTE software command line will simplify the process of setting up IPSec.

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

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 = RSA_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 Monitor> prompt, enter protocol ip. 

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

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.

IPSec Commands

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

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

peer_id_type

The peer ID identifies a peer. The peer ID type tells IPSec the type of ID you are using for a peer. By default, IPSec identifies a peer using the peer's IP address. For road warrior peers, whose IP address is not known in advance, you can identify a peer using its domain name, e-mail address, or a Key ID.

Notes:

Syntax: peer_id_type =

ip_address
domain_name_(Fully_Qualified_Domain_Name)
email_(User_Fully_Qualified_Domain_Name)
keyID
Example: add peer chicago2 peer_id_type = email_(User_Fully_Qualified_Domain_Name)

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

The peer ID value identifies peers that IPSec cannot identify using an IP address. For users such as road warrior peers, whose IP address is not known in advance, you can identify a peer using its domain name, e-mail address, or a Key ID.

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
Example: add peer chicago peer_id_value ascii_for_peer_id = abc@nxnetworks.com

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

Specifies the road warrior profile IPSec uses to create dynamic policies when this peer completes IKE Phase 1 negotiation and begins Phase 2 negotiation. Phase 2 SA negotiation fails if you do not specify an RW profile for the peer.

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.

Syntax: rw_profile =

profile name
Example: add peer chicago rw_profile = branches

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.

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

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

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 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
The following examples show how to add a key for a peer in ASCII format and then in hex format.

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

If you are using certificates for this peer, specifies the name of the preferred Certificate Authority (CA) for this peer. You need to enter a preferred CA only if you have multiple CAs in the Certificate Management software, and you need to use a specific CA for the peer.

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
Example: add peer chicago preferred_ca = certchicago

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.

send_cert_id

Specifies whether the local IKE peer uses the SubAltName as its ID in its certificate when it negotiates IKE phase 1 with this peer.

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

With this matching set to 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.

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]

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

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

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 as the method of authentication.

Example: add sa_proposal sa2 AH_auth_method = hmac_sha

ESP_auth_method

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

Notes:

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

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

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

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

This Comp SPI must match the Comp 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.

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.

esp_encr_key If you are using ESP encryption for this SA, use this option to enter the key ESP uses for encryption.

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,

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.

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.

esp_encr_key If you are using ESP encryption for this SA, use this option to enter the key ESP uses for encryption.

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

rename

Syntax: rename =

newname
Example: add profile chicago rename=boston

type

Lets you specify the profile type. Use the default of SPD unless you are setting up a road warrior peer, meaning a peer that does not know its IP address in advance.

Syntax: type =

spd
roadwarrior_client
roadwarrior_gateway
Entry Description
spd IPSec directly uses the policies created for the peer in this profile. This is the default.

roadwarrior_client Allows a single user to access the secure network using a dynamic IP address.

If you select roadwarrior client, IPSec accepts only proposals that have an individual IP address as the source address. The proposed source IP address must also be equal to the IP address the RW peer uses.

Other than the source address, IPSec accepts a proposal if the proposed addresses are a subset of addresses defined in the template policy.

roadwarrior_gateway Allows a group of users, such as at a branch office, to access the secure network using dynamic addressing.

If you select roadwarrior gateway, IPSec does not accept proposals that use a wildcard in the source IP address.

IPSec accepts a proposal if the proposed addresses are a subset of addresses defined in the template policy.

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 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
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. When IPSec receives traffic that matches this policy, it sends that traffic to this peer. 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.

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

Applies the policy to traffic that originates from this source. 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: source =

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.

The following example adds a range of IP addresses.

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

The following example adds an IP address with a mask.

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

protocol

Sets the policy to recognize certain transport protocols. This narrows the policy to match only packets of the specified protocol. The protocol, combined with the policy's action lets you protect certain types of traffic or allow other traffic to pass unprotected.

The software recognizes certain well-known protocols that you can enter by name. Enter protocol = SPACE to see a list of well-known protocol names.

Type protocol = space to see a list of protocol names. For example,

IPSec Config> add policy branch.finance protocol =
 Matches the transport protocol

The choices/prefixes are (a partial list):

 TCP
 UDP
 Any
 ENCAP
 ICMP
 IGMP
 SKIP
 OSPF
 AH
 ESP
 IPCOMP
You can also enter a protocol number or any, to recognize all protocols. You cannot enter a range of numbers or a list of comma-separated names or numbers.

The default setting is protocol = any.

Notes:

Syntax: protocol =

name
number
any
Example: add policy branch.finance protocol =tcp

opaque_protocol

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.

The default is opaque on.

Syntax: opaque_protocol =

on
off
Example: add policy branch.finance opaque_protocol = on

dport

Adds, replaces, or removes a destination port for the policy to recognize. You can set ports only for TCP and UDP protocols.

To specify a port, enter the port name or port number. The software recognizes certain well-known ports that you can enter by their name. Enter dport= space to see a list of well-known port names.

If you enter a

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

To remove a port from your policy, type -= followed by the port name or number.

Syntax: dport

=name
=number
-=name
-=number
The following examples show how to enter destination ports using a well-known port name and number.

Example: add policy branch.finance dport = ftp_data

Example: add policy branch.finance protocol = tcp dport = 20

The following example shows how to remove port 20 from the policy.

Example: add policy branch.finance dport -=20

sport

Adds, replaces, or removes a source port for the policy to recognize. You can set ports only for TCP and UDP protocols.

To specify a port, enter the port name or port number. The software recognizes certain well-known ports that you can enter by their name. Enter sport= space to see a list of well-known port names.

If you enter a

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

To remove a port from a policy, type -= before the name or number.