Hallo, dies ist ein Test.

PWD: /www/data-lst1/unixsoft/unixsoft/kaempfer/.public_html

Running in File Mode
Relative path: ././../../../../../../usr/man/man8/ipsecconf.8
Real path: /usr/share/man/man8/ipsecconf.8
Zurück

'\" te
.\" Copyright (c) 2008, 2021, Oracle and/or its affiliates.
.TH ipsecconf 8 "3 Nov 2021" "Oracle Solaris 11.4" "System Administration Commands"
.SH NAME
ipsecconf \- configure system wide IPsec
policy
.SH SYNOPSIS

.LP
.nf
\fB/usr/sbin/ipsecconf\fR 
.fi

.LP
.nf
\fB/usr/sbin/ipsecconf\fR \fB-a\fR \fIfile\fR [\fB-q\fR]
.fi

.LP
.nf
\fB/usr/sbin/ipsecconf\fR \fB-c\fR \fIfile\fR
.fi

.LP
.nf
\fB/usr/sbin/ipsecconf\fR \fB-d\fR [\fB-i\fR \fItunnel-name\fR] {\fIindex\fR, \fItunnel-name\fR, \fIindex\fR}
.fi

.LP
.nf
\fB/usr/sbin/ipsecconf\fR \fB-f\fR [\fB-i\fR \fItunnel-name\fR]
.fi

.LP
.nf
\fB/usr/sbin/ipsecconf\fR \fB-F\fR
.fi

.LP
.nf
\fB/usr/sbin/ipsecconf\fR \fB-Fa\fR \fIfile\fR [\fB-q\fR]
.fi

.LP
.nf
\fB/usr/sbin/ipsecconf\fR \fB-l\fR [\fB-i\fR \fItunnel-name\fR] [\fB-n\fR]
.fi

.LP
.nf
\fB/usr/sbin/ipsecconf\fR \fB-L\fR [\fB-n\fR]
.fi

.LP
.nf
\fB/usr/sbin/ipsecconf\fR \fB-r\fR \fIfile\fR [\fB-q\fR]
.fi
.SH DESCRIPTION
.sp
.LP
The \fBipsecconf\fR utility configures the IPsec policy for a host or for one of its tunnels. Once the policy is configured, all outbound and inbound datagrams are subject to policy checks as they exit and enter the host or tunnel. For the host policy, if no entry is found, no policy checks will be completed, and all the traffic will pass through. For a tunnel, if no entry is found and there is at least one entry for the tunnel, the traffic will automatically drop. The difference in behavior is because of the assumptions about IPsec tunnels made in many implementations. Datagrams that are being forwarded will not be subjected to policy checks that are added using this command. See \fBdladm\fR(8) for information on how to protect forwarded packets. Depending upon the match of the policy entry, a specific action will be taken.
.sp
.LP
Users with the \fBNetwork IPSec Management\fR rights profile can run this command.
.sp
.LP
Each entry can protect traffic in either one direction (requiring a pair of entries) or by a single policy entry which installs the needed symmetric \fBsadb\fR rules.
.sp
.LP
When the command is issued without any arguments, the list of file policy entries loaded are shown. To display the SPD policy entries use the \fB-l\fR option. Both will display the index number for the entry. To specify a single tunnel's SPD, use the \fB-i\fR option in combination with \fB-l\fR. To specify all SPDs, both host and for all tunnels, use \fB-L\fR.
.sp
.LP
Note, since one file policy entry (\fBFPE\fR) can generate multiple SPD pol entries (\fBSPE\fRs), the list of FPEs may not show all the actual entries. However, it is still useful in determining what what rules have been added to get the spd into its current state.
.sp
.LP
You can use the \fB-d\fR option with the index to delete a given policy in the system. If the \fB-d\fR option removes an FPE entry that produces multiple SPEs, only then SPD with the same policy index as the FPE will be removed. This can produce a situation where there may be SPEs when there are no FPEs.
.sp
.LP
As with \fB-l\fR, \fB-d\fR can use the \fB-i\fR flag to indicate a tunnel. An alternate syntax is to specify a tunnel name, followed by a comma (\fB,\fR), followed by an index. For example, \fBip.tun0,1\fR.
.sp
.LP
With no options, the entries are displayed in the order that they were added, which is not necessarily the order in which the traffic match takes place.
.sp
.LP
To view the order in which the traffic match will take place, use the \fB-l\fR option. The rules are ordered such that all bypass rules are checked first, then ESP rules, then AH rules. After that, they are checked in the order entered.
.sp
.LP
Policy entries are not preserved across system restarts. Permanent policy entries should be added to \fB/etc/inet/ipsecinit.conf\fR. This file is read by the following \fBsmf\fR(7) service:
.sp
.in +2
.nf
svc:/network/ipsec/policy
.fi
.in -2
.sp
.sp
.LP
See \fBNOTES\fR for more information on managing IPsec security policy and \fBSECURITY\fR for issues in securing \fB/etc/inet/ipsecinit.conf\fR.
.SH OPTIONS
.sp
.LP
\fBipsecconf\fR supports the following options:
.sp
.ne 2
.mk
.na
\fB\fB-a\fR \fIfile\fR\fR
.ad
.br
.sp .6
.RS 4n
Add the IPsec policy to the system as specified by each entry in the file. An IPsec configuration file contains one or more entries that specify the configuration. Once the policy is added, all outbound and inbound datagrams are subject to policy checks.
.sp
Policy is latched for TCP/UDP sockets on which a \fBconnect\fR(3C) or \fBaccept\fR(3C) is issued. So, the addition of new policy entries may not affect such endpoints or sockets. However, the policy will be latched for a socket with an existing non-null policy. Thus, make sure that there are no preexisting connections that will be subject to checks by the new policy entries.
.sp
The feature of policy latching explained above may change in the future. It is not advisable to depend upon this feature.
.sp
The default behavior is to append new rules to the existing policy. If a new rule conflicts with an existing rule, an error is reported, the new rule will not be added.
.sp
To add a new rule that conflicts with an existing rule, the existing rule must be removed (see below) or the existing policy flushed. If the policy is flushed, IPsec will not protect any network traffic until a new policy is added.
.sp
The \fB-F\fR (flush) flag can be combined with \fB-a\fR to perform an atomic policy replacement; the existing policy will be replaced by the new policy described in the config file. By combining these two flags, there is not even a small window when the system is without a policy, which is the case when the flush and add commands are run sequentially.
.RE

.sp
.ne 2
.mk
.na
\fB\fB-c\fR \fIfile\fR\fR
.ad
.br
.sp .6
.RS 4n
Check the syntax of the configuration file and report any errors without making any changes to the policy. This option is useful when debugging configurations and when \fBsmf\fR(7) reports a configuration error. See \fBSECURITY\fR.
.RE

.sp
.ne 2
.mk
.na
\fB\fB-d\fR \fIindex\fR\fR
.ad
.br
.sp .6
.RS 4n
Delete the host policy denoted by the index. The index is obtained by invoking \fBipsecconf\fR without any arguments, or with the \fB-l\fR option. See DESCRIPTION for more information. Once the entry is deleted, all outbound and inbound datagrams affected by this policy entry will not be subjected to policy checks. Be advised that with connections for which the policy has been latched, packets will continue to go out with the same policy, even if it has been deleted. It is advisable to use the \fB-l\fR option to find the correct policy index.
.RE

.sp
.ne 2
.mk
.na
\fB\fB-d\fR \fIname\fR,\fIindex\fR\fR
.ad
.br
.sp .6
.RS 4n
Delete the policy entry denoted by \fIindex\fR on a tunnel denoted by \fIname\fR. Since tunnels affect traffic that might originate off-node, latching does not apply as it does in the host policy case. Equivalent to: \fB-d\fR  \fIindex\fR  \fB-i\fR  \fIname\fR.
.RE

.sp
.ne 2
.mk
.na
\fB\fB-f\fR\fR
.ad
.br
.sp .6
.RS 4n
Flush all the policies in the system. Constraints are similar to the \fB-d\fR option with respect to latching and host versus per-tunnel behavior.
.RE

.sp
.ne 2
.mk
.na
\fB\fB-F\fR\fR
.ad
.br
.sp .6
.RS 4n
Flush all policies on all tunnels and also flush all host policies. See discussion of combining the \fB-F\fR and \fB-a\fR options, under \fB-a\fR, above.
.RE

.sp
.ne 2
.mk
.na
\fB\fB-i\fR \fIname\fR\fR
.ad
.br
.sp .6
.RS 4n
Specify a tunnel interface name for use with the \fB-d\fR, \fB-f\fR, or \fB-l\fR flags.
.RE

.sp
.ne 2
.mk
.na
\fB\fB-l\fR\fR
.ad
.br
.sp .6
.RS 4n
Listing of a single policy table, defaulting to the host policy. When \fBipsecconf\fR is invoked without any arguments, a complete list of policy entries with indexes added by the user since boot is displayed. The current table can differ from the previous one if, for example, a multi-homed entry was added or policy reordering occurred, or if a single rule entry generates two \fBspd\fR rules. In the case of a multi-homed entry, all the addresses are listed explicitly. If a mask was not specified earlier but was instead inferred from the address, it will be explicitly listed here. This option is used to view policy entries in the correct order. The outbound and inbound policy entries are listed separately.
.RE

.sp
.ne 2
.mk
.na
\fB\fB-L\fR\fR
.ad
.br
.sp .6
.RS 4n
Lists all policy tables, including host policy and all tunnel instances (including configured but unplumbed).
.sp
If \fB-i\fR is specified, \fB-L\fR lists the policy table for a specific tunnel interface.
.RE

.sp
.ne 2
.mk
.na
\fB\fB-n\fR\fR
.ad
.br
.sp .6
.RS 4n
Show network addresses, ports, protocols in numbers. The \fB-n\fR option may only be used with the \fB-l\fR option. 
.RE

.sp
.ne 2
.mk
.na
\fB\fB-q\fR\fR
.ad
.br
.sp .6
.RS 4n
Quiet mode. Suppresses the warning message generated when adding policies.
.RE

.sp
.ne 2
.mk
.na
\fB\fB-r\fR \fIfile\fR\fR
.ad
.br
.sp .6
.RS 4n
Remove IPsec policy rules from the system as specified by each entry in \fIfile\fR. The format of the file contents is the same as is specified with the \fB-a\fR option. The file could be created with \fBipsecconf\fR  \fB-l\fR and then modified with an editor.
.RE

.SH OPERANDS
.sp
.LP
Each policy entry contains three parts specified as follows:
.sp
.in +2
.nf
{pattern} action {properties}
.fi
.in -2
.sp
.sp
.LP
or
.sp
.in +2
.nf
{pattern} action {properties} ["or" action {properties}]*
.fi
.in -2
.sp
.sp
.LP
Every policy entry begins on a new line and can span multiple lines. If an entry exceeds the length of a line, you should split it only within a "braced" section or immediately before the first (left-hand) brace of a braced section. Avoid using the backslash character (\e). See EXAMPLES.
.sp
.LP
The \fIpattern\fR section, as shown in the syntax above, specifies the traffic pattern that should be matched against the outbound and inbound datagrams. If there is a match, a specific \fIaction\fR determined by the second argument will be taken, depending upon the \fIproperties\fR of the policy entry.
.sp
.LP
If there is an \fBor\fR in the rule (multiple action-properties for a given pattern), a transmitter will use the first action-property pair that works, while a receiver will use any that are acceptable.
.sp
.LP
\fIpattern\fR and \fIproperties\fR are name-value pairs where name and value are separated by a <space>, <tab> or <newline>. Multiple name-value pairs should be separated by <space>, <tab> or <newline>. The beginning and end of the pattern and properties are marked by \fB{\fR and \fB}\fR respectively. 
.sp
.LP
Files can contain multiple policy entries. An unspecified name-value pair in the \fIpattern\fR will be considered as a wildcard. Wildcard entries match any corresponding entry in the datagram.
.sp
.LP
One thing to remember is that UDP port 500 is always bypassed for the key management daemons themselves regardless of any policy entries. This is a requirement for \fBin.iked\fR(8) to work.
.sp
.LP
File can be commented by using a \fB#\fR as the first character. Comments may be inserted either at the beginning or the end of a line.
.sp
.LP
The complete syntax of a policy entry is:
.sp
.in +2
.nf
policy ::= { <pattern1> } <action1> { <properties1> } |
     { <pattern2> } <action2> { <properties2> }
     [ 'or' <action2> { <properties2>} ]*

pattern1 ::=  <pattern_name_value_pair1>*

pattern2 ::=  <pattern_name_value_pair2>*

properties1 ::=   {<prop_name_value_pair1>}
     properties2 ::=   {<prop_name_value_pair2>}

address ::=  <IPv4 dot notation> | <IPv6 colon notation> |
                  <String recognized by gethostbyname>|
                  <String recognized by getnetbyname>

prefix ::=  <number>

mask ::= <0xhexdigit[hexdigit]> | <0Xhexdigit[hexdigit]> |
              <IPv4 dot notation>

port ::= <number>| <String recognized by getservbyname>

protocol ::=  <number>| <String recognized by getprotobyname>

prop_name_value_pair2 ::=
          auth_algs <auth_alg> |
          encr_algs <encr_alg> |
          encr_auth_algs <auth_alg> |
          sa <sa_val>

auth_alg ::=  <auth_algname>
     auth_algname ::= <auth_algname>

encr_alg ::= <encr_algname> ['(' <keylen> ')']
     encr_algname ::= <encr_algname> ['(' <keylen> ')']

keylen ::= <number> | <number>'..' | '..'<number> | <number>'..' \e
     <number>

sa_val ::= shared | unique

dir_val1 ::= out | in
     dir_val2 ::= out | in | both
     version  ::= 1 | 2

icmp-code ::= <number> | net-unr | host-unr | proto-unr | port-unr |
                   needfrag | srcfail | net-unk | host-unk | isolate |
                   net-prohib | host-prohib | net-tos | host-tos |
                   filter-prohib | host-preced | cutoff-preced |
                   no-route6 | adm-prohib6 | addr-unr6 | port-unr6 |
                   hop-limex6 | frag-re-timex6 | err-head6 | unrec-head6 |
                   unreq-opt6
.fi
.in -2
.sp
.sp
.LP
Policy entries may contain the following (name value) pairs in the \fIpattern\fR field. Each (name value) pair may appear only once in given policy entry.
.sp
.ne 2
.mk
.na
\fBladdr/plen\fR
.ad
.br
.na
\fBlocal/plen\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the local address of the datagram with the prefix length. Only plen leading bits of the source address of the packet will be matched. plen is optional. Local means destination on incoming and source on outgoing packets. The source address value can be a hostname as described in getaddrinfo(3SOCKET) or a network name as described in \fBgetnetbyname\fR(3C) or a host address or network address in the Internet standard dot notation. See \fBinet_addr\fR(3C). If a hostname is given and \fBgetaddrinfo\fR(3C) returns multiple addresses for the host, then policy will be added for each of the addresses with other entries remaining the same.
.RE

.sp
.ne 2
.mk
.na
\fBraddr/plen\fR
.ad
.br
.na
\fBremote/plen\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the remote address of the datagram with the prefix length. Only plen leading bits of the remote address of the packet will be matched. plen is optional. Remote means source on incoming packets and destination on outgoing packets. The remote address value can be a hostname as described in \fBgetaddrinfo\fR(3C) or a network name as described in \fBgetnetbyname\fR(3C) or a host address or network address in the Internet standard dot notation. See \fBinet_addr\fR(3C). If a hostname is given and \fBgetaddrinfo\fR(3C) returns multiple addresses for the host, then policy will be added for each of the addresses with other entries remaining the same.
.RE

.sp
.ne 2
.mk
.na
\fBsrc/plen\fR
.ad
.br
.na
\fBsrcaddr/plen\fR
.ad
.br
.na
\fBsaddr/plen\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the source address of the datagram with the prefix length. Only \fIplen\fR leading bits of the source address of the packet will be matched. \fIplen\fR is optional.
.sp
The source address value can be a hostname as described in \fBgetaddrinfo\fR(3C) or a network name as described in \fBgetnetbyname\fR(3C) or a host address or network address in the Internet standard dot notation. See \fBinet_addr\fR(3C).
.sp
If a hostname is given and \fBgetaddrinfo\fR(3C) returns multiple addresses for the host, then policy will be added for each of the addresses with other entries remaining the same.
.RE

.sp
.ne 2
.mk
.na
\fBdaddr/plen\fR
.ad
.br
.na
\fBdest/plen\fR
.ad
.br
.na
\fBdstaddr/plen\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the destination address of the datagram with the prefix length. Only \fIplen\fR leading bits of the destination address of the packet will be matched. \fIplen\fR is optional.
.sp
See \fIsaddr\fR for valid values that can be given. If multiple source and destination addresses are found, then a policy entry that covers each source address-destination address pair will be added to the system.
.RE

.sp
.ne 2
.mk
.na
\fB\fIsmask\fR\fR
.ad
.br
.sp .6
.RS 4n
For IPv4 only. The value that follows is the source mask. If prefix length is given with \fIsaddr\fR, this should not be given. This can be represented either in hexadecimal number with a leading \fB0x\fR or \fB0X\fR, for example, \fB0xffff0000\fR, \fB0Xffff0000\fR or in the Internet decimal dot notation, for example, \fB255.255.0.0\fR and \fB255.255.255.0\fR. The mask should be contiguous and the behavior is not defined for non-contiguous masks.
.sp
\fIsmask\fR is considered only when \fIsaddr\fR is given.
.sp
For both IPv4 and IPv6 addresses, the same information can be specified as a \fIslen\fR value attached to the \fIsaddr\fR parameter.
.RE

.sp
.ne 2
.mk
.na
\fB\fIdmask\fR\fR
.ad
.br
.sp .6
.RS 4n
Analogous to \fIsmask.\fR
.RE

.sp
.ne 2
.mk
.na
\fB\fIlport\fR\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the local port of the datagram. This can be either a port number or a string searched with a \fBNULL\fR proto argument, as described in \fBgetservbyname\fR(3C).
.RE

.sp
.ne 2
.mk
.na
\fB\fIrport\fR\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the remote port of the datagram. This can be either a port number or a string searched with a \fBNULL\fR proto argument, as described in \fBgetservbyname\fR(3C).
.RE

.sp
.ne 2
.mk
.na
\fB\fIsport\fR\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the source port of the datagram. This can be either a port number or a string searched with a \fBNULL\fR proto argument, as described in \fBgetservbyname\fR(3C).
.RE

.sp
.ne 2
.mk
.na
\fB\fIdport\fR\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the destination port of the datagram. This can be either a port number or a string as described in \fBgetservbyname\fR(3C) searched with \fBNULL\fR proto argument.
.RE

.sp
.ne 2
.mk
.na
\fB\fBproto\fR \fIulp\fR\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the Upper Layer Protocol that this entry should be matched against. It could be a number or a string as described in \fBgetprotobyname\fR(3C). If no smask or plen is specified, a plen of 32 for IPv4 or 128 for IPv6 will be used, meaning a host. If the \fIulp\fR is \fBicmp\fR or \fBipv6-icmp\fR, any action applying IPsec must be the same for all \fBicmp\fR rules.
.RE

.sp
.ne 2
.mk
.na
\fB\fBtype\fR \fInum\fR or \fInum\fR-\fInum\fR\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the ICMP type that this entry should be matched against. \fBtype\fR must be a number from 0 to 255, or one of the appropriate \fBicmp-type\fR keywords. Also, \fIulp\fR must be present and must specify either \fBicmp\fR or \fBipv6-icmp\fR. A range of types can be specified with a hyphen separating numbers.
.LP
Note -
.sp
.RS 2
.sp
.LP
If \fBicmp-code\fR is to be specified, it must be done in conjunction with \fBicmp-type\fR. The \fBicmp-code\fR should be specified after \fBicmp-type\fR, otherwise an error will occur.

.RE
.RE

.sp
.ne 2
.mk
.na
\fB\fBcode\fR \fInum\fR or \fInum\fR-\fInum\fR\fR
.ad
.br
.sp .6
.RS 4n
The value that follows is the ICMP code that this entry should be matched against. The value following the keyword \fBcode\fR must be a number from 0 to 254 or one of the appropriate \fBicmp-code\fR keywords. Also, \fBtype\fR must be present. A range of codes can be specified with a hyphen separating numbers.
.RE

.sp
.ne 2
.mk
.na
\fB\fBtunnel\fR \fIname\fR\fR
.ad
.br
.sp .6
.RS 4n
Specifies a tunnel network interface, as configured with \fBifconfig\fR(8). If a tunnel of \fIname\fR does not yet exist, the policy entries are added anyway, and joined with the tunnel state when it is created. If a tunnel is unplumbed, its policy entries disappear.
.RE

.sp
.ne 2
.mk
.na
\fB\fBnegotiate\fR \fItunnel\fR\fR
.ad
.br
.na
\fB\fBnegotiate\fR \fItransport\fR\fR
.ad
.br
.sp .6
.RS 4n
For per-tunnel security, specify whether the IPsec SAs protecting the traffic should be tunnel-mode SAs or transport-mode SAs. If transport-mode SAs are specified, no addresses can appear in the policy entry. Transport-mode is backward compatible with Solaris 9, and tunnel IPsec policies configured with \fBifconfig\fR(8) will show up as transport mode entries here.
.RE

.sp
.LP
Policy entries may contain the following (name-value) pairs in the properties field. Each (name-value) pair may appear only once in a given policy entry.
.sp
.ne 2
.mk
.na
\fB\fBauth_algs\fR\fR
.ad
.br
.sp .6
.RS 4n
An acceptable value following this implies that IPsec \fBAH\fR header will be present in the outbound datagram, after the outer IP header. The algorithm specified after the \fBauth_algs\fR keyword will be used to generate an Integrity Check Value (ICV) based on the contents of the original packet. The following algorithms do not encrypt the contents of the packet, just provide a mechanism to verify the packets contents have not been modified in transit. See \fIRFC 2402\fR.
.sp
If \fBauth_algs\fR is used in conjunction with \fBencr_algs\fR, the original payload will be encrypted using the algorithm specified after \fBencr_algs\fR. The ICV generated by AH in this case will be of the encrypted packet and the ESP header that was inserted after the encryption.
.sp
Different authentication algorithms produce different length ICV's. Generally, the longer the ICV, the stronger the authentication. The stronger algorithms usually come with a performance penalty.
.sp
This entry should contain a string.
.sp
.sp
.ne 2
.mk
.na
\fB\fBstring\fR\fR
.ad
.br
.sp .6
.RS 4n
Can be one of the following:
.sp
.sp
.in +2
.nf
  string value:          Algorithm Used:     See RFC:
------------------------------------------------------
sha256 or hmac-sha256     HMAC-SHA256          4868
sha384 or hmac-sha384     HMAC-SHA384          4868
sha512 or hmac-sha512     HMAC-SHA512          4868
aes-xcbc                  AES-XCBC-MAC-96      3566
aes-gmac128               AES-GMAC             4543
aes-gmac192               AES-GMAC             4543
aes-gmac256               AES-GMAC             4543
.fi
.in -2
.sp
.LP
Note -
.sp
.RS 2
.sp
.LP
The values of \fBauth_algs\fR that use the AES-GMAC algorithm all generate the same length ICV, but take different length keys, 128, 192 or 256 bits respectively.

.RE
For backward compatibility reasons, the following deprecated authentication algorithms are also allowed. However, administrators are encouraged to migrate away from these obsolete algorithms as soon as feasible.
.sp
.sp
.in +2
.nf
  string value:            Algorithm Used:          See RFC:
------------------------------------------------------------
sha1 or hmac-sha1 or sha     HMAC-SHA1               2404
.fi
.in -2
.sp
You can use the \fBipsecalgs\fR(8) command to obtain the complete list of authentication algorithms.
.sp
Strings are not case-sensitive.
.RE

If \fBauth_algs\fR is not present, the \fBAH\fR header will not be present in the outbound datagram, and the same will be verified for the inbound datagram.
.RE

.sp
.ne 2
.mk
.na
\fB\fBencr_algs\fR\fR
.ad
.br
.sp .6
.RS 4n
An acceptable value following this keyword implies that IPsec ESP header will be present in the outbound datagram. The value describes the encryption algorithm that will be used to encrypt original payload of the outbound datagram. Some of the algorithms listed below also generate an Integrity Check Value (ICV) based on the contents of the encrypted packet and the ESP header. The ICV generated is added to the end of the datagram, after the encrypted payload and can be used by the receiving system to verify the packet has not been modified in transit. See \fIRFC 2406\fR.
.sp
Algorithms that do not generate an ICV as part of the encryption operation should be used in conjunction with an authentication algorithm specified with the \fBencr_auth_algs\fR keyword.
.sp
The following tables list supported encryption only algorithms and combined mode encryption algorithms.
.sp
This entry should contain a string. Strings are not case-sensitive.
.sp
.ne 2
.mk
.na
\fB\fBstring\fR\fR
.ad
.br
.sp .6
.RS 4n
The following encryption algorithms provide encryption only and require an authentication algorithm to generate an ICV. They should be used in conjunction with the \fBencr_auth_algs\fR keyword.
.sp
Each of the following algorithms support key lengths of 128, 192, or 256 bits.
.sp
.sp
.in +2
.nf
  string value:              Algorithm Used:     See RFC:
----------------------------------------------------------
aes or aes-cbc                AES-CBC              2451
camellia or camellia-cbc      Camellia-CBC         4312
.fi
.in -2
.sp
The following combined modes algorithms combine encryption and ICV generation into a single operation. They should not be used in conjunction with the \fBencr_auth_algs\fR keyword.
.sp
Each of the following algorithms support key lengths of 128, 192, or 256 bits.
.sp
.sp
.in +2
.nf

string value:        Algorithm Used:   ICV Length    See RFC:
---------------------------------------------------------------
aes-ccm or aes-ccm16      AES-CCM         16 bytes       4309
aes-ccm8                  AES-CCM          8 bytes       4309
aes-ccm12                 AES-CCM         12 bytes       4309
aes-gcm or aes-gcm16      AES-GCM         16 bytes       4106
aes-gcm8                  AES-GCM          8 bytes       4106
aes-gcm12                 AES-GCM         12 bytes       4106
aes-none-gmac [*]         AES-GMAC        16 bytes       4543
.fi
.in -2
.sp
[*] Generates ICV for authentication only, without encryption. See the example on using AES GMAC, in the Examples section below.
.sp
For backward compatibility reasons, the following deprecated encryption only algorithms are also allowed. However, administrators are encouraged to migrate away from these obsolete algorithms as soon as feasible.
.sp
.sp
.TS
tab(
);
lw(1.83i) lw(1.83i) lw(1.83i) 
lw(1.83i) lw(1.83i) lw(1.83i) 
.
string value:
Algorithm Used:
See RFC:
_
3des or 3des-cbc
3DES-CBC
2451
.TE
.sp
You can use the \fBipsecalgs\fR(8) command to obtain the complete list of authentication algorithms.
.sp
The value can be \fBNULL\fR, which implies a \fBNULL\fR encryption, pursuant to \fIRFC 2410\fR. This means that the payload will not be encrypted. The string can also be \fBANY\fR, which indicates no-preference for the algorithm. Default algorithms will be chosen depending upon the SAs available at the time for manual SAs and upon the key negotiating daemon for automatic SAs. Strings are not case-sensitive.
.RE

.RE

.sp
.ne 2
.mk
.na
\fB\fBencr_auth_algs\fR\fR
.ad
.br
.sp .6
.RS 4n
An acceptable value following \fBencr_auth_algs\fR implies that the IPsec \fBESP\fR header will be present in the outbound datagram. The values following \fBencr_auth_algs\fR describe the authentication algorithms that will be used while applying the IPsec \fBESP\fR protocol on outbound datagrams and verified to be present on inbound datagrams. See \fIRFC 2406\fR. This entry can must contain a string. Strings are case-insensitive.
.sp
.sp
.ne 2
.mk
.na
\fB\fBstring\fR\fR
.ad
.br
.sp .6
.RS 4n
Can be one of the following:
.sp
.sp
.in +2
.nf

string value:        Algorithm Used:     See RFC:
------------------------------------------------------
sha256 or hmac-sha256     HMAC-SHA256          4868
sha384 or hmac-sha384     HMAC-SHA384          4868
sha512 or hmac-sha512     HMAC-SHA512          4868
aes-xcbc                  AES-XCBC-MAC-96      3566

.fi
.in -2
.sp
For backward compatibility reasons, the following deprecated authentication algorithms are also allowed. However, administrators are encouraged to migrate away from these obsolete algorithms as soon as feasible.
.sp
.sp
.in +2
.nf
    string value:             Algorithm Used:     See RFC:
-----------------------------------------------------------
sha1 or hmac-sha1 or sha         HMAC-SHA1          2404
.fi
.in -2
.sp
You can use the \fBipsecalgs\fR(8) command to obtain the complete list of authentication algorithms. Strings are not case-sensitive.
.RE

If \fBencr_algs\fR is present and \fBencr_auth_algs\fR is not present in a policy entry, the system will use an \fBESP\fR  \fBSA\fR regardless of whether the \fBSA\fR has an authentication algorithm or not.
.sp
If \fBencr_algs\fR is not present and \fBencr_auth_algs\fR is present in a policy entry, null encryption will be provided, which is equivalent to \fBencr_algs\fR with \fBNULL\fR, for outbound and inbound datagrams.
.sp
If both \fBencr_algs\fR and \fBencr_auth_algs\fR are not present in a policy entry, \fBESP\fR header will not be present for outbound datagrams and the same will be verified for inbound datagrams.
.sp
If both \fBencr_algs\fR and \fBencr_auth_algs\fR are present in a policy entry, \fBESP\fR header with integrity checksum will be present on outbound datagrams and the same will be verified for inbound datagrams.
.sp
For \fBencr_algs\fR, \fBencr_auth_algs\fR, and \fBauth_algs\fR a key length specification may be present. This is either a single value specifying the only valid key length for the algorithm or a range specifying the valid minimum and/or maximum key lengths. Minimum or maximum lengths may be omitted.
.RE

.sp
.ne 2
.mk
.na
\fB\fBdir\fR\fR
.ad
.br
.sp .6
.RS 4n
Values following this decides whether this policy entry is applied to outbound and/or inbound datagrams. Generally this value should not be specified, because for typical network traffic an IPsec policy should apply to both inbound and outbound traffic. Most common network protocols are bidirectional.
.sp
This entry is not needed when the action is "apply" or "permit" because it is implied with those actions. It is not valid when the action is "ipsec" because this implies both directions.
.sp
The exception is the "bypass" action, when this is mandatory.
.sp
If a direction is specified, great care should be taken to ensure the peer has a matching reverse policy, otherwise IKE negotiation may fail.
.sp
Valid values are strings that should be one of the following:
.sp
.ne 2
.mk
.na
\fB\fBout\fR\fR
.ad
.br
.sp .6
.RS 4n
This means that this policy entry should be considered only for outbound datagrams. This is equivalent to not specifying anything.
.RE

.sp
.ne 2
.mk
.na
\fB\fBin\fR\fR
.ad
.br
.sp .6
.RS 4n
This means that this policy entry should be considered only for inbound datagrams.
.RE

.sp
.ne 2
.mk
.na
\fB\fBboth\fR\fR
.ad
.br
.sp .6
.RS 4n
This means that this policy entry should be considered for both inbound and outbound datagrams
.RE

.RE

.sp
.ne 2
.mk
.na
\fB\fBsa\fR\fR
.ad
.br
.sp .6
.RS 4n
Values following this decide the attribute of the security association. Value indicates whether a unique security association should be used or any existing \fBSA\fR can be used. If there is a policy requirement, \fBSA\fRs are created dynamically on the first outbound datagram using the key management daemon. Static \fBSA\fRs can be created using \fBipseckey\fR(8). The values used here determine whether a new \fBSA\fR will be used/obtained. Valid values are strings that could be one of the following:
.sp
.sp
.ne 2
.mk
.na
\fB\fBunique\fR\fR
.ad
.br
.sp .6
.RS 4n
Unique Association. A new/unused association will be obtained/used for packets matching this policy entry. If an \fBSA\fR that was previously used by the same 5 tuples, that is, {Source address, Destination address, Source port, Destination Port, Protocol (for example, \fBTCP\fR/\fBUDP\fR)} exists, it will be reused. Thus uniqueness is expressed by the 5 tuples given above. The security association used by the above 5 tuples will not be used by any other socket. For inbound datagrams, uniqueness will not be verified.
.sp
For tunnel-mode tunnels, \fBunique\fR is ignored. SAs are assigned per-rule in tunnel-mode tunnels. For transport-mode tunnels, \fBunique\fR is implicit, because the enforcement happens only on the outer-packet addresses and protocol value of either IPv4-in-IP or IPv6-in-IP.
.RE

.sp
.ne 2
.mk
.na
\fB\fBshared\fR\fR
.ad
.br
.sp .6
.RS 4n
Shared association. If an \fBSA\fR exists already for this source-destination pair, it will be used. Otherwise a new \fBSA\fR will be obtained. This is the default.
.RE

This is mandatory only for outbound policy entries and should not be given for entries whose action is "bypass". If this entry is not given for inbound entries, for example, when "dir" is in or "action" is permit, it will be assumed to be shared.
.RE

.sp
.ne 2
.mk
.na
\fB\fBike_version\fR\fR
.ad
.br
.sp .6
.RS 4n
Constrain this policy so that requests for IPsec SAs are only processed by a specific version of IKE daemon. Specify ike_version 1 for \fBin.iked\fR(8) and ike_version 2 for \fBin.ikev2d\fR(8). Lack of this action shall be interpreted as a wild card, that is, any suitably configured daemon can respond.
.RE

.sp
.ne 2
.mk
.na
\fB\fBtfc\fR\fR
.ad
.br
.sp .6
.RS 4n
Enable Traffic Flow Confidentiality (TFC) on this rule. When TFC is enabled, ESP protected packets are padded with dummy data before being encrypted. This helps disguise traffic patterns. The packets are padded to the MTU. The generation, encryption and processing of dummy data requires resources so there is a performance impact. TFC is only supported in tunnel mode.
.RE

.sp
.ne 2
.mk
.na
\fB\fBmtu\fR\fR
.ad
.br
.sp .6
.RS 4n
The only supported value of tfc is padding of the packet to the path MTU of that connection. The value of MTU is calculated by IP. This property is optional. If it is not set, \fBin.ikev2d\fR will send the following notification to its peer when negotiating child SAs:
.sp
.in +2
.nf
IKEV2_ESP_TFC_PADDING_NOT_SUPPORTED
.fi
.in -2
.sp
.RE

.sp
.LP
Action follows the pattern and should be given before properties. It should be one of the following and this field is mandatory.
.sp
.ne 2
.mk
.na
\fB\fBipsec\fR\fR
.ad
.br
.sp .6
.RS 4n
Use IPsec for the datagram as described by the properties, if the pattern matches the datagram. If ipsec is given without a dir spec, the pattern is matched to incoming and outgoing datagrams.
.RE

.sp
.ne 2
.mk
.na
\fB\fBapply\fR\fR
.ad
.br
.sp .6
.RS 4n
Apply IPsec to the datagram as described by the properties, if the pattern matches the datagram. If \fBapply\fR is given, the pattern is matched only on the outbound datagram.
.RE

.sp
.ne 2
.mk
.na
\fB\fBpermit\fR\fR
.ad
.br
.sp .6
.RS 4n
Permit the datagram if the pattern matches the incoming datagram and satisfies the constraints described by the properties. If it does not satisfy the properties, discard the datagram. If \fBpermit\fR is given, the pattern is matched only for inbound datagrams.
.RE

.sp
.ne 2
.mk
.na
\fB\fBbypass\fR\fR
.ad
.br
.na
\fB\fBpass\fR\fR
.ad
.br
.sp .6
.RS 4n
Bypass any policy checks if the pattern matches the datagram. \fBdir\fR in the properties decides whether the check is done on outbound or inbound datagrams. All the \fBbypass\fR entries are checked before checking with any other policy entry in the system. This has the highest precedence over any other entries. \fBdir\fR is the only field that should be present when action is \fBbypass\fR.
.RE

.sp
.ne 2
.mk
.na
\fB\fBdrop\fR\fR
.ad
.br
.sp .6
.RS 4n
Drop any packets that match the pattern.
.RE

.sp
.LP
If the file contains multiple policy entries, for example, they are assumed to be listed in the order in which they are to be applied. In cases of multiple entries matching the outbound and inbound datagram, the first match will be taken.
.sp
.LP
If the new entry has \fBbypass\fR as action, \fBbypass\fR has the highest precedence. It can be added in any order, and the system will still match all the \fBbypass\fR entries before matching any other entries. This is useful for key management daemons which can use this feature to bypass IPsec as it protects its own traffic.
.sp
.LP
Entries with both \fBAH\fR (\fBauth_algs\fR present in the policy entry) and \fBESP\fR (\fBencr_auth_algs\fR or \fBencr_auth_algs\fR present in the policy entry) protection are ordered after all the entries with \fBAH\fR and \fBESP\fR and before any \fBAH\fR-only and \fBESP\fR-only entries. In all other cases the order specified by the user is not modified, that is, newer entries are added at the end of all the old entries.
.sp
.LP
A new entry is considered duplicate of the old entry if an old entry matches the same traffic pattern as the new entry.
.SH SECURITY
.sp
.LP
If, for example, the policy file comes over the wire from an \fBNFS\fR mounted file system, an adversary can modify the data contained in the file, thus changing the policy configured on the machine to suit their needs. Administrators should be cautious about transmitting a copy of the policy file over a network.
.sp
.LP
To prevent non-privileged users from modifying the security policy, ensure that the configuration file is writable only by trusted users.
.sp
.LP
The configuration file is defined by a property of the \fBpolicy\fR  \fBsmf\fR(7) service. The default configuration file, is \fB/etc/inet/ipsecinit.conf\fR. This can be changed using the \fBsvcprop\fR(1) command. See \fBNOTES\fR for more details.
.sp
.LP
The policy description language supports the use of tokens that can be resolved by means of a name service, using functions such as \fBgethostbyname\fR(3C). While convenient, these functions are only secure as the name service the system is configured to use. Great care should be taken to secure the name service if it is used to resolve elements of the security policy.
.sp
.LP
If your source address is a host that can be looked up over the network and your naming system itself is compromised, then any names used will no longer be trustworthy.
.sp
.LP
If the name switch is configured to use a name service that is not local to the system, bypass policy entries might be required to prevent the policy from preventing communication to the name service. See \fBnsswitch.conf\fR(5).
.sp
.LP
Policy is latched for \fBTCP/UDP\fR sockets on which a \fBconnect\fR(3C) or \fBaccept\fR(3C) has been issued. Adding new policy entries will not have any effect on them. This feature of latching may change in the future. It is not advisable to depend upon this feature.
.sp
.LP
The \fBipsecconf\fR command can only be run by a user who has sufficient privilege to open the \fBpf_key\fR(4P) socket. The appropriate privilege can be assigned to a user with the Network IPsec Management profile. See \fBprofiles\fR(1), \fBrbac\fR(7), \fBprof_attr\fR(5).
.sp
.LP
Make sure to set up the policies before starting any communications, as existing connections may be affected by the addition of new policy entries. Similarly, do not change policies in the middle of a communication. 
.sp
.LP
Note that certain \fBndd\fR tunables affect how policies configured with this tool are enforced; see \fBipsecesp\fR(4P) for more details.
.SH EXAMPLES
.LP
\fBExample 1\fR Protecting all Traffic Between Two Hosts by Using ESP

.sp
.LP
The following example specifies that the traffic is protected by using the AES encryption algorithm and authenticated by using SHA256.

.sp
.in +2
.nf
{ laddr spiderweb raddr arachnid } ipsec
    { encr_algs aes encr_auth_algs sha256 }
.fi
.in -2
.sp
.LP
\fBExample 2\fR Authenticating all Inbound Traffic to the Telnet Port by Using AH

.sp
.LP
This entry specifies that any inbound datagram to telnet port should be protected by AH and authenticated with the SHA1 algorithm. Otherwise, the datagram will be discarded. Without this entry, traffic destined to port number 23 would be permitted without any protection. Traffic that does not use port 23 will not match this rule, if this is the only rule, all other traffic will not need IPsec protection.

.sp
.in +2
.nf
#
# All the inbound traffic to the telnet port should be
# authenticated.
#
{ lport telnet dir in } ipsec { auth_algs sha1 }
.fi
.in -2
.sp
.LP
\fBExample 3\fR Verifying Inbound Traffic by Using ESP Null-Encrypted

.sp
.LP
The first entry permits any packets from address host-B to enter the system without IPsec protection. The second entry requires packets from an address machine, the network-B specification to be protected with ESP, NULL encrypted but use \fBsha512\fR for authentication.

.sp
.LP
Null-Encrypted ESP gives a similar level of protection as AH.

.sp
.in +2
.nf
#
# Make sure that all inbound traffic from network-B is NULL
# encrypted, but bypass for host-B alone from that network.
# Add the bypass first.

{ raddr host-B dir in } bypass {}

# Now add for network-B.
{ raddr network-B/16 dir in } ipsec
     { encr_algs NULL encr_auth_algs sha512 }
.fi
.in -2
.sp
.LP
\fBExample 4\fR Entries to Allow DNS Traffic to Bypass IPsec

.sp
.LP
The first two entries permit any datagram leaving the machine with source port 53 or coming into port number 53 to pass without IPsec protection, irrespective of any other policy entry in the system. Thus the latter two entries will be considered only for ports other than port number 53.

.sp
.in +2
.nf
#
# Bypass traffic for port number 53
#
{lport 53 dir out} bypass {}
{rport 53 dir in} bypass {}
{raddr spiderweb } ipsec {encr_algs aes-ccm sa unique}
.fi
.in -2
.sp
.LP
\fBExample 5\fR Protecting Outbound Traffic

.sp
.in +2
.nf
#
# Protect the outbound traffic from all interfaces.
#
{raddr spiderweb dir out} ipsec {auth_algs any sa unique}
{ laddr arachnid raddr spiderweb dir in } ipsec
      {auth_algs sha256 sa unique}
.fi
.in -2
.sp

.sp
.LP
If the \fBgethostbyname\fR(3C) call for spiderweb yields multiple addresses, multiple policy entries will be added for all the source address with the same properties.

.sp
.in +2
.nf
{
    laddr arachnid
    raddr spiderweb
    dir in
} ipsec {auth_algs any sa unique}
.fi
.in -2
.sp

.sp
.LP
If the \fBgethostbyname\fR(3C) call for \fBspiderweb\fR and the \fBgethostbyname\fR(3C) call for \fBarachnid\fR yield multiple addresses, multiple policy entries will be added for each (\fBsaddr\fR  \fBdaddr\fR) pair with the same properties. Use \fBipsecconf\fR  \fB-l\fR to view all the policy entries added.
.LP
\fBExample 6\fR Bypassing Unauthenticated Traffic

.sp
.in +2
.nf
#
# Protect all the outbound traffic with ESP except any traffic
# to network-b which should be authenticated and bypass anything
# to network-c
#
{raddr network-b/16 dir out} ipsec {auth_algs sha256 }
{dir out} ipsec {encr_algs aes-ccm}
{raddr network-c/16 dir out} bypass {}
.fi
.in -2
.sp

.sp
.LP
Note that bypass can be given anywhere and it will take precedence over all other entries. NULL pattern in the second rule matches all the traffic.
.LP
\fBExample 7\fR Encrypting IPv6 Traffic With Camellia and sha256

.sp
.LP
Requires packets between the host with the address \fIfe80::a00:20ff:fe21:4483\fR and the host with the address \fIfe80::a00:20ff:felf:e346\fR to use ESP, encrypted with Camellia and sha256 for authentication.

.sp
.in +2
.nf
{
    laddr fe80::a00:20ff:fe21:4483
    raddr fe80::a00:20ff:felf:e346

} ipsec {
    encr_algs camellia
    encr_auth_algs sha256
}
.fi
.in -2
.sp
.LP
\fBExample 8\fR Verifying IPv6 Traffic uses AH, Authenticated with sha384

.sp
.LP
The following two entries require that all IPv6 traffic to and from the IPv6 site-local network \fBfec0:abcd::0/32\fR be authenticated with sha384.

.sp
.in +2
.nf
{raddr fec0:abcd::0/32} ipsec { auth_algs sha384 }
.fi
.in -2
.sp
.LP
\fBExample 9\fR Key Lengths

.sp
.in +2
.nf
# use aes at any key length defined my ipsecalgs(8)
{raddr spiderweb} ipsec {encr_algs aes encr_auth_algs sha256}
# This has the same effect
{raddr spiderweb} ipsec {encr_algs aes(128..256) encr_auth_algs sha256}

# Only use aes with a 192 bit key
{raddr spiderweb} ipsec {encr_algs aes(192) encr_auth_algs sha256}

# use aes with any key length up to 192 bits
# i.e. 192 bits or less
{raddr spiderweb} ipsec {encr_algs aes(..192) encr_auth_algs sha256}

# use aes with any key length of 192 or more
# i.e. 192 bits or more
{raddr spiderweb} ipsec {encr_algs aes(192..) encr_auth_algs sha256}

#use aes with any key from 192 to 256 bits
{raddr spiderweb} ipsec {encr_algs aes(192..256) encr_auth_algs sha256}

#use any algorithm with a key of 192 bits or longer
{raddr spiderweb} ipsec {encr_algs any(192..) encr_auth_algs sha256}
.fi
.in -2
.sp

.sp
.LP
Note that when using IKE, a policy entry that specifies more than a single key length will generate multiple proposals to its peer. It is up to the peer to select the proposal that most closely matches its local IPsec policy.
.LP
\fBExample 10\fR Correct and Incorrect Policy Entries

.sp
.LP
The following are examples of correctly formed policy entries:

.sp
.in +2
.nf
{ raddr that_system rport telnet } ipsec { encr_algs aes
 encr_auth_algs sha256 sa shared}

{
        raddr that_system
        rport telnet
} ipsec {
        encr_algs aes
        encr_auth_algs sha256
        sa shared
}

{ raddr that_system rport telnet } ipsec
        { encr_algs aes encr_auth_algs sha1 sa shared}

{ raddr that_system rport telnet } ipsec
        { encr_algs 3des encr_auth_algs sha256 sa shared} or ipsec
        { encr_algs aes encr_auth_algs sha256 sa shared}
.fi
.in -2
.sp

.sp
.LP
\&...and the following is an incorrectly formed entry:

.sp
.in +2
.nf
{ raddr that_system rport telnet } ipsec
        { encr_algs 3des encr_auth_algs sha1 sa shared}
        or ipsec { encr_algs aes encr_auth_algs sha1 sa shared}
.fi
.in -2
.sp

.sp
.LP
In the preceding, incorrect entry, note that the third line begins with "\fBor ipsec\fR". Such an entry causes \fBipsecconf\fR to return an error.
.LP
\fBExample 11\fR Allowing Neighbor Discovery to Bypass IPsec

.sp
.LP
The following two entries require that all IPv6 traffic to and from the IPv6 site-local network \fBfec0:abcd::0/32\fR be authenticated with sha256. The second entry allows neighbor discovery to operate correctly.

.sp
.in +2
.nf
{raddr fec0:abcd::0/32} ipsec { auth_algs sha256 }
{raddr fec0:abcd::0/32 ulp ipv6-icmp type 133-137
   dir both } pass { }
.fi
.in -2
.sp
.LP
\fBExample 12\fR Using "or"

.sp
.LP
The following entry allows IPsec traffic using the AES or Camellia algorithms from the remote machine spiderweb. It will also allow unencrypted traffic from spiderweb under certain circumstances:

.sp
.in +2
.nf
{raddr spiderweb} ipsec {encr_auth_algs sha256 encr_algs aes}
        or ipsec {encr_algs camellia} or pass {}
.fi
.in -2
.sp

.sp
.LP
For outgoing traffic initiated from this system, the first packet will trigger an ACQUIRE message to be sent from the kernel to the key management daemon (\fBin.iked\fR(8) or \fBin.ikev2d\fR(8)).

.sp
.LP
The ACQUIRE will contain both algorithm combinations and the peer system will pick one that its acceptable to it and IPsec SAs will be added. The traffic will use those SAs.

.sp
.LP
For inbound traffic, IPsec protected packets will require an SA on the receiving system to decrypt the packet. For protocols that support latching (for example, TCP) the first packet to use an SA will be checked against the policy after it was decrypted, then the policy will be latched. For protocols that do not latch (for example, UDP) packets will always be checked against the inbound policy.

.sp
.LP
The example above has a third action "pass". For inbound traffic, this system will accept IPsec packets or unprotected packets from spiderweb.

.sp
.LP
When this system responds, it will need to make a decision about what IPsec algorithm it uses, if any. The response will use any matching SA that's already in the SADB. If the inbound packet was IPsec protected, there must have been an IKE exchange to generate the SAs. As IPsec SAs are added in pairs, one inbound and one outbound, there should already be an SA in place. The outbound packet will be IPsec protected.

.sp
.LP
Conversely, if there is no SA in place the packet will be sent unprotected. Its important to understand that packet latching plays an important role here.

.sp
.LP
Policy entries that use "pass" as an action are a useful migration tool to allow systems to make use of IPsec if its available. Rules using "pass" as an action should be written with care.
.LP
\fBExample 13\fR Configuring a Tunnel to be Backward-Compatible with
Solaris 9

.sp
.LP
The following example is equivalent to "\fBencr_algs aes encr_auth_algs sha1\fR" in \fBifconfig\fR(8):

.sp
.in +2
.nf
{tunnel ip.tun0 negotiate transport} ipsec
                  {encr_algs aes encr_auth_algs sha1}
.fi
.in -2
.sp
.LP
\fBExample 14\fR Configuring a Tunnel to a VPN client with an Assigned Address

.sp
.LP
The following example assumes a distinct "inside" network with its own topology, such that a client's default route goes "inside".

.sp
.in +2
.nf
# Unlike route(8), the default route has to be spelled-out.
{tunnel ip.tun0 negotiate tunnel raddr client-inside/32
laddr 0.0.0.0/0} ipsec {encr_algs aes encr_auth_algs sha256}
.fi
.in -2
.sp
.LP
\fBExample 15\fR Transit VPN router between Two Tunnelled Subnets and
a Third

.sp
.LP
The following example specifies a configuration for a VPN router that routes between two tunnelled subnets and a third subnet that is on-link. Consider remote-site A, remote-site B, and local site C, each with a \fB/24\fR address allocation.

.sp
.in +2
.nf
# ip.tun0 between me (C) and remote-site A.
# Cover remote-site A to remote-side B.
{tunnel ip.tun0 negotiate tunnel
    raddr A-prefix/24 laddr B-prefix/24} ipsec
     {encr_algs aes encr_auth_algs sha256}

# Cover remote-site A traffic to my subnet.
{tunnel ip.tun0 negotiate tunnel
    raddr A-prefix/24 laddr C-prefix/24}
    ipsec {encr_algs aes encr_auth_algs sha256}

# ip.tun1 between me (C) and remote-site B.
# Cover remote-site B to remote-site A.
{tunnel ip.tun1 negotiate tunnel
    raddr B-prefix/24 laddr A-prefix/24} ipsec
    {encr_algs camellia encr_auth_algs sha256}

# Cover remote-site B traffic to my subnet.
{tunnel ip.tun1 negotiate tunnel
    raddr B-prefix/24 laddr C-prefix/24} ipsec
    {encr_algs camellia encr_auth_algs sha256}
.fi
.in -2
.sp
.LP
\fBExample 16\fR Using Combined Mode Ciphers

.sp
.LP
The parameters used are the same as any other encr_algs value. In both examples, the number in the algorithm token indicates the length of the Integrity Check Value (ICV). See \fBipsecalgs\fR(8).

.sp
.in +2
.nf
# simple example using GCM in transport mode
{laddr 192.168.99.2 raddr 192.168.99.3} ipsec
    {encr_algs aes-gcm sa shared}
# simple example using CCM mode and 128 bit keys
{laddr 192.168.99.100 raddr 192.168.99.200} ipsec
    {encr_algs aes-ccm(128) sa shared}
.fi
.in -2
.sp
.LP
\fBExample 17\fR Using AES GMAC

.sp
.LP
The AES GMAC algorithm is a hash algorithm that provides message authentication. An Integrity Check Vector (ICV) is calculated and transmitted as part of the authenticated packet.

.sp
.LP
The AES GMAC algorithm can be used in ESP mode, in which case the packet data and the ESP header are authenticated. When used with IPsec ESP, AES GMAC can only be specified as an encryption algorithm, even though it does not provide any encryption.

.sp
.in +2
.nf
# \fBsimple example using AES GMAC and 128 bit keys for ESP
\fR
\fB{laddr 192.168.99.100 raddr 192.168.99.200} ipsec\fR
    \fB{encr_algs aes-none-gmac(128) sa shared}\fR
.fi
.in -2
.sp

.sp
.LP
The above example is analogous to the following invalid example:

.sp
.in +2
.nf
{laddr 192.168.99.100 raddr 192.168.99.200} ipsec
    {encr_algs null encr_auth_algs aes-gmac(128) sa shared}
.fi
.in -2
.sp

.sp
.LP
When used with ESP, the \fBaes-none-gmac\fR algorithm takes the key length as an optional argument, the supported key lengths can be displayed using the \fBipsecalgs\fR(8) command.

.sp
.LP
The AES GMAC algorithm can be used in AH mode, in which case the whole packet, including the IP header, is authenticated. When used with IPsec AH, AES GMAC can only be specified as an authentication algorithm.

.sp
.in +2
.nf
# \fBsimple example using AES GMAC and 128 bit keys for AH
\fR
\fB{laddr 192.168.99.100 raddr 192.168.99.200} ipsec\fR
    \fB{auth_algs aes-gmac128 sa shared}\fR
.fi
.in -2
.sp

.sp
.LP
When used with AH, each key length has its own DOI number, the key length does not need to be specified as an argument.
.LP
\fBExample 18\fR Specifying Only IKEv2 to be Used for Keying Material

.sp
.LP
The following example shows policy that specifies that IKEv2 will be used to negotiate keying material for IPsec SAs and any IKEv1 requests for IPsec SAs will be ignored.

.sp
.in +2
.nf
# \fBOnly allow in.ikev2d(8) to respond\fR
\fB{raddr A laddr B} ipsec {encr_algs aes-ccm ike_version 2}\fR
.fi
.in -2
.sp
.SH FILES
.sp
.ne 2
.mk
.na
\fB\fB/var/run/ipsecpolicy.conf\fR\fR
.ad
.br
.sp .6
.RS 4n
Cache of IPsec policies currently configured for the system, maintained by \fBipsecconf\fR command. Do not edit this file.
.RE

.sp
.ne 2
.mk
.na
\fB\fB/etc/inet/ipsecinit.conf\fR\fR
.ad
.br
.sp .6
.RS 4n
File containing IPsec policies to be installed at system restart by the \fBpolicy\fR  \fBsmf\fR(7) service. See \fBNOTES\fR for more information.
.RE

.sp
.ne 2
.mk
.na
\fB\fB/etc/inet/ipsecinit.sample\fR\fR
.ad
.br
.sp .6
.RS 4n
Sample input file for \fBipsecconf\fR.
.RE

.SH ATTRIBUTES
.sp
.LP
See \fBattributes\fR(7) for descriptions of the following attributes:
.sp
.TS
tab(
) box;
cw(2.75i) |cw(2.75i) 
lw(2.75i) |lw(2.75i) 
.
ATTRIBUTE TYPE
ATTRIBUTE VALUE
_
Availability
system/network
_
Interface Stability
Committed
.TE
.sp
.SH SEE ALSO
.sp
.LP
\fBauths\fR(1), \fBprofiles\fR(1), \fBsvcprop\fR(1), \fBsvcs\fR(1), \fBgethostbyname\fR(3C), \fBaccept\fR(3C), \fBconnect\fR(3C), \fBgetaddrinfo\fR(3C), \fBsocket\fR(3C), \fBgethostbyname\fR(3C), \fBgetnetbyname\fR(3C), \fBgetprotobyname\fR(3C), \fBgetservbyname\fR(3C), \fBipsecah\fR(4P), \fBipsecesp\fR(4P), \fBpf_key\fR(4P), \fBike.config\fR(5), \fBnsswitch.conf\fR(5), \fBprof_attr\fR(5), \fBuser_attr\fR(5), \fBattributes\fR(7), \fBrbac\fR(7), \fBsmf\fR(7), \fBifconfig\fR(8), \fBin.iked\fR(8), \fBinit\fR(8), \fBipsecalgs\fR(8), \fBipseckey\fR(8), \fBnetcfg\fR(8), \fBsvcadm\fR(8), \fBsvccfg\fR(8)
.sp
.ne 2
.mk
.na
\fBGlenn, R. and Kent, S. \fIRFC 2410, The NULL Encryption Algorithm and Its Use With IPsec\fR. The Internet Society. 1998.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc2410
.RE

.sp
.ne 2
.mk
.na
\fBKent, S. and Atkinson, R. \fIRFC 2402, IP Authentication Header\fR. The Internet Society. 1998.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc2402
.RE

.sp
.ne 2
.mk
.na
\fBKent, S. and Atkinson, R. \fIRFC 2406, IP Encapsulating Security Payload (ESP)\fR. The Internet Society. 1998.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc2406
.RE

.sp
.ne 2
.mk
.na
\fBMadsen, C. and Glenn, R. \fIRFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH\fR. The Internet Society. 1998.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc2404
.RE

.sp
.ne 2
.mk
.na
\fBMadsen, C. and Doraswamy, N. \fIRFC 2405, The ESP DES-CBC Cipher Algorithm With Explicit IV\fR. The Internet Society. 1998.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc2405
.RE

.sp
.ne 2
.mk
.na
\fBPereira, R. and Adams, R. \fIRFC 2451, The ESP CBC-Mode Cipher Algorithms\fR. The Internet Society. 1998.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc2451
.RE

.sp
.ne 2
.mk
.na
\fBFrankel, S. and Kelly, R. Glenn, \fIRFC 3602, The AES Cipher Algorithm and Its Use With IPsec\fR. The Internet Society. 2003.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc3602
.RE

.sp
.ne 2
.mk
.na
\fBKelly, S. and Frankel, S. \fIRFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec\fR. The Internet Society. 2007.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc4868
.RE

.sp
.ne 2
.mk
.na
\fBKato, A., Moriai, S., and Kanda, M. \fIRFC 4312, The Camellia Cipher Algorithm and Its Use With IPsec\fR. The Internet Society. 2005.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc4312
.RE

.sp
.ne 2
.mk
.na
\fBMcGrew, D., and Viega, J. \fIRFC 4543, The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH\fR. The Internet Society. 2006.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc4543
.RE

.sp
.ne 2
.mk
.na
\fBFrankel, S. and Herbert, H. \fIRFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec\fR. The Internet Society. 2003.\fR
.ad
.br
.sp .6
.RS 4n
https://tools.ietf.org/html/rfc3566
.RE

.SH DIAGNOSTICS
.sp
.ne 2
.mk
.na
\fBBad "string" on line \fIN\fR.\fR
.ad
.br
.na
\fBDuplicate "string" on line \fIN\fR.\fR
.ad
.br
.sp .6
.RS 4n
\fIstring\fR refers to one of the names in pattern or properties. A Bad string indicates that an argument is malformed; a Duplicate string indicates that there are multiple arguments of a similar type, for example, multiple Source Address arguments.
.RE

.sp
.ne 2
.mk
.na
\fBInterface name already selected\fR
.ad
.br
.sp .6
.RS 4n
Dual use of \fB-i\fR  \fIname\fR and \fIname\fR,\fIindex\fR for an interface.
.RE

.sp
.ne 2
.mk
.na
\fBError before or at line \fIN\fR.\fR
.ad
.br
.sp .6
.RS 4n
Indicates parsing error before or at line \fIN\fR. 
.RE

.sp
.ne 2
.mk
.na
\fBNon-existent index\fR
.ad
.br
.sp .6
.RS 4n
Reported when the \fIindex\fR for delete is not a valid one.
.RE

.sp
.ne 2
.mk
.na
\fBspd_msg return: File exists\fR
.ad
.br
.sp .6
.RS 4n
Reported when there is already a policy entry that matches the traffic of this new entry.
.RE

.SH NOTES
.sp
.LP
IPsec manual keys are managed by the service management facility, \fBsmf\fR(7). The services listed below manage the components of IPsec. These services are delivered as follows:
.sp
.in +2
.nf
svc:/network/ipsec/policy:default (enabled)
svc:/network/ipsec/ipsecalgs:default (enabled)
svc:/network/ipsec/manual-key:default (disabled)
svc:/network/ipsec/ike:default (disabled)
.fi
.in -2
.sp
.sp
.LP
The manual-key service is delivered disabled. The system administrator must create manual IPsec Security Associations (SAs), as described in \fBipseckey\fR(8), before enabling that service.
.sp
.LP
The policy service is delivered enabled, but without a configuration file, so that, as a starting condition, packets are not protected by IPsec. After you create the configuration file \fB/etc/inet/ipsecinit.conf\fR, as described in this man page, and refresh the service (\fBsvcadm refresh\fR, see below), the policy contained in the configuration file is applied. If there is an error in this file, the service enters maintenance mode.
.sp
.LP
Services that are delivered disabled are delivered that way because the system administrator must create configuration files for those services before enabling them. See \fBike.config\fR(5) for the \fBike\fR service. 
.sp
.LP
See \fBipsecalgs\fR(8) for the \fBipsecalgs\fR service.
.sp
.LP
The correct administrative procedure is to create the configuration file for each service, then enable each service using \fBsvcadm\fR(8).
.sp
.LP
If the configuration needs to be changed, edit the configuration file then refresh the service, as follows:
.sp
.in +2
.nf
example# \fBsvcadm refresh policy\fR
.fi
.in -2
.sp
.sp
.LP
The \fBsmf\fR(7) framework will record any errors in the service-specific log file. Use any of the following commands to examine the \fBlogfile\fR property:
.sp
.in +2
.nf
example# \fBsvcs -l policy\fR
example# \fBsvcprop policy\fR
example# \fBsvccfg -s policy listprop\fR
.fi
.in -2
.sp
.sp
.LP
The following property is defined for the \fBpolicy\fR service: 
.sp
.in +2
.nf
config/config_file
.fi
.in -2
.sp
.sp
.LP
This property can be modified using \fBsvccfg\fR(8) by users who have been assigned the following authorization:
.sp
.in +2
.nf
solaris.smf.value.ipsec
.fi
.in -2
.sp
.sp
.LP
See \fBauths\fR(1), \fBuser_attr\fR(5), \fBrbac\fR(7).
.sp
.LP
The service needs to be refreshed using \fBsvcadm\fR(8) before the new property is effective. General non-modifiable properties can be viewed with the \fBsvcprop\fR(1) command.
.sp
.in +2
.nf
# \fBsvccfg -s ipsec/policy setprop config/config_file = /new/config_file
\fR
# \fBsvcadm refresh policy\fR
.fi
.in -2
.sp
.sp
.LP
Administrative actions on this service, such as enabling, disabling, refreshing, and requesting restart can be performed using \fBsvcadm\fR(8). A user who has been assigned the authorization shown below can perform these actions:
.sp
.in +2
.nf
solaris.smf.manage.ipsec
.fi
.in -2
.sp
.sp
.LP
The service's status can be queried using the \fBsvcs\fR(1) command.
.sp
.LP
The \fBipsecconf\fR command is designed to be managed by the \fBpolicy\fR  \fBsmf\fR(7) service. While the \fBipsecconf\fR command can be run from the command line, this is discouraged. If the \fBipsecconf\fR command is to be run from the command line, the \fBpolicy\fR  \fBsmf\fR(7) service should be disabled first. See \fBsvcadm\fR(8).