1ipsecconf(1M) System Administration Commands ipsecconf(1M)
2
6 ipsecconf - configure system wide IPsec policy
7
9 /usr/sbin/ipsecconf
10 /usr/sbin/ipsecconf -a file [-q]
13 /usr/sbin/ipsecconf -c file
16 /usr/sbin/ipsecconf -d [-i tunnel-name] {index, tunnel-name, index}
19 /usr/sbin/ipsecconf -f [-i tunnel-name]
22 /usr/sbin/ipsecconf -F
25 /usr/sbin/ipsecconf -l [-i tunnel-name] [-n]
28 /usr/sbin/ipsecconf -L [-n]
31
34 The ipsecconf utility configures the IPsec policy for a host or for one
35 of its tunnels. Once the policy is configured, all outbound and inbound
36 datagrams are subject to policy checks as they exit and enter the host
37 or tunnel. For the host policy, if no entry is found, no policy checks
38 will be completed, and all the traffic will pass through. For a tunnel,
39 if no entry is found and there is at least one entry for the tunnel,
40 the traffic will automatically drop. The difference in behavior is
41 because of the assumptions about IPsec tunnels made in many implementa‐
42 tions. Datagrams that are being forwarded will not be subjected to pol‐
43 icy checks that are added using this command. See ifconfig(1M) and
44 dladm(1M) for information on how to protect forwarded packets. Depend‐
45 ing upon the match of the policy entry, a specific action will be
46 taken.
47 This command can be run only by superuser.
50 Each entry can protect traffic in either one direction (requiring a
53 pair of entries) or by a single policy entry which installs the needed
54 symmetric sadb rules.
55 When the command is issued without any arguments, the list of file pol‐
58 icy entries loaded are shown. To display the (spd p.e.s) use the -l
59 option. Both will display the index number for the entry. To specify a
60 single tunnel's SPD, use the -i option in combination with -l. To spec‐
61 ify all SPDs, both host and for all tunnels, use -L.
62 Note, since one file policy entry (FPE) can generate multiple SPD pol
65 entries (SPEs), the list of FPEs may not show all the actual entries.
66 However, it is still useful in determining what what rules have been
67 added to get the spd into its current state.
68 You can use the -d option with the index to delete a given policy in
71 the system. If the -d option removes an FPE entry that produces multi‐
72 ple SPEs, only then SPD with the same policy index as the FPE will be
73 removed. This can produce a situation where there may be SPEs when
74 there are no FPEs.
75 As with -l, -d can use the -i flag to indicate a tunnel. An alternate
78 syntax is to specify a tunnel name, followed by a comma (,), followed
79 by an index. For example, ip.tun0,1.
80 With no options, the entries are displayed in the order that they were
83 added, which is not necessarily the order in which the traffic match
84 takes place.
85 To view the order in which the traffic match will take place, use the
88 -l option. The rules are ordered such that all bypass rules are checked
89 first, then ESP rules, then AH rules. After that, they are checked in
90 the order entered.
91 Policy entries are not preserved across system restarts. Permanent pol‐
94 icy entries should be added to /etc/inet/ipsecinit.conf. This file is
95 read by the following smf(5) service:
96 svc:/network/ipsec/policy
98 See NOTES for more information on managing IPsec security policy and
103 SECURITY for issues in securing /etc/inet/ipsecinit.conf.
104
106 ipsecconf supports the following options:
107 -a file
109 Add the IPsec policy to the system as specified by each entry in
111 the file. An IPsec configuration file contains one or more entries
112 that specify the configuration. Once the policy is added, all out‐
113 bound and inbound datagrams are subject to policy checks.
114 Entries in the files are described in the section below. Examples
116 can be found in the section below.
117 Policy is latched for TCP/UDP sockets on which a connect(3SOCKET)
119 or accept(3SOCKET) is issued. So, the addition of new policy
120 entries may not affect such endpoints or sockets. However, the pol‐
121 icy will be latched for a socket with an existing non-null policy.
122 Thus, make sure that there are no preexisting connections that will
123 be subject to checks by the new policy entries.
124 The feature of policy latching explained above may change in the
126 future. It is not advisable to depend upon this feature.
127 -c file
130 Check the syntax of the configuration file and report any errors
132 without making any changes to the policy. This option is useful
133 when debugging configurations and when smf(5) reports a configura‐
134 tion error. See SECURITY.
135 -d index
138 Delete the host policy denoted by the index. The index is obtained
140 by invoking ipsecconf without any arguments, or with the -l option.
141 See DESCRIPTION for more information. Once the entry is deleted,
142 all outbound and inbound datagrams affected by this policy entry
143 will not be subjected to policy checks. Be advised that with con‐
144 nections for which the policy has been latched, packets will con‐
145 tinue to go out with the same policy, even if it has been deleted.
146 It is advisable to use the -l option to find the correct policy
147 index.
148 -d name,index
151 Delete the policy entry denoted by index on a tunnel denoted by
153 name. Since tunnels affect traffic that might originate off-node,
154 latching does not apply as it does in the host policy case. Equiva‐
155 lent to: -d index -i name.
156 -f
159 Flush all the policies in the system. Constraints are similar to
161 the -d option with respect to latching and host versus per-tunnel
162 behavior.
163 -F
166 Flush all policies on all tunnels and also flush all host policies.
168 -i name
171 Specify a tunnel interface name for use with the -d, -f, or -l
173 flags.
174 -l
177 Listing of a single policy table, defaulting to the host policy.
179 When ipsecconf is invoked without any arguments, a complete list of
180 policy entries with indexes added by the user since boot is dis‐
181 played. The current table can differ from the previous one if, for
182 example, a multi-homed entry was added or policy reordering
183 occurred, or if a single rule entry generates two spd rules In the
184 case of a multi-homed entry, all the addresses are listed explic‐
185 itly. If a mask was not specified earlier but was instead inferred
186 from the address, it will be explicitly listed here. This option is
187 used to view policy entries in the correct order. The outbound and
188 inbound policy entries are listed separately.
189 -L
192 Lists all policy tables, including host policy and all tunnel
194 instances (including configured but unplumbed).
195 If -i is specified, -L lists the policy table for a specific tunnel
197 interface.
198 -n
201 Show network addresses, ports, protocols in numbers. The -n option
203 may only be used with the -l option.
204 -q
207 Quiet mode. Suppresses the warning message generated when adding
209 policies.
210
213 Each policy entry contains three parts specified as follows:
214 {pattern} action {properties}
216 or
220 {pattern} action {properties} ["or" action {properties}]*
222 Every policy entry begins on a new line and can span multiple lines. If
226 an entry exceeds the length of a line, you should split it only within
227 a "braced" section or immediately before the first (left-hand) brace of
228 a braced section. Avoid using the backslash character (\). See EXAM‐
229 PLES.
230 The pattern section, as shown in the syntax above, specifies the traf‐
233 fic pattern that should be matched against the outbound and inbound
234 datagrams. If there is a match, a specific action determined by the
235 second argument will be taken, depending upon the properties of the
236 policy entry.
237 If there is an or in the rule (multiple action-properties for a given
240 pattern), a transmitter will use the first action-property pair that
241 works, while a receiver will use any that are acceptable.
242 pattern and properties are name-value pairs where name and value are
245 separated by a <space>, <tab> or <newline>. Multiple name-value pairs
246 should be separated by <space>, <tab> or <newline>. The beginning and
247 end of the pattern and properties are marked by { and } respectively.
248 Files can contain multiple policy entries. An unspecified name-value
251 pair in the pattern will be considered as a wildcard. Wildcard entries
252 match any corresponding entry in the datagram.
253 One thing to remember is that UDP port 500 is always bypassed regard‐
256 less of any policy entries. This is a requirement for in.iked(1M) to
257 work.
258 File can be commented by using a # as the first character. Comments may
261 be inserted either at the beginning or the end of a line.
262 The complete syntax of a policy entry is:
265 policy ::= { <pattern1> } <action1> { <properties1> } |
267 { <pattern2> } <action2> { <properties2> }
268 [ 'or' <action2> { <properties2>} ]*
269 pattern1 ::= <pattern_name_value_pair1>*
271 pattern2 ::= <pattern_name_value_pair2>*
273 action1 ::= apply | permit | bypass | pass
275 action2 ::= bypass | pass | drop | ipsec
276 properties1 ::= {<prop_name_value_pair1>}
278 properties2 ::= {<prop_name_value_pair2>}
279 pattern_name_value_pair1 ::=
282 saddr <address>/<prefix> |
283 src <address>/<prefix> |
284 srcaddr <address>/<prefix> |
285 smask <mask> |
286 sport <port> |
287 daddr <address>/<prefix> |
288 dst <address>/<prefix> |
289 dstaddr <address>/<prefix> |
290 dmask <mask> |
291 dport <port> |
292 ulp <protocol> |
293 proto <protocol> |
294 type <icmp-type> |
295 type <number>-<number> |
296 code <icmp-code>
297 code <number>-<number>
298 tunnel <interface-name> |
299 negotiate <tunnel,transport>
300 pattern_name_value_pair2 ::=
302 raddr <address>/<prefix> |
303 remote <address>/<prefix> |
304 rport <port> |
305 laddr <address>/<prefix> |
306 local <address>/<prefix> |
307 lport <port> |
308 ulp <protocol> |
309 type <icmp-type> |
310 type <number>-<number> |
311 code <icmp-code> |
312 code <number>-<number>
313 proto <protocol> |
314 tunnel <interface-name> |
315 negotiate <tunnel,transport> |
316 dir <dir_val2>
317 address ::= <IPv4 dot notation> | <IPv6 colon notation> |
319 <String recognized by gethostbyname>|
320 <String recognized by getnetbyname>
321 prefix ::= <number>
323 mask ::= <0xhexdigit[hexdigit]> | <0Xhexdigit[hexdigit]> |
325 <IPv4 dot notation>
326 port ::= <number>| <String recognized by getservbyname>
328 protocol ::= <number>| <String recognized by getprotobyname>
330 prop_name_value_pair1 ::=
332 auth_algs <auth_alg> |
333 encr_algs <encr_alg> |
334 encr_auth_algs <auth_alg> |
335 sa <sa_val> |
336 dir <dir_val1>
337 prop_name_value_pair2 ::=
339 auth_algs <auth_alg> |
340 encr_algs <encr_alg> |
341 encr_auth_algs <auth_alg> |
342 sa <sa_val>
343 auth_alg ::= <auth_algname> ['(' <keylen> ')']
345 auth_algname ::= any | md5 | hmac-md5 | sha | sha1 | hmac-sha |
346 hmac-sha1 | hmac-sha256 | hmac-sha384 |
347 hmac-sha512 |<number>
348 encr_alg ::= <encr_algname> ['(' <keylen> ')']
350 encr_algname ::= any | aes | aes-cbc | des | des-cbc | 3des |
351 3des-cbc | blowfish | blowfish-cbc | <number>
352 keylen ::= <number> | <number>'..' | '..'<number> | <number>'..' \
354 <number>
355 sa_val ::= shared | unique
357 dir_val1 ::= out | in
359 dir_val2 ::= out | in | both
360 number ::= < 0 | 1 | 2 ... 9> <number>
362 icmp-type ::= <number> | unreach | echo | echorep | squench |
363 redir | timex | paramprob | timest | timestrep |
364 inforeq | inforep | maskreq | maskrep | unreach6 |
365 pkttoobig6 | timex6 | paramprob6 | echo6 | echorep6 |
366 router-sol6 | router-ad6 | neigh-sol6 | neigh-ad6 |
367 redir6
368 icmp-code ::= <number> | net-unr | host-unr | proto-unr | port-unr |
370 needfrag | srcfail | net-unk | host-unk | isolate |
371 net-prohib | host-prohib | net-tos | host-tos |
372 filter-prohib | host-preced | cutoff-preced |
373 no-route6 | adm-prohib6 | addr-unr6 | port-unr6 |
374 hop-limex6 | frag-re-timex6 | err-head6 | unrec-head6 |
375 unreq-opt6
376 Policy entries may contain the following (name value) pairs in the pat‐
380 tern field. Each (name value) pair may appear only once in given policy
381 entry.
382 laddr/plen
384 local/plen
385 The value that follows is the local address of the datagram with
387 the prefix length. Only plen leading bits of the source address of
388 the packet will be matched. plen is optional. Local means destina‐
389 tion on incoming and source on outgoing packets. The source address
390 value can be a hostname as described in getaddrinfo(3SOCKET) or a
391 network name as described in getnetbyname(3XNET) or a host address
392 or network address in the Internet standard dot notation. See
393 inet_addr(3XNET). If a hostname is given and getaddrinfo(3SOCKET)
394 returns multiple addresses for the host, then policy will be added
395 for each of the addresses with other entries remaining the same.
396 raddr/plen
399 remote/plen
400 The value that follows is the remote address of the datagram with
402 the prefix length. Only plen leading bits of the remote address of
403 the packet will be matched. plen is optional. Remote means source
404 on incoming packets and destination on outgoing packets. The remote
405 address value can be a hostname as described in getad‐
406 drinfo(3SOCKET) or a network name as described in getnetby‐
407 name(3XNET) or a host address or network address in the Internet
408 standard dot notation. See inet_addr(3XNET). If a hostname is given
409 and getaddrinfo(3SOCKET) returns multiple addresses for the host,
410 then policy will be added for each of the addresses with other
411 entries remaining the same.
412 src/plen
415 srcaddr/plen
416 saddr/plen
417 The value that follows is the source address of the datagram with
419 the prefix length. Only plen leading bits of the source address of
420 the packet will be matched. plen is optional.
421 The source address value can be a hostname as described in getad‐
423 drinfo(3SOCKET) or a network name as described in getnetby‐
424 name(3XNET) or a host address or network address in the Internet
425 standard dot notation. See inet_addr(3XNET).
426 If a hostname is given and getaddrinfo(3SOCKET) returns multiple
428 addresses for the host, then policy will be added for each of the
429 addresses with other entries remaining the same.
430 daddr/plen
433 dest/plen
434 dstaddr/plen
435 The value that follows is the destination address of the datagram
437 with the prefix length. Only plen leading bits of the destination
438 address of the packet will be matched. plen is optional.
439 See saddr for valid values that can be given. If multiple source
441 and destination addresses are found, then a policy entry that cov‐
442 ers each source address-destination address pair will be added to
443 the system.
444 smask
447 For IPv4 only. The value that follows is the source mask. If prefix
449 length is given with saddr, this should not be given. This can be
450 represented either in hexadecimal number with a leading 0x or 0X,
451 for example, 0xffff0000, 0Xffff0000 or in the Internet decimal dot
452 notation, for example, 255.255.0.0 and 255.255.255.0. The mask
453 should be contiguous and the behavior is not defined for non-con‐
454 tiguous masks.
455 smask is considered only when saddr is given.
457 For both IPv4 and IPv6 addresses, the same information can be spec‐
459 ified as a slen value attached to the saddr parameter.
460 dmask
463 Analogous to smask.
465 lport
468 The value that follows is the local port of the datagram. This can
470 be either a port number or a string searched with a NULL proto
471 argument, as described in getservbyname(3XNET)
472 rport
475 The value that follows is the remote port of the datagram. This can
477 be either a port number or a string searched with a NULL proto
478 argument, as described in getservbyname(3XNET)
479 sport
482 The value that follows is the source port of the datagram. This can
484 be either a port number or a string searched with a NULL proto
485 argument, as described in getservbyname(3XNET)
486 dport
489 The value that follows is the destination port of the datagram.
491 This can be either a port number or a string as described in get‐
492 servbyname(3XNET) searched with NULL proto argument.
493 proto ulp
496 The value that follows is the Upper Layer Protocol that this entry
498 should be matched against. It could be a number or a string as
499 described in getprotobyname(3XNET). If no smask or plen is speci‐
500 fied, a plen of 32 for IPv4 or 128 for IPv6 will be used, meaning a
501 host. If the ulp is icmp or ipv6-icmp, any action applying IPsec
502 must be the same for all icmp rules.
503 type num or num-num
506 The value that follows is the ICMP type that this entry should be
508 matched against. type must be a number from 0 to 255, or one of the
509 appropriate icmp-type keywords. Also, ulp must be present and must
510 specify either icmp or ipv6-icmp. A range of types can be specified
511 with a hyphen separating numbers.
512 code num or num-num
515 The value that follows is the ICMP code that this entry should be
517 matched against. The value following the keyword code must be a
518 number from 0 to 254 or one of the appropriate icmp-code keywords.
519 Also, type must be present. A range of codes can be specified with
520 a hyphen separating numbers.
521 tunnel name
524 Specifies a tunnel network interface, as configured with ifcon‐
526 fig(1M). If a tunnel of name does not yet exist, the policy entries
527 are added anyway, and joined with the tunnel state when it is cre‐
528 ated. If a tunnel is unplumbed, its policy entries disappear.
529 negotiate tunnel
532 negotiate transport
533 For per-tunnel security, specify whether the IPsec SAs protecting
535 the traffic should be tunnel-mode SAs or transport-mode SAs. If
536 transport-mode SAs are specified, no addresses can appear in the
537 policy entry. Transport-mode is backward compatible with Solaris 9,
538 and tunnel IPsec policies configured with ifconfig(1M) will show up
539 as transport mode entries here.
540 Policy entries may contain the following (name-value) pairs in the
544 properties field. Each (name-value) pair may appear only once in a
545 given policy entry.
546 auth_algs
548 An acceptable value following this implies that IPsec AH header
550 will be present in the outbound datagram. Values following this
551 describe the authentication algorithms that will be used while
552 applying the IPsec AH on outbound datagrams and verified to be
553 present on inbound datagrams. See RFC 2402.
554 This entry can contain either a string or a decimal number.
556 string
558 This should be either MD5 or HMAC-MD5 denoting the HMAC-MD5
560 algorithm as described in RFC 2403, and SHA1, or HMAC-SHA1 or
561 SHA or HMAC-SHA denoting the HMAC-SHA algorithm described in
562 RFC 2404. You can use the ipsecalgs(1M) command to obtain the
563 complete list of authentication algorithms.
564 The string can also be ANY, which denotes no-preference for the
566 algorithm. Default algorithms will be chosen based upon the SAs
567 available at this time for manual SAs and the key negotiating
568 daemon for automatic SAs. Strings are not case-sensitive.
569 number
572 A number in the range 1-255. This is useful when new algorithms
574 can be dynamically loaded.
575 If auth_algs is not present, the AH header will not be present in
577 the outbound datagram, and the same will be verified for the
578 inbound datagram.
579 encr_algs
582 An acceptable value following this implies that IPsec ESP header
584 will be present in the outbound datagram. The value following this
585 describes the encryption algorithms that will be used to apply the
586 IPsec ESP protocol to outbound datagrams and verify it to be
587 present on inbound datagrams. See RFC 2406.
588 This entry can contain either a string or a decimal number. Strings
590 are not case-sensitive.
591 string
593 Can be one of the following:
595 string value: Algorithm Used: See RFC:
600 ────────────────────────────────────────────────────────────────────
601 DES or DES-CBC DES-CBC 2405
602 3DES or 3DES-CBC 3DES-CBC 2451
604 BLOWFISH or BLOWFISH-CBC BLOWFISH-CBC 2451
605 AES or AES-CBC AES-CBC 2451
606 You can use the ipsecalgs(1M) command to obtain the complete
608 list of authentication algorithms.
609 The value can be NULL, which implies a NULL encryption, pur‐
611 suant to RFC 2410. This means that the payload will not be
612 encrypted. The string can also be ANY, which indicates no-pref‐
613 erence for the algorithm. Default algorithms will be chosen
614 depending upon the SAs available at the time for manual SAs and
615 upon the key negotiating daemon for automatic SAs. Strings are
616 not case-sensitive.
617 number
620 A decimal number in the range 1-255. This is useful when new
622 algorithms can be dynamically loaded.
623 encr_auth_algs
627 An acceptable value following encr_auth_algs implies that the IPsec
629 ESP header will be present in the outbound datagram. The values
630 following encr_auth_algs describe the authentication algorithms
631 that will be used while applying the IPsec ESP protocol on outbound
632 datagrams and verified to be present on inbound datagrams. See RFC
633 2406. This entry can contain either a string or a number. Strings
634 are case-insensitive.
635 string
637 Valid values are the same as the ones described for auth_algs
639 above.
640 number
643 This should be a decimal number in the range 1-255. This is
645 useful when new algorithms can be dynamically loaded.
646 If encr_algs is present and encr_auth_algs is not present in a pol‐
648 icy entry, the system will use an ESP SA regardless of whether the
649 SA has an authentication algorithm or not.
650 If encr_algs is not present and encr_auth_algs is present in a pol‐
652 icy entry, null encryption will be provided, which is equivalent to
653 encr_algs with NULL, for outbound and inbound datagrams.
654 If both encr_algs and encr_auth_algs are not present in a policy
656 entry, ESP header will not be present for outbound datagrams and
657 the same will be verified for inbound datagrams.
658 If both encr_algs and encr_auth_algs are present in a policy entry,
660 ESP header with integrity checksum will be present on outbound
661 datagrams and the same will be verified for inbound datagrams.
662 For encr_algs, encr_auth_algs, and auth_algs a key length specifi‐
664 cation may be present. This is either a single value specifying the
665 only valid key length for the algorithm or a range specifying the
666 valid minimum and/or maximum key lengths. Minimum or maximum
667 lengths may be omitted.
668 dir
671 Values following this decides whether this entry is for outbound or
673 inbound datagram. Valid values are strings that should be one of
674 the following:
675 out
677 This means that this policy entry should be considered only for
679 outbound datagrams.
680 in
683 This means that this policy entry should be considered only for
685 inbound datagrams.
686 both
689 This means that this policy entry should be considered for both
691 inbound and outbound datagrams
692 This entry is not needed when the action is "apply", "permit" or
694 "ipsec". But if it is given while the action is "apply" or "per‐
695 mit", it should be "out" or "in" respectively. This is mandatory
696 when the action is "bypass".
697 sa
700 Values following this decide the attribute of the security associa‐
702 tion. Value indicates whether a unique security association should
703 be used or any existing SA can be used. If there is a policy
704 requirement, SAs are created dynamically on the first outbound
705 datagram using the key management daemon. Static SAs can be created
706 using ipseckey(1M). The values used here determine whether a new SA
707 will be used/obtained. Valid values are strings that could be one
708 of the following:
709 unique
711 Unique Association. A new/unused association will be
713 obtained/used for packets matching this policy entry. If an SA
714 that was previously used by the same 5 tuples, that is, {Source
715 address, Destination address, Source port, Destination Port,
716 Protocol (for example, TCP/UDP)} exists, it will be reused.
717 Thus uniqueness is expressed by the 5 tuples given above. The
718 security association used by the above 5 tuples will not be
719 used by any other socket. For inbound datagrams, uniqueness
720 will not be verified.
721 For tunnel-mode tunnels, unique is ignored. SAs are assigned
723 per-rule in tunnel-mode tunnels. For transport-mode tunnels,
724 unique is implicit, because the enforcement happens only on the
725 outer-packet addresses and protocol value of either IPv4-in-IP
726 or IPv6-in-IP.
727 shared
730 Shared association. If an SA exists already for this source-
732 destination pair, it will be used. Otherwise a new SA will be
733 obtained. This is the default.
734 This is mandatory only for outbound policy entries and should not
736 be given for entries whose action is "bypass". If this entry is not
737 given for inbound entries, for example, when "dir" is in or
738 "action" is permit, it will be assumed to be shared.
739 Action follows the pattern and should be given before properties. It
743 should be one of the following and this field is mandatory.
744 ipsec
746 Use IPsec for the datagram as described by the properties, if the
748 pattern matches the datagram. If ipsec is given without a dir spec
749 , the pattern is matched to incoming and outgoing datagrams.
750 apply
753 Apply IPsec to the datagram as described by the properties, if the
755 pattern matches the datagram. If apply is given, the pattern is
756 matched only on the outbound datagram.
757 permit
760 Permit the datagram if the pattern matches the incoming datagram
762 and satisfies the constraints described by the properties. If it
763 does not satisfy the properties, discard the datagram. If permit is
764 given, the pattern is matched only for inbound datagrams.
765 bypass
768 pass
769 Bypass any policy checks if the pattern matches the datagram. dir
771 in the properties decides whether the check is done on outbound or
772 inbound datagrams. All the bypass entries are checked before check‐
773 ing with any other policy entry in the system. This has the highest
774 precedence over any other entries. dir is the only field that
775 should be present when action is bypass.
776 drop
779 Drop any packets that match the pattern.
781 If the file contains multiple policy entries, for example, they are
785 assumed to be listed in the order in which they are to be applied. In
786 cases of multiple entries matching the outbound and inbound datagram,
787 the first match will be taken. The system will reorder the policy
788 entry, that is, add the new entry before the old entry, only when:
789 The level of protection is "stronger" than the old level of protection.
792 Currently, strength is defined as:
795 AH and ESP > ESP > AH
797 The standard uses of AH and ESP were what drove this ranking of
802 "stronger". There are flaws with this. ESP can be used either without
803 authentication, which will allow cut-and-paste or replay attacks, or
804 without encryption, which makes it equivalent or slightly weaker than
805 AH. An administrator should take care to use ESP properly. See ipse‐
806 cesp(7P) for more details.
807 If the new entry has bypass as action, bypass has the highest prece‐
810 dence. It can be added in any order, and the system will still match
811 all the bypass entries before matching any other entries. This is use‐
812 ful for key management daemons which can use this feature to bypass
813 IPsec as it protects its own traffic.
814 Entries with both AH (auth_algs present in the policy entry) and ESP
817 (encr_auth_algs or encr_auth_algs present in the policy entry) protec‐
818 tion are ordered after all the entries with AH and ESP and before any
819 AH-only and ESP-only entries. In all other cases the order specified by
820 the user is not modified, that is, newer entries are added at the end
821 of all the old entries. See .
822 A new entry is considered duplicate of the old entry if an old entry
825 matches the same traffic pattern as the new entry. See for information
826 on duplicates.
827
829 If, for example, the policy file comes over the wire from an NFS
830 mounted file system, an adversary can modify the data contained in the
831 file, thus changing the policy configured on the machine to suit his
832 needs. Administrators should be cautious about transmitting a copy of
833 the policy file over a network.
834 To prevent non-privileged users from modifying the security policy,
837 ensure that the configuration file is writable only by trusted users.
838 The configuration file is defined by a property of the policy smf(5)
841 service. The default configuration file, is /etc/inet/ipsecinit.conf.
842 This can be changed using the svcprop(1) command. See NOTES for more
843 details.
844 The policy description language supports the use of tokens that can be
847 resolved by means of a name service, using functions such as gethostby‐
848 name(3NSL). While convenient, these functions are only secure as the
849 name service the system is configured to use. Great care should be
850 taken to secure the name service if it is used to resolve elements of
851 the security policy.
852 If your source address is a host that can be looked up over the network
855 and your naming system itself is compromised, then any names used will
856 no longer be trustworthy.
857 If the name switch is configured to use a name service that is not
860 local to the system, bypass policy entries might be required to prevent
861 the policy from preventing communication to the name service. See nss‐
862 witch.conf(4).
863 Policy is latched for TCP/UDP sockets on which a connect(3SOCKET) or
866 accept(3SOCKET) has been issued. Adding new policy entries will not
867 have any effect on them. This feature of latching may change in the
868 future. It is not advisable to depend upon this feature.
869 The ipsecconf command can only be run by a user who has sufficient
872 privilege to open the pf_key(7P) socket. The appropriate privilege can
873 be assigned to a user with the Network IPsec Management profile. See
874 profiles(1), rbac(5), prof_attr(4).
875 Make sure to set up the policies before starting any communications, as
878 existing connections may be affected by the addition of new policy
879 entries. Similarly, do not change policies in the middle of a communi‐
880 cation.
881 Note that certain ndd tunables affect how policies configured with this
884 tool are enforced; see ipsecesp(7P) for more details.
885
887 Example 1 Protecting Outbound TCP Traffic With ESP and the AES Algo‐
888 rithm
889 The following example specified that any TCP packet from spiderweb to
892 arachnid should be encrypted with AES, and the SA could be a shared
893 one. It does not verify whether or not the inbound traffic is
894 encrypted.
895 #
898 # Protect the outbound TCP traffic between hosts spiderweb
899 # and arachnid with ESP and use AES algorithm.
900 #
901 {
902 laddr spiderweb
903 raddr arachnid
904 ulp tcp
905 dir out
906 } ipsec {
907 encr_algs AES
908 }
909 Example 2 Verifying Whether or Not Inbound Traffic is Encrypted
912 Example 1 does not verify whether or not the inbound traffic is
915 encrypted. The entry in this example protects inbound traffic:
916 #
919 # Protect the TCP traffic on inbound with ESP/DES from arachnid
920 # to spiderweb
921 #
922 {
923 laddr spiderweb
924 raddr arachnid
925 ulp tcp
926 dir in
927 } ipsec {
928 encr_algs AES
929 }
930 sa can be absent for inbound policy entries as it implies that it can
934 be a shared one. Uniqueness is not verified on inbound. Note that in
935 both the above entries, authentication was never specified. This can
936 lead to cut and paste attacks. As mentioned previously, though the
937 authentication is not specified, the system will still use an ESP SA
938 with encr_auth_alg specified, if it was found in the SA tables.
939 Example 3 Protecting All Traffic Between Two Hosts
942 The following example protects both directions at once:
945 {
948 laddr spiderweb
949 raddr arachnid
950 ulp tcp
951 } ipsec {
952 encr_algs AES
953 }
954 Example 4 Authenticating All Inbound Traffic to the Telnet Port
957 This entry specifies that any inbound datagram to telnet port should
960 come in authenticated with the SHA1 algorithm. Otherwise the datagram
961 should not be permitted. Without this entry, traffic destined to port
962 number 23 can come in clear. sa is not specified, which implies that it
963 is shared. This can be done only for inbound entries. You need to have
964 an equivalent entry to protect outbound traffic so that the outbound
965 traffic is authenticated as well, remove the dir.
966 #
969 # All the inbound traffic to the telnet port should be
970 # authenticated.
971 #
972 {
973 lport telnet
974 dir in
975 } ipsec {
976 auth_algs sha1
977 }
978 Example 5 Verifying Inbound Traffic is Null-Encrypted
981 The first entry specifies that any packet with address host-B should
984 not be checked against any policies. The second entry specifies that
985 all inbound traffic from network-B should be encrypted with a NULL
986 encryption algorithm and the MD5 authentication algorithm. NULL encryp‐
987 tion implies that ESP header will be used without encrypting the data‐
988 gram. As the first entry is bypass it need not be given first in order,
989 as bypass entries have the highest precedence. Thus any inbound traffic
990 will be matched against all bypass entries before any other policy
991 entries.
992 #
995 # Make sure that all inbound traffic from network-B is NULL
996 # encrypted, but bypass for host-B alone from that network.
997 # Add the bypass first.
998 {
999 raddr host-B
1000 dir in
1001 } bypass {}
1002 # Now add for network-B.
1004 {
1005 raddr network-B/16
1006 dir in
1007 } ipsec {
1008 encr_algs NULL
1009 encr_auth_algs md5
1010 }
1011 Example 6 Entries to Bypass Traffic from IPsec
1014 The first two entries provide that any datagram leaving the machine
1017 with source port 53 or coming into port number 53 should not be sub‐
1018 jected to IPsec policy checks, irrespective of any other policy entry
1019 in the system. Thus the latter two entries will be considered only for
1020 ports other than port number 53.
1021 #
1024 # Bypass traffic for port no 53
1025 #
1026 {lport 53} bypass {}
1027 {rport 53} bypass {}
1028 {raddr spiderweb } ipsec {encr_algs any sa unique}
1029 Example 7 Protecting Outbound Traffic
1032 #
1034 # Protect the outbound traffic from all interfaces.
1035 #
1036 {raddr spiderweb dir out} ipsec {auth_algs any sa unique}
1037 If the gethostbyname(3XNET) call for spiderweb yields multiple
1041 addresses, multiple policy entries will be added for all the source
1042 address with the same properties.
1043 {
1046 laddr arachnid
1047 raddr spiderweb
1048 dir in
1049 } ipsec {auth_algs any sa unique}
1050 If the gethostbyname(3XNET) call for spiderweb and the gethostby‐
1054 name(3XNET) call for arachnid yield multiple addresses, multiple policy
1055 entries will be added for each (saddr daddr) pair with the same proper‐
1056 ties. Use ipsecconf -l to view all the policy entries added.
1057 Example 8 Bypassing Unauthenticated Traffic
1060 #
1062 # Protect all the outbound traffic with ESP except any traffic
1063 # to network-b which should be authenticated and bypass anything
1064 # to network-c
1065 #
1066 {raddr network-b/16 dir out} ipsec {auth_algs any}
1067 {dir out} ipsec {encr_algs any}
1068 {raddr network-c/16 dir out} bypass {} # NULL properties
1069 Note that bypass can be given anywhere and it will take precedence over
1073 all other entries. NULL pattern matches all the traffic.
1074 Example 9 Encrypting IPv6 Traffic with 3DES and MD5
1077 The following entry on the host with the link local address
1080 fe80::a00:20ff:fe21:4483 specifies that any outbound traffic between
1081 the hosts wtih IPv6 link-local addresses fe80::a00:20ff:fe21:4483 and
1082 fe80::a00:20ff:felf:e346 must be encrypted with 3DES and MD5.
1083 {
1086 laddr fe80::a00:20ff:fe21:4483
1087 raddr fe80::a00:20ff:felf:e346
1088 dir out
1089 } ipsec {
1090 encr_algs 3DES
1091 encr_auth_algs MD5
1092 }
1093 Example 10 Verifying IPv6 Traffic is Authenticated with SHA1
1096 The following two entries require that all IPv6 traffic to and from the
1099 IPv6 site-local network fec0:abcd::0/32 be authenticated with SHA1.
1100 {raddr fec0:abcd::0/32} ipsec { auth_algs SHA1 }
1103 Example 11 Key Lengths
1106 # use aes at any key length
1108 {raddr spiderweb} ipsec {encr_algs aes}
1109 # use aes with a 192 bit key
1111 {raddr spiderweb} ipsec {encr_algs aes(192)}
1112 # use aes with any key length up to 192 bits
1114 # i.e. 192 bits or less
1115 {raddr spiderweb} ipsec {encr_algs aes(..192)}
1116 # use aes with any key length of 192 or more
1118 # i.e. 192 bits or more
1119 {raddr spiderweb} ipsec {encr_algs aes(192..)}
1120 #use aes with any key from 192 to 256 bits
1122 {raddr spiderweb} ipsec {encr_algs aes(192..256)}
1123 #use any algorithm with a key of 192 bits or longer
1125 {raddr spiderweb} ipsec {encr_algs any(192..)}
1126 Example 12 Correct and Incorrect Policy Entries
1129 The following are examples of correctly formed policy entries:
1132 { raddr that_system rport telnet } ipsec { encr_algs 3des encr_auth_algs
1135 sha1 sa shared}
1136 {
1138 raddr that_system
1139 rport telnet
1140 } ipsec {
1141 encr_algs 3des
1142 encr_auth_algs sha1
1143 sa shared
1144 }
1145 { raddr that_system rport telnet } ipsec
1147 { encr_algs 3des encr_auth_algs sha1 sa shared}
1148 { raddr that_system rport telnet } ipsec
1150 { encr_algs 3des encr_auth_algs sha1 sa shared} or ipsec
1151 { encr_algs aes encr_auth_algs sha1 sa shared}
1152 ...and the following is an incorrectly formed entry:
1157 { raddr that_system rport telnet } ipsec
1160 { encr_algs 3des encr_auth_algs sha1 sa shared}
1161 or ipsec { encr_algs aes encr_auth_algs sha1 sa shared}
1162 In the preceding, incorrect entry, note that the third line begins with
1167 "or ipsec". Such an entry causes ipsecconf to return an error.
1168 Example 13 Allowing Neighbor Discovery to Occur in the Clear
1171 The following two entries require that all IPv6 traffic to and from the
1174 IPv6 site-local network fec0:abcd::0/32 be authenticated with SHA1. The
1175 second entry allows neighbor discovery to operate correctly.
1176 {raddr fec0:abcd::0/32} ipsec { auth_algs SHA1 }
1179 {raddr fec0:abcd::0/32 ulp ipv6-icmp type 133-137 dir both }
1180 pass { }
1181 Example 14 Using "or"
1184 The following entry allows traffic using the AES or Blowfish algorithms
1187 from the remote machine spiderweb:
1188 {raddr spiderweb} ipsec {encr_algs aes} or ipsec {encr_algs blowfish}
1191 Example 15 Configuring a Tunnel to be Backward-Compatible with Solaris
1194 9
1195 The following example is equivalent to "encr_algs aes encr_auth_algs
1198 md5" in ifconfig(1M):
1199 {tunnel ip.tun0 negotiate transport} ipsec {encr_algs aes
1202 encr_auth_algs md5}
1203 Example 16 Configuring a Tunnel to a VPN client with an Assigned
1206 Address
1207 The following example assumes a distinct "inside" network with its own
1210 topology, such that a client's default route goes "inside".
1211 # Unlike route(1m), the default route has to be spelled-out.
1214 {tunnel ip.tun0 negotiate tunnel raddr client-inside/32
1215 laddr 0.0.0.0/0} ipsec {encr_algs aes encr_auth_algs sha1}
1216 Example 17 Transit VPN router between Two Tunnelled Subnets and a Third
1219 The following example specifies a configuration for a VPN router that
1222 routes between two tunnelled subnets and a third subnet that is on-
1223 link. Consider remote-site A, remote-site B, and local site C, each
1224 with a /24 address allocation.
1225 # ip.tun0 between me (C) and remote-site A.
1228 # Cover remote-site A to remote-side B.
1229 {tunnel ip.tun0 negotiate tunnel raddr A-prefix/24 laddr
1230 B-prefix/24} ipsec {encr_algs 3des encr_auth_algs md5}
1231 # Cover remote-site A traffic to my subnet.
1233 {tunnel ip.tun0 negotiate tunnel raddr A-prefix/24 laddr
1234 C-prefix/24} ipsec {encr_algs 3des encr_auth_algs md5}
1235 # ip.tun1 between me (C) and remote-site B.
1237 # Cover remote-site B to remote-site A.
1238 {tunnel ip.tun1 negotiate tunnel raddr B-prefix/24 laddr
1239 A-prefix/24} ipsec {encr_algs aes encr_auth_algs sha1}
1240 # Cover remote-site B traffic to my subnet.
1242 {tunnel ip.tun1 negotiate tunnel raddr B-prefix/24 laddr
1243 C-prefix/24} ipsec {encr_algs aes encr_auth_algs md5}
1244
1247 /var/run/ipsecpolicy.conf
1248 Cache of IPsec policies currently configured for the system, main‐
1250 tained by ipsecconf command. Do not edit this file.
1251 /etc/inet/ipsecinit.conf
1254 File containing IPsec policies to be installed at system restart by
1256 the policy smf(5) service. See NOTES for more information.
1257 /etc/inet/ipsecinit.sample
1260 Sample input file for ipseconf.
1262
1265 See attributes(5) for descriptions of the following attributes:
1266 ┌─────────────────────────────┬─────────────────────────────┐
1271 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
1272 ├─────────────────────────────┼─────────────────────────────┤
1273 │Availability │SUNWcsu │
1274 ├─────────────────────────────┼─────────────────────────────┤
1275 │Interface Stability │Committed │
1276 └─────────────────────────────┴─────────────────────────────┘
1277
1279 auths(1), profiles(1), svcprop(1), svcs(1), in.iked(1M), init(1M),
1280 ifconfig(1M), ipsecalgs(1M), ipseckey(1M), svcadm(1M), svccfg(1M),
1281 gethostbyname(3NSL), accept(3SOCKET), connect(3SOCKET), gethostby‐
1282 name(3XNET), getnetbyname(3XNET), getprotobyname(3XNET), getservby‐
1283 name(3XNET), getaddrinfo(3SOCKET), socket(3SOCKET), ike.config(4), nss‐
1284 witch.conf(4), prof_attr(4), user_attr(4), attributes(5), rbac(5),
1285 smf(5), ipsecah(7P), ipsecesp(7P), pf_key(7P)
1286 Glenn, R. and Kent, S. RFC 2410, The NULL Encryption Algorithm and Its
1289 Use With IPsec. The Internet Society. 1998.
1290 Kent, S. and Atkinson, R. RFC 2402, IP Authentication Header.The Inter‐
1293 net Society. 1998.
1294 Kent, S. and Atkinson, R. RFC 2406, IP Encapsulating Security Payload
1297 (ESP). The Internet Society. 1998.
1298 Madsen, C. and Glenn, R. RFC 2403, The Use of HMAC-MD5-96 within ESP
1301 and AH. The Internet Society. 1998.
1302 Madsen, C. and Glenn, R. RFC 2404, The Use of HMAC-SHA-1-96 within ESP
1305 and AH. The Internet Society. 1998.
1306 Madsen, C. and Doraswamy, N. RFC 2405, The ESP DES-CBC Cipher Algorithm
1309 With Explicit IV. The Internet Society. 1998.
1310 Pereira, R. and Adams, R. RFC 2451, The ESP CBC-Mode Cipher Algorithms.
1313 The Internet Society. 1998.
1314 Frankel, S. and Kelly, R. Glenn, The AES Cipher Algorithm and Its Use
1317 With IPsec. 2001.
1318
1320 Bad "string" on line N.
1321 Duplicate "string" on line N.
1322 string refers to one of the names in pattern or properties. A Bad
1324 string indicates that an argument is malformed; a Duplicate string
1325 indicates that there are multiple arguments of a similar type, for
1326 example, multiple Source Address arguments.
1327 Interface name already selected
1330 Dual use of -i name and name,index for an index.
1332 Error before or at line N.
1335 Indicates parsing error before or at line N.
1337 Non-existent index
1340 Reported when the index for delete is not a valid one.
1342 spd_msg return: File exists
1345 Reported when there is already a policy entry that matches the
1347 traffic of this new entry.
1348
1351 IPsec manual keys are managed by the service management facility,
1352 smf(5). The services listed below manage the components of IPsec. These
1353 services are delivered as follows:
1354 svc:/network/ipsec/policy:default (enabled)
1356 svc:/network/ipsec/ipsecalgs:default (enabled)
1357 svc:/network/ipsec/manual-key:default (disabled)
1358 svc:/network/ipsec/ike:default (disabled)
1359 The manual-key service is delivered disabled. The system administrator
1364 must create manual IPsec Security Associations (SAs), as described in
1365 ipseckey(1M), before enabling that service.
1366 The policy service is delivered enabled, but without a configuration
1369 file, so that, as a starting condition, packets are not protected by
1370 IPsec. After you create the configuration file
1371 /etc/inet/ipsecinit.conf, as described in this man page, and refresh
1372 the service (svcadm refresh, see below), the policy contained in the
1373 configuration file is applied. If there is an error in this file, the
1374 service enters maintenance mode.
1375 Services that are delivered disabled are delivered that way because the
1378 system administrator must create configuration files for those services
1379 before enabling them. See ike.config(4) for the ike service.
1380 See ipsecalgs(1M) for the ipsecalgs service.
1383 The correct administrative procedure is to create the configuration
1386 file for each service, then enable each service using svcadm(1M).
1387 If the configuration needs to be changed, edit the configuration file
1390 then refresh the service, as follows:
1391 example# svcadm refresh policy
1393 The smf(5) framework will record any errors in the service-specific log
1398 file. Use any of the following commands to examine the logfile prop‐
1399 erty:
1400 example# svcs -l policy
1402 example# svcprop policy
1403 example# svccfg -s policy listprop
1404 The following property is defined for the policy service:
1409 config/config_file
1411 This property can be modified using svccfg(1M) by users who have been
1416 assigned the following authorization:
1417 solaris.smf.value.ipsec
1419 See auths(1), user_attr(4), rbac(5).
1424 The service needs to be refreshed using svcadm(1M) before the new prop‐
1427 erty is effective. General non-modifiable properties can be viewed with
1428 the svcprop(1) command.
1429 # svccfg -s ipsec/policy setprop config/config_file = /new/config_file
1431 # svcadm refresh policy
1432 Administrative actions on this service, such as enabling, disabling,
1437 refreshing, and requesting restart can be performed using svcadm(1M). A
1438 user who has been assigned the authorization shown below can perform
1439 these actions:
1440 solaris.smf.manage.ipsec
1442 The service's status can be queried using the svcs(1) command.
1447 The ipsecconf command is designed to be managed by the policy smf(5)
1450 service. While the ipsecconf command can be run from the command line,
1451 this is discouraged. If the ipsecconf command is to be run from the
1452 command line, the policy smf(5) service should be disabled first. See
1453 svcadm(1M).
1454SunOS 5.11 28 Sep 2009 ipsecconf(1M)