Starts, stops, and monitors IP Security dynamic tunnels which use the Internet Key Exchange Protocol (ISAKMP/Oakley).
ike cmd=Subcommand [ parameter ... ]
The IKE negotiation occurs in two phases. The first phase authenticates the two parties and sets up a Key Management (also known as phase 1) Security Association for protecting the data that is passed during the negotiation. In this phase the key management policy is used to secure the negotiation messages. The second phase negotiates Data Management (also known as the phase 2) Security Association, which uses the data management policy to set up IP Security tunnels in the kernel for encapsulating and decapsulating data packets. The secure channel established in phase 1 can be used to protect multiple data management negotiations between 2 hosts.
The ike command is used to activate tunnels with identification and policy information which has already been entered using the ikedb command or the Web-based System Manager Graphical User Interface (GUI) under Virtual Private Networks (IP Security) in the Network application. The parameters to be used during the negotiation are entered by the user and stored in a database. The ike command allows the activation, removal and listing of tunnels that have been started using the security parameters stored in the database.
In most uses of the ike command, activation and deletion occurs for both phases, however the command allows these operations to be done separately.
| Item | Description |
|---|---|
| Purpose | Start the negotiation of an IKE tunnel. If phase is not specified, both a phase 1 and phase 2 tunnel are started. If IP addresses are supplied, the tunnel is setup using those IP addresses. If the IDs used during the negotiation are not IP addresses, the local and remote host IDs must be entered using the Virtual Private Networks Web-based System Manager Graphical User Interface (GUI) panels. A unique tunnel number is created. The tunnel can then be referenced by the tunnel number in the ike command to indicate the particular tunnel to be started. |
| Syntax | ike cmd=activate [ phase=1|2 ] [numlist=tunnel_num_list] [ namelist=tunnel_name_list ] [ remid=remote_id ] [ipaddr=src_addr,dst_addr] [autostart] |
| Description | The activate subcommand works using a two phase paradigm.
A phase 1 tunnel must be established before a phase 2 tunnel can be
started. If a phase 1 tunnel is specified, then only the phase 1 tunnel
negotiation takes place. If a phase 2 tunnel is specified, the system
checks for the existence of the corresponding phase 1 tunnel before
creating the phase 2 tunnel. If the phase 1 negotiation has not been
started, it is started automatically. Upon successful completion of a phase 2 tunnel, the tunnel definition and corresponding filter rules are inserted into the IP Security kernel, and the new tunnel is activated. Traffic described by the tunnel definition passing between the designated endpoints is protected by the encryption and authentication algorithms indicated by the associated IKE security policy. Multiple phase 2 tunnels can be started under the same phase 1 tunnel. A situation where this may be desired is if different types of traffic between two endpoints need different levels of security protection. The Security Association used for the phase 1 tunnel can be shared by multiple phase 2 tunnels. The phase 2 tunnels would specify the type of traffic (by protocol and port, or subnet mask, for instance) and could have different security policies protecting them. The ike command returns if either a negotiation has been initiated, an error returns, or the tunnel already exists. Since the remote host must be contacted during the negotiation and the amount of time needed to complete the negotiation is uncertain, the list subcommand should be used to determine if the negotiation was successful. Errors that are detected during the negotiation process can be captured by using syslog. |
| Flags |
|
| Examples |
|
| Item | Description |
|---|---|
| Purpose | Monitors the status of IP Security tunnels by phase. It is also used to view tunnel entries defined in the IKE database. |
| Syntax | ike cmd=list [phase=1|1+|2] [numlist= tunnel_num_list] [db | role=i|r] [verbose] |
| Description | The list subcommand queries the Tunnel Manager and lists phase 1 and phase 2 tunnel status and information according to the result of the query. This command can also be used to view information in the Tunnel Definition database. The default behavior is to list the tunnels currently active. To list the tunnels in the database, the db option must be used. |
| Flags |
|
| Examples | Note: Tunnel numbers from the database and tunnel numbers
from the tunnel manager do not necessarily reflect the same tunnel.
|
| Item | Description |
|---|---|
| Purpose | Deactivates specified phase 1 or phase 2 tunnel(s). |
| Syntax | ike cmd=remove [phase=1|2] [numlist= tunnel_num_list] [all] |
| Description | The remove subcommand requests the deactivation of phase 1 or phase 2 tunnel(s). Because phase 2 tunnels are associated with a phase 1 tunnel, if a phase 1 tunnel is deactivated, all phase 2 tunnels under the phase 1 tunnel are not refreshed when the phase 2 tunnel lifetime expires. |
| Flags |
|
| Examples |
|
| Item | Description |
|---|---|
| Purpose | Read the ISAKMP daemon log level from /etc/isamkpd.conf and start logging at that level. |
| Syntax | ike cmd=log |
| Description | The log subcommand causes the ISAKMP daemon to read the log level from /etc/isakmpd.conf, and a filename from /etc/syslog.conf. The logging level specified is set and the log output, along with other syslog output, is placed in the file specified. |
| Item | Description |
|---|---|
| /usr/sbin/ike | Location of the ike admin commands. |
| /etc/isakmpd.conf | Configuration file for the iksakmpd daemon. |
| /etc/syslog.conf | Provides configuration information for the syslogd daemon. |