1IKED.CONF(5) BSD File Formats Manual IKED.CONF(5)
2
4 iked.conf — IKEv2 configuration file
5
7 iked.conf is the configuration file for iked(8), the Internet Key Ex‐
8 change version 2 (IKEv2) daemon for IPsec. IPsec itself is a pair of
9 protocols: Encapsulating Security Payload (ESP), which provides integrity
10 and confidentiality; and Authentication Header (AH), which provides in‐
11 tegrity. The IPsec protocol itself is described in ipsec(4).
12 In its most basic form, a flow is established between hosts and/or net‐
14 works, and then Security Associations (SA) are established, which detail
15 how the desired protection will be achieved. IPsec uses flows to deter‐
16 mine whether to apply security services to an IP packet or not. iked(8)
17 is used to set up flows and establish SAs automatically, by specifying
18 ‘ikev2’ policies in iked.conf (see AUTOMATIC KEYING POLICIES, below).
19 Alternative methods of setting up flows and SAs are also possible using
21 manual keying or automatic keying using the older ISAKMP/Oakley a.k.a.
22 IKEv1 protocol. Manual keying is not recommended, but can be convenient
23 for quick setups and testing. See ipsec.conf(5) and isakmpd(8) for more
24 information about manual keying and ISAKMP support.
25
27 iked.conf is divided into three main sections:
28 Macros
30 User-defined macros may be defined and used later, simplifying the
31 configuration file.
32 Global Configuration
34 Global settings for iked(8).
35 Automatic Keying Policies
37 Policies to set up IPsec flows and SAs automatically.
38 Lines beginning with ‘#’ and empty lines are regarded as comments, and
40 ignored. Lines may be split using the ‘\’ character.
41 Argument names not beginning with a letter, digit, or underscore must be
43 quoted.
44 Addresses can be specified in CIDR notation (matching netblocks), as sym‐
46 bolic host names, interface names, or interface group names.
47 Additional configuration files can be included with the include keyword,
49 for example:
50 include "/etc/macros.conf"
52 Certain parameters can be expressed as lists, in which case iked(8) gen‐
54 erates all the necessary flow combinations. For example:
55 ikev2 esp proto { tcp, udp } \
57 from 192.168.1.1 to 10.0.0.18 \
58 peer 192.168.10.1
59
61 Macros can be defined that will later be expanded in context. Macro
62 names must start with a letter, digit, or underscore, and may contain any
63 of those characters. Macro names may not be reserved words (for example
64 flow, from, esp). Macros are not expanded inside quotes.
65 For example:
67 remote_gw = "192.168.3.12"
69 ikev2 esp from 192.168.7.0/24 to 192.168.8.0/24 peer $remote_gw
70
72 Here are the settings that can be set globally:
73 set active
75 Set iked(8) to global active mode. In active mode the per-policy
76 mode setting is respected. iked(8) will initiate policies set to
77 active and wait for incoming requests for policies set to passive.
78 This is the default.
79 set passive
81 Set iked(8) to global passive mode. In passive mode no packets are
82 sent to peers and no connections are initiated by iked(8), even for
83 active policies. This option is used for setups using sasyncd(8)
84 and carp(4) to provide redundancy. iked(8) will run in passive
85 mode until sasyncd has determined that the host is the master and
86 can switch to active mode.
87 set couple
89 Load the negotiated security associations (SAs) and flows into the
90 kernel. This is the default.
91 set decouple
93 Don't load the negotiated SAs and flows from the kernel. This mode
94 is only useful for testing and debugging.
95 set dpd_check_interval time
97 Specify the liveness check interval, in seconds. Setting time to 0
98 disables DPD. The default value is 60 seconds.
99 set enforcesingleikesa
101 Allow only a single active IKE SA for each dstid. When a new SA
102 with the same dstid is established, it replaces the old SA.
103 set noenforcesingleikesa
105 Don't limit the number of IKE SAs per dstid. This is the default.
106 set fragmentation
108 Enable IKEv2 Message Fragmentation (RFC 7383) support. This allows
109 IKEv2 to operate in environments that might block IP fragments.
110 set nofragmentation
112 Disables IKEv2 Message Fragmentation support. This is the default.
113 set mobike
115 Enable MOBIKE (RFC 4555) support. This is the default. MOBIKE al‐
116 lows the peer IP address to be changed for IKE and IPsec SAs. Cur‐
117 rently iked(8) only supports MOBIKE when acting as a responder.
118 set nomobike
120 Disables MOBIKE support.
121 set cert_partial_chain
123 Allow partial certificate chain if at least one certificate is a
124 trusted CA from /etc/iked/ca/.
125 set ocsp URL [tolerate time [maxage time]]
127 Enable OCSP and set the fallback URL of the OCSP responder. This
128 fallback will be used if the trusted CA from /etc/iked/ca/ does not
129 have an OCSP-URL extension. The matching responder certificates
130 have to be placed in /etc/iked/ocsp/responder.crt.
131 The optional tolerate parameter specifies how much the OCSP re‐
133 sponse attribute ‘thisUpdate’ may be in the future and how much
134 ‘nextUpdate’ may be in the past, with respect to the local time.
135 The optional maxage parameter specifies how much ‘thisUpdate’ may
136 be in the past. If tolerate is set to 0 then the times are not
137 verified at all. This is the default setting.
138 user name password
140 iked(8) supports user-based authentication by tunneling the Exten‐
141 sible Authentication Protocol (EAP) over IKEv2. In its most basic
142 form, the users will be authenticated against a local, integrated
143 password database that is configured with the user lines in
144 iked.conf and the name and password arguments. The password has to
145 be specified in plain text which is required to support different
146 challenge-based EAP methods like EAP-MD5 or EAP-MSCHAPv2.
147
149 This section is used to configure policies that will be used by iked(8)
150 to set up flows and SAs automatically. Some examples of setting up auto‐
151 matic keying:
152 # Set up a VPN:
154 # First between the gateway machines 192.168.3.1 and 192.168.3.2
155 # Second between the networks 10.1.1.0/24 and 10.1.2.0/24
156 ikev2 esp from 192.168.3.1 to 192.168.3.2
157 ikev2 esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2
158 For incoming connections from remote peers, the policies are evaluated in
160 sequential order, from first to last. The last matching policy decides
161 what action is taken; if no policy matches the connection, the default
162 action is to ignore the connection attempt or to use the default policy,
163 if set. See the EXAMPLES section for a detailed example of the policy
164 evaluation.
165 The first time an IKEv2 connection matches a policy, an IKE SA is cre‐
167 ated; for subsequent packets the connection is identified by the IKEv2
168 parameters that are stored in the SA without evaluating any policies.
169 After the connection is closed or times out, the IKE SA is automatically
170 removed.
171 The commands are as follows:
173 ikev2 [name]
174 The mandatory ikev2 keyword will identify an IKEv2 automatic keying
175 policy. name is an optional arbitrary string identifying the pol‐
176 icy. The name should only occur once in iked.conf or any included
177 files. If omitted, a name will be generated automatically for the
178 policy.
179 [eval]
181 The eval option modifies the policy evaluation for this policy. It
182 can be one of quick, skip or default. If a new incoming connection
183 matches a policy with the quick option set, that policy is consid‐
184 ered the last matching policy, and evaluation of subsequent poli‐
185 cies is skipped. The skip option will disable evaluation of this
186 policy for incoming connections. The default option sets the de‐
187 fault policy and should only be specified once.
188 [mode]
190 mode specifies the IKEv2 mode to use: one of passive or active.
191 When passive is specified, iked(8) will not immediately start nego‐
192 tiation of this tunnel, but wait for an incoming request from the
193 remote peer. When active is specified, negotiation will be started
194 at once. If omitted, passive mode will be used.
195 [ipcomp]
197 The keyword ipcomp specifies that ipcomp(4), the IP Payload Com‐
198 pression protocol, is negotiated in addition to encapsulation. The
199 optional compression is applied before packets are encapsulated.
200 IPcomp must be enabled in the kernel:
201 # sysctl net.inet.ipcomp.enable=1
203 [tmode]
205 tmode describes the encapsulation mode to be used. Possible modes
206 are tunnel and transport; the default is tunnel.
207 [encap]
209 encap specifies the encapsulation protocol to be used. Possible
210 protocols are esp and ah; the default is esp.
211 [af] This policy only applies to endpoints of the specified address fam‐
213 ily which can be either inet or inet6. This only matters for IKEv2
214 endpoints and does not restrict the traffic selectors to negotiate
215 flows with different address families, e.g. IPv6 flows negotiated
216 by IPv4 endpoints.
217 proto protocol
219 proto { protocol ... }
220 The optional proto parameter restricts the flow to a specific IP
221 protocol. Common protocols are icmp(4), tcp(4), and udp(4). For a
222 list of all the protocol name to number mappings used by iked(8),
223 see the file /etc/protocols.
224 Multiple protocol entries can be specified, separated by commas or
226 whitespace, if enclosed in curly brackets:
227 proto { tcp, udp }
229 rdomain number
231 Specify a different routing domain for unencrypted traffic. The
232 resulting IPsec SAs will match outgoing packets in the specified
233 rdomain number and move the encrypted packets to the rdomain the
234 iked(8) instance is running in. Vice versa, incoming ipsec(4)
235 traffic is moved to rdomain number after decryption.
236 from src [port sport] [(srcnat)] to dst [port dport]
238 Specify one or more traffic selectors for this policy which will be
239 used to negotiate the IPsec flows between the IKEv2 peers. During
240 the negotiation, the peers may decide to narrow a flow to a subset
241 of the configured traffic selector networks to match the policies
242 on each side.
243 Each traffic selector will apply for packets with source address
245 src and destination address dst. If the src argument specifies a
246 fictional source ID, the srcnat parameter can be used to specify
247 the actual source address. This can be used in outgoing NAT/BINAT
248 scenarios as described below. The keyword any will match any ad‐
249 dress (i.e. 0.0.0.0/0 and ::/0). If the config address option is
250 specified, the dynamic keyword can be used to create flows from or
251 to the dynamically assigned address.
252 The optional port modifiers restrict the traffic selectors to the
254 specified ports. They are only valid in conjunction with the
255 tcp(4) and udp(4) protocols. Ports can be specified by number or
256 by name. For a list of all port name to number mappings used by
257 ipsecctl(8), see the file /etc/services.
258 local localip peer remote
260 The local parameter specifies the address or FQDN of the local end‐
261 point. Unless the gateway is multi-homed or uses address aliases,
262 this option is generally not needed.
263 The peer parameter specifies the address or FQDN of the remote end‐
265 point. For host-to-host connections where dst is identical to
266 remote, this option is generally not needed as it will be set to
267 dst automatically. If it is not specified or if the keyword any is
268 given, the default peer is used.
269 ikesa auth algorithm enc algorithm prf algorithm group group
271 These parameters define the mode and cryptographic transforms to be
272 used for the IKE SA negotiation, also known as phase 1. The IKE SA
273 will be used to authenticate the machines and to set up an en‐
274 crypted channel for the IKEv2 protocol.
275 Possible values for auth, enc, prf, group, and the default propos‐
277 als are described below in CRYPTO TRANSFORMS. If omitted, iked(8)
278 will use the default proposals for the IKEv2 protocol.
279 The keyword ikesa can be used multiple times as a delimiter between
281 IKE SA proposals. The order of the proposals depend on the order
282 in the configuration. The keywords auth, enc, prf and group can be
283 used multiple times within a single proposal to configure multiple
284 crypto transforms.
285 childsa auth algorithm enc algorithm group group esn
287 These parameters define the cryptographic transforms to be used for
288 the Child SA negotiation, also known as phase 2. Each Child SA
289 will be used to negotiate the actual IPsec SAs. The initial Child
290 SA is always negotiated with the initial IKEv2 key exchange; addi‐
291 tional Child SAs may be negotiated with additional Child SA key ex‐
292 changes for an established IKE SA.
293 Possible values for auth, enc, group, esn, and the default propos‐
295 als are described below in CRYPTO TRANSFORMS. If omitted, iked(8)
296 will use the default proposals for the ESP or AH protocol.
297 The group option will only be used to enable Perfect Forward Se‐
299 crecy (PFS) for additional Child SAs exchanges that are not part of
300 the initial key exchange.
301 The keyword childsa can be used multiple times as a delimiter be‐
303 tween Child SA proposals. The order of the proposals depend on the
304 order in the configuration. The keywords auth, enc and group can
305 be used multiple times within a single proposal to configure multi‐
306 ple crypto transforms.
307 srcid string dstid string
309 srcid defines an ID of type “FQDN”, “ASN1_DN”, “IPV4”, “IPV6”, or
310 “UFQDN” that will be used by iked(8) as the identity of the local
311 peer. If the argument is an email address (reyk@example.com),
312 iked(8) will use UFQDN as the ID type. The ASN1_DN type will be
313 used if the string starts with a slash ‘/’
314 (/C=DE/../CN=10.0.0.1/emailAddress=reyk@example.com). If the argu‐
315 ment is an IPv4 address or a compressed IPv6 address, the ID types
316 IPV4 or IPV6 will be used. Anything else is considered to be an
317 FQDN.
318 If srcid is omitted, the default is to use the hostname of the lo‐
320 cal machine, see hostname(1) to set or print the hostname.
321 dstid is similar to srcid, but instead specifies the ID to be used
323 by the remote peer.
324 ikelifetime time
326 The optional ikelifetime parameter defines the IKE SA expiration
327 timeout by the time SA was created. A zero value disables active
328 IKE SA rekeying. This is the default.
329 The accepted format of the time specification is described below.
331 lifetime time [bytes bytes]
333 The optional lifetime parameter defines the Child SA expiration
334 timeout by the time SA was in use and by the number of bytes that
335 were processed using the SA. Default values are 3 hours and 4 gi‐
336 gabytes which means that SA will be rekeyed before reaching the
337 time limit or 4 gigabytes of data will pass through. Zero values
338 disable rekeying.
339 Several unit specifiers are recognized (ignoring case): ‘m’ and ‘h’
341 for minutes and hours, and ‘K’, ‘M’ and ‘G’ for kilo-, mega- and
342 gigabytes accordingly.
343 Rekeying must happen at least several times a day as IPsec security
345 heavily depends on frequent key renewals.
346 [ikeauth]
348 Specify a method to be used to authenticate the remote peer.
349 iked(8) will automatically determine a method based on public keys
350 or certificates configured for the peer. ikeauth can be used to
351 override this behaviour. Non-psk modes will require setting up
352 certificates and RSA or ECDSA public keys; see iked(8) for more in‐
353 formation.
354 eap type
356 Use EAP to authenticate the initiator. The only
357 supported EAP type is currently MSCHAP-V2. The re‐
358 sponder will use RSA public key authentication.
359 ecdsa256
360 Use ECDSA with a 256-bit elliptic curve key and
361 SHA2-256 for authentication.
362 ecdsa384
363 Use ECDSA with a 384-bit elliptic curve key and
364 SHA2-384 for authentication.
365 ecdsa521
366 Use ECDSA with a 521-bit elliptic curve key and
367 SHA2-512 for authentication.
368 psk string
369 Use a pre-shared key string or hex value (starting
370 with 0x) for authentication.
371 rfc7427 Only use RFC 7427 signatures for authentication.
372 RFC 7427 signatures currently only support SHA2-256
373 as the hash.
374 rsa Use RSA public key authentication with SHA1 as the
375 hash.
376 The default is to allow any signature authentication.
378 config option address
380 request option address
381 Request or serve one or more optional configuration payloads (CP).
382 The configuration option can be one of the following with the ex‐
383 pected address format:
384 address address
386 Assign a static address on the internal network.
387 address address/prefix
388 Assign a dynamic address on the internal network.
389 The address will be assigned from an address pool
390 with the size specified by prefix.
391 netmask netmask
392 The IPv4 netmask of the internal network.
393 name-server address
394 The DNS server address within the internal network.
395 netbios-server address
396 The NetBIOS name server (WINS) within the internal
397 network. This option is provided for compatibility
398 with legacy clients.
399 dhcp-server address
400 The address of an internal DHCP server for further
401 configuration.
402 protected-subnet address/prefix
403 The address of an additional IPv4 or IPv6 subnet
404 reachable over the gateway. This option is used to
405 notify the peer of a subnet behind the gateway (that
406 might require a second SA). Networks specified in
407 this SA's "from" or "to" options do not need to be
408 included.
409 access-server address
410 The address of an internal remote access server.
411 iface interface
413 Enable automatic network configuration as initiator. Received ad‐
414 dresses, routes and nameservers will be installed on the specified
415 interface.
416 tag string
418 Add a pf(4) tag to all packets of IPsec SAs created for this con‐
419 nection. This will allow matching packets for this connection by
420 defining rules in pf.conf(5) using the tagged keyword.
421 The following variables can be used in tags to include information
423 from the remote peer on runtime:
424 $id The dstid that was proposed by the remote peer to
426 identify itself. It will be expanded to id-value,
427 e.g. FQDN/foo.example.com. To limit the size of the
428 derived tag, iked(8) will extract the common name
429 ‘CN=’ from ASN1_DN IDs, for example
430 ASN1_ID//C=DE/../CN=10.1.1.1/.. will be expanded to
431 10.1.1.1.
432 $eapid For a connection using EAP, the identity (username)
433 used by the remote peer.
434 $domain Extract the domain from IDs of type FQDN, UFQDN or
435 ASN1_DN.
436 $name The name of the IKEv2 policy that was configured in
437 iked.conf or automatically generated by iked(8).
438 For example, if the ID is FQDN/foo.example.com or
440 UFQDN/user@example.com, “ipsec-$domain” expands to
441 “ipsec-example.com”. The variable expansion for the tag directive
442 occurs only at runtime (not when the file is parsed) and must be
443 quoted, or it will be interpreted as a macro.
444 tap interface
446 Send the decapsulated IPsec traffic to the specified enc(4)
447 interface instead of enc0 for filtering and monitoring. The traf‐
448 fic will be blocked if the specified interface does not exist.
449
451 IPsec traffic appears unencrypted on the enc(4) interface and can be fil‐
452 tered accordingly using the OpenBSD packet filter, pf(4). The grammar
453 for the packet filter is described in pf.conf(5).
454 The following components are relevant to filtering IPsec traffic:
456 external interface
458 Interface for IKE traffic and encapsulated IPsec traffic.
459 proto udp port 500
461 IKE traffic on the external interface.
462 proto udp port 4500
464 IKE NAT-Traversal traffic on the external interface.
465 proto ah | esp
467 Encapsulated IPsec traffic on the external interface.
468 enc0
470 Default interface for outgoing traffic before it's been encapsu‐
471 lated, and incoming traffic after it's been decapsulated. State on
472 this interface should be interface bound; see enc(4) for further
473 information.
474 proto ipencap
476 [tunnel mode only] IP-in-IP traffic flowing between gateways on the
477 enc0 interface.
478 tagged ipsec-example.org
480 Match traffic of IPsec SAs using the tag keyword.
481 If the filtering rules specify to block everything by default, the fol‐
483 lowing rule would ensure that IPsec traffic never hits the packet filter‐
484 ing engine, and is therefore passed:
485 set skip on enc0
487 In the following example, all traffic is blocked by default. IPsec-re‐
489 lated traffic from gateways {192.168.3.1, 192.168.3.2} and networks
490 {10.0.1.0/24, 10.0.2.0/24} is permitted.
491 block on ix0
493 block on enc0
494 pass in on ix0 proto udp from 192.168.3.2 to 192.168.3.1 \
496 port {500, 4500}
497 pass out on ix0 proto udp from 192.168.3.1 to 192.168.3.2 \
498 port {500, 4500}
499 pass in on ix0 proto esp from 192.168.3.2 to 192.168.3.1
501 pass out on ix0 proto esp from 192.168.3.1 to 192.168.3.2
502 pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \
504 keep state (if-bound)
505 pass out on enc0 proto ipencap from 192.168.3.1 to 192.168.3.2 \
506 keep state (if-bound)
507 pass in on enc0 from 10.0.2.0/24 to 10.0.1.0/24 \
508 keep state (if-bound)
509 pass out on enc0 from 10.0.1.0/24 to 10.0.2.0/24 \
510 keep state (if-bound)
511 pf(4) has the ability to filter IPsec-related packets based on an arbi‐
513 trary tag specified within a ruleset. The tag is used as an internal
514 marker which can be used to identify the packets later on. This could be
515 helpful, for example, in scenarios where users are connecting in from
516 differing IP addresses, or to support queue-based bandwidth control,
517 since the enc0 interface does not support it.
518 The following pf.conf(5) fragment uses queues for all IPsec traffic with
520 special handling for developers and employees:
521 queue std on ix0 bandwidth 100M
523 queue deflt parent std bandwidth 10M default
524 queue developers parent std bandwidth 75M
525 queue employees parent std bandwidth 5M
526 queue ipsec parent std bandwidth 10M
527 pass out on ix0 proto esp set queue ipsec
529 pass out on ix0 tagged ipsec-developers.example.com \
531 set queue developers
532 pass out on ix0 tagged ipsec-employees.example.com \
533 set queue employees
534 The following example assigns the tags in the iked.conf configuration and
536 also sets an alternative enc(4) device:
537 ikev2 esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2 \
539 tag "ipsec-$domain" tap "enc1"
540
542 In some network topologies it is desirable to perform NAT on traffic
543 leaving through the VPN tunnel. In order to achieve that, the src argu‐
544 ment is used to negotiate the desired network ID with the peer and the
545 srcnat parameter defines the true local subnet, so that a correct SA can
546 be installed on the local side.
547 For example, if the local subnet is 192.168.1.0/24 and all the traffic
549 for a specific VPN peer should appear as coming from 10.10.10.1, the fol‐
550 lowing configuration is used:
551 ikev2 esp from 10.10.10.1 (192.168.1.0/24) to 192.168.2.0/24 \
553 peer 10.10.20.1
554 Naturally, a relevant NAT rule is required in pf.conf(5). For the exam‐
556 ple above, this would be:
557 match out on enc0 from 192.168.1.0/24 to 192.168.2.0/24 \
559 nat-to 10.10.10.1
560 From the peer's point of view, the local end of the VPN tunnel is de‐
562 clared to be 10.10.10.1 and all the traffic arrives with that source ad‐
563 dress.
564
566 The following authentication types are permitted with the auth keyword:
567 Authentication Key Length Truncated Length Default
569 hmac-md5 128 bits 96 bits
570 hmac-sha1 160 bits 96 bits x
571 hmac-sha2-256 256 bits 128 bits x
572 hmac-sha2-384 384 bits 192 bits x
573 hmac-sha2-512 512 bits 256 bits x
574 The following pseudo-random function types are permitted with the prf
576 keyword:
577 PRF Key Length Default
579 hmac-md5 128 bits [IKE only]
580 hmac-sha1 160 bits x [IKE only]
581 hmac-sha2-256 256 bits x [IKE only]
582 hmac-sha2-384 384 bits x [IKE only]
583 hmac-sha2-512 512 bits x [IKE only]
584 The following cipher types are permitted with the enc keyword:
586 Cipher Key Length Default
588 3des 168 bits x
589 aes-128 128 bits x
590 aes-192 192 bits x
591 aes-256 256 bits x
592 aes-128-ctr 160 bits [ESP only]
593 aes-192-ctr 224 bits [ESP only]
594 aes-256-ctr 288 bits [ESP only]
595 aes-128-gcm 160 bits x
596 aes-192-gcm 224 bits [ESP only]
597 aes-256-gcm 288 bits x
598 aes-128-gcm-12 160 bits [IKE only]
599 aes-256-gcm-12 288 bits [IKE only]
600 blowfish 160 bits [ESP only]
601 cast 128 bits [ESP only]
602 chacha20-poly1305 288 bits [ESP only]
603 The following cipher types provide only authentication, not encryption:
605 aes-128-gmac 160 bits [ESP only]
607 aes-192-gmac 224 bits [ESP only]
608 aes-256-gmac 288 bits [ESP only]
609 null [ESP only]
610 The Extended Sequence Numbers option can be enabled or disabled with the
612 esn or noesn keywords:
613 ESN Default
615 esn x [ESP only]
616 noesn x [ESP only]
617 Transforms followed by [IKE only] can only be used with the ikesa key‐
619 word, transforms with [ESP only] can only be used with the childsa key‐
620 word.
621 Using AES-GMAC or NULL with ESP will only provide authentication. This
623 is useful in setups where AH cannot be used, e.g. when NAT is involved.
624 The following group types are permitted with the group keyword:
626 Name Group Size Type Default
628 modp768 grp1 768 MODP [insecure]
629 modp1024 grp2 1024 MODP x [weak]
630 modp1536 grp5 1536 MODP x [weak]
631 modp2048 grp14 2048 MODP x
632 modp3072 grp15 3072 MODP x
633 modp4096 grp16 4096 MODP x
634 modp6144 grp17 6144 MODP
635 modp8192 grp18 8192 MODP
636 ecp256 grp19 256 ECP x
637 ecp384 grp20 384 ECP x
638 ecp521 grp21 521 ECP x
639 ecp192 grp25 192 ECP
640 ecp224 grp26 224 ECP
641 brainpool224 grp27 224 ECP
642 brainpool256 grp28 256 ECP
643 brainpool384 grp29 384 ECP
644 brainpool512 grp30 512 ECP
645 curve25519 grp31 256 Curve25519 x
646 sntrup761x25519 1190 B Hybrid PQKE
647 The currently supported group types are either MODP (exponentiation
649 groups modulo a prime), ECP (elliptic curve groups modulo a prime), or
650 Curve25519. MODP groups of less than 2048 bits are considered as weak or
651 insecure (see RFC 8247 section 2.4) and only provided for backwards com‐
652 patibility.
653
655 /etc/iked.conf
656 /etc/examples/iked.conf
657
659 The first example is intended for a server with clients connecting to
660 iked(8) as an IPsec gateway, or IKEv2 responder, using mutual public key
661 authentication and additional challenge-based EAP-MSCHAPv2 password au‐
662 thentication:
663 user "test" "password123"
665 ikev2 "win7" esp \
667 from dynamic to 172.16.2.0/24 \
668 peer 10.0.0.0/8 local 192.168.56.0/24 \
669 eap "mschap-v2" \
670 config address 172.16.2.1 \
671 tag "$name-$id"
672 The next example allows peers to authenticate using a pre-shared key
674 ‘foobar’:
675 ikev2 "big test" \
677 esp proto tcp \
678 from 10.0.0.0/8 port 23 to 20.0.0.0/8 port 40 \
679 from 192.168.1.1 to 192.168.2.2 \
680 peer any local any \
681 ikesa \
682 enc aes-128-gcm \
683 group ecp256 group curve25519 \
684 ikesa \
685 enc aes-128 auth hmac-sha2-256 \
686 group ecp256 group curve25519 \
687 childsa enc aes-128-gcm \
688 childsa enc aes-128 auth hmac-sha2-256 \
689 srcid host.example.com \
690 dstid 192.168.0.254 \
691 psk "foobar"
692 The following example illustrates the last matching policy evaluation for
694 incoming connections on an IKEv2 gateway. The peer 192.168.1.34 will al‐
695 ways match the first policy because of the quick keyword; connections
696 from the peers 192.168.1.3 and 192.168.1.2 will be matched by one of the
697 last two policies; any other connections from 192.168.1.0/24 will be
698 matched by the ‘subnet’ policy; and any other connection will be matched
699 by the ‘catch all’ policy.
700 ikev2 quick esp from 10.10.10.0/24 to 10.20.20.0/24 \
702 peer 192.168.1.34
703 ikev2 "catch all" esp from 10.0.1.0/24 to 10.0.2.0/24 \
704 peer any
705 ikev2 "subnet" esp from 10.0.3.0/24 to 10.0.4.0/24 \
706 peer 192.168.1.0/24
707 ikev2 esp from 10.0.5.0/30 to 10.0.5.4/30 peer 192.168.1.2
708 ikev2 esp from 10.0.5.8/30 to 10.0.5.12/30 peer 192.168.1.3
709 This example encrypts a gre(4) tunnel from local machine A
711 (2001:db8::aa:1) to peer D (2001:db8::dd:4) based on FQDN-based public
712 key authentication; transport mode avoids double encapsulation:
713 ikev2 transport \
715 proto gre \
716 from 2001:db8::aa:1 to 2001:db8::dd:4 \
717 peer D.example.com
718
720 enc(4), ipsec(4), ipsec.conf(5), pf.conf(5), ikectl(8), iked(8)
721
723 The iked.conf file format first appeared in OpenBSD 4.8.
724
726 The iked(8) program was written by Reyk Floeter <reyk@openbsd.org>.
727BSD April 13, 2022 BSD