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 set vendorid
140 Send OpenIKED Vendor ID payload. This is the default.
141 set novendorid
143 Don't send a Vendor ID payload.
144 user name password
146 iked(8) supports user-based authentication by tunneling the Exten‐
147 sible Authentication Protocol (EAP) over IKEv2. In its most basic
148 form, the users will be authenticated against a local, integrated
149 password database that is configured with the user lines in
150 iked.conf and the name and password arguments. The password has to
151 be specified in plain text which is required to support different
152 challenge-based EAP methods like EAP-MD5 or EAP-MSCHAPv2.
153
155 This section is used to configure policies that will be used by iked(8)
156 to set up flows and SAs automatically. Some examples of setting up auto‐
157 matic keying:
158 # Set up a VPN:
160 # First between the gateway machines 192.168.3.1 and 192.168.3.2
161 # Second between the networks 10.1.1.0/24 and 10.1.2.0/24
162 ikev2 esp from 192.168.3.1 to 192.168.3.2
163 ikev2 esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2
164 For incoming connections from remote peers, the policies are evaluated in
166 sequential order, from first to last. The last matching policy decides
167 what action is taken; if no policy matches the connection, the default
168 action is to ignore the connection attempt or to use the default policy,
169 if set. See the EXAMPLES section for a detailed example of the policy
170 evaluation.
171 The first time an IKEv2 connection matches a policy, an IKE SA is cre‐
173 ated; for subsequent packets the connection is identified by the IKEv2
174 parameters that are stored in the SA without evaluating any policies.
175 After the connection is closed or times out, the IKE SA is automatically
176 removed.
177 The commands are as follows:
179 ikev2 [name]
180 The mandatory ikev2 keyword will identify an IKEv2 automatic keying
181 policy. name is an optional arbitrary string identifying the pol‐
182 icy. The name should only occur once in iked.conf or any included
183 files. If omitted, a name will be generated automatically for the
184 policy.
185 [eval]
187 The eval option modifies the policy evaluation for this policy. It
188 can be one of quick, skip or default. If a new incoming connection
189 matches a policy with the quick option set, that policy is consid‐
190 ered the last matching policy, and evaluation of subsequent poli‐
191 cies is skipped. The skip option will disable evaluation of this
192 policy for incoming connections. The default option sets the de‐
193 fault policy and should only be specified once.
194 [mode]
196 mode specifies the IKEv2 mode to use: one of passive or active.
197 When passive is specified, iked(8) will not immediately start nego‐
198 tiation of this tunnel, but wait for an incoming request from the
199 remote peer. When active is specified, negotiation will be started
200 at once. If omitted, passive mode will be used.
201 [ipcomp]
203 The keyword ipcomp specifies that ipcomp(4), the IP Payload Com‐
204 pression protocol, is negotiated in addition to encapsulation. The
205 optional compression is applied before packets are encapsulated.
206 IPcomp must be enabled in the kernel:
207 # sysctl net.inet.ipcomp.enable=1
209 [tmode]
211 tmode describes the encapsulation mode to be used. Possible modes
212 are tunnel and transport; the default is tunnel.
213 [encap]
215 encap specifies the encapsulation protocol to be used. Possible
216 protocols are esp and ah; the default is esp.
217 [af] This policy only applies to endpoints of the specified address fam‐
219 ily which can be either inet or inet6. This only matters for IKEv2
220 endpoints and does not restrict the traffic selectors to negotiate
221 flows with different address families, e.g. IPv6 flows negotiated
222 by IPv4 endpoints.
223 proto protocol
225 proto { protocol ... }
226 The optional proto parameter restricts the flow to a specific IP
227 protocol. Common protocols are icmp(4), tcp(4), and udp(4). For a
228 list of all the protocol name to number mappings used by iked(8),
229 see the file /etc/protocols.
230 Multiple protocol entries can be specified, separated by commas or
232 whitespace, if enclosed in curly brackets:
233 proto { tcp, udp }
235 rdomain number
237 Specify a different routing domain for unencrypted traffic. The
238 resulting IPsec SAs will match outgoing packets in the specified
239 rdomain number and move the encrypted packets to the rdomain the
240 iked(8) instance is running in. Vice versa, incoming ipsec(4)
241 traffic is moved to rdomain number after decryption.
242 from src [port sport] [(srcnat)] to dst [port dport]
244 Specify one or more traffic selectors for this policy which will be
245 used to negotiate the IPsec flows between the IKEv2 peers. During
246 the negotiation, the peers may decide to narrow a flow to a subset
247 of the configured traffic selector networks to match the policies
248 on each side.
249 Each traffic selector will apply for packets with source address
251 src and destination address dst. If the src argument specifies a
252 fictional source ID, the srcnat parameter can be used to specify
253 the actual source address. This can be used in outgoing NAT/BINAT
254 scenarios as described below. The keyword any will match any ad‐
255 dress (i.e. 0.0.0.0/0 and ::/0). If the config address option is
256 specified, the dynamic keyword can be used to create flows from or
257 to the dynamically assigned address.
258 The optional port modifiers restrict the traffic selectors to the
260 specified ports. They are only valid in conjunction with the
261 tcp(4) and udp(4) protocols. Ports can be specified by number or
262 by name. For a list of all port name to number mappings used by
263 ipsecctl(8), see the file /etc/services.
264 local localip peer remote
266 The local parameter specifies the address or FQDN of the local end‐
267 point. Unless the gateway is multi-homed or uses address aliases,
268 this option is generally not needed.
269 The peer parameter specifies the address or FQDN of the remote end‐
271 point. For host-to-host connections where dst is identical to
272 remote, this option is generally not needed as it will be set to
273 dst automatically. If it is not specified or if the keyword any is
274 given, the default peer is used.
275 ikesa auth algorithm enc algorithm prf algorithm group group
277 These parameters define the mode and cryptographic transforms to be
278 used for the IKE SA negotiation, also known as phase 1. The IKE SA
279 will be used to authenticate the machines and to set up an en‐
280 crypted channel for the IKEv2 protocol.
281 Possible values for auth, enc, prf, group, and the default propos‐
283 als are described below in CRYPTO TRANSFORMS. If omitted, iked(8)
284 will use the default proposals for the IKEv2 protocol.
285 The keyword ikesa can be used multiple times as a delimiter between
287 IKE SA proposals. The order of the proposals depend on the order
288 in the configuration. The keywords auth, enc, prf and group can be
289 used multiple times within a single proposal to configure multiple
290 crypto transforms.
291 childsa auth algorithm enc algorithm group group esn
293 These parameters define the cryptographic transforms to be used for
294 the Child SA negotiation, also known as phase 2. Each Child SA
295 will be used to negotiate the actual IPsec SAs. The initial Child
296 SA is always negotiated with the initial IKEv2 key exchange; addi‐
297 tional Child SAs may be negotiated with additional Child SA key ex‐
298 changes for an established IKE SA.
299 Possible values for auth, enc, group, esn, and the default propos‐
301 als are described below in CRYPTO TRANSFORMS. If omitted, iked(8)
302 will use the default proposals for the ESP or AH protocol.
303 The group option will only be used to enable Perfect Forward Se‐
305 crecy (PFS) for additional Child SAs exchanges that are not part of
306 the initial key exchange.
307 The keyword childsa can be used multiple times as a delimiter be‐
309 tween Child SA proposals. The order of the proposals depend on the
310 order in the configuration. The keywords auth, enc and group can
311 be used multiple times within a single proposal to configure multi‐
312 ple crypto transforms.
313 srcid string dstid string
315 srcid defines an ID of type “FQDN”, “ASN1_DN”, “IPV4”, “IPV6”, or
316 “UFQDN” that will be used by iked(8) as the identity of the local
317 peer. If the argument is an email address (reyk@example.com),
318 iked(8) will use UFQDN as the ID type. The ASN1_DN type will be
319 used if the string starts with a slash ‘/’
320 (/C=DE/../CN=10.0.0.1/emailAddress=reyk@example.com). If the argu‐
321 ment is an IPv4 address or a compressed IPv6 address, the ID types
322 IPV4 or IPV6 will be used. Anything else is considered to be an
323 FQDN.
324 If srcid is omitted, the default is to use the hostname of the lo‐
326 cal machine, see hostname(1) to set or print the hostname.
327 dstid is similar to srcid, but instead specifies the ID to be used
329 by the remote peer.
330 ikelifetime time
332 The optional ikelifetime parameter defines the IKE SA expiration
333 timeout by the time SA was created. A zero value disables active
334 IKE SA rekeying. This is the default.
335 The accepted format of the time specification is described below.
337 lifetime time [bytes bytes]
339 The optional lifetime parameter defines the Child SA expiration
340 timeout by the time SA was in use and by the number of bytes that
341 were processed using the SA. Default values are 3 hours and 4 gi‐
342 gabytes which means that SA will be rekeyed before reaching the
343 time limit or 4 gigabytes of data will pass through. Zero values
344 disable rekeying.
345 Several unit specifiers are recognized (ignoring case): ‘m’ and ‘h’
347 for minutes and hours, and ‘K’, ‘M’ and ‘G’ for kilo-, mega- and
348 gigabytes accordingly.
349 Rekeying must happen at least several times a day as IPsec security
351 heavily depends on frequent key renewals.
352 [ikeauth]
354 Specify a method to be used to authenticate the remote peer.
355 iked(8) will automatically determine a method based on public keys
356 or certificates configured for the peer. ikeauth can be used to
357 override this behaviour. Non-psk modes will require setting up
358 certificates and RSA or ECDSA public keys; see iked(8) for more in‐
359 formation.
360 eap type
362 Use EAP to authenticate the initiator. The only
363 supported EAP type is currently MSCHAP-V2. The re‐
364 sponder will use RSA public key authentication.
365 ecdsa256
366 Use ECDSA with a 256-bit elliptic curve key and
367 SHA2-256 for authentication.
368 ecdsa384
369 Use ECDSA with a 384-bit elliptic curve key and
370 SHA2-384 for authentication.
371 ecdsa521
372 Use ECDSA with a 521-bit elliptic curve key and
373 SHA2-512 for authentication.
374 psk string
375 Use a pre-shared key string or hex value (starting
376 with 0x) for authentication.
377 rfc7427 Only use RFC 7427 signatures for authentication.
378 RFC 7427 signatures currently only support SHA2-256
379 as the hash.
380 rsa Use RSA public key authentication with SHA1 as the
381 hash.
382 The default is to allow any signature authentication.
384 config option address
386 request option address
387 Request or serve one or more optional configuration payloads (CP).
388 The configuration option can be one of the following with the ex‐
389 pected address format:
390 address address
392 Assign a static address on the internal network.
393 address address/prefix
394 Assign a dynamic address on the internal network.
395 The address will be assigned from an address pool
396 with the size specified by prefix.
397 netmask netmask
398 The IPv4 netmask of the internal network.
399 name-server address
400 The DNS server address within the internal network.
401 netbios-server address
402 The NetBIOS name server (WINS) within the internal
403 network. This option is provided for compatibility
404 with legacy clients.
405 dhcp-server address
406 The address of an internal DHCP server for further
407 configuration.
408 protected-subnet address/prefix
409 The address of an additional IPv4 or IPv6 subnet
410 reachable over the gateway. This option is used to
411 notify the peer of a subnet behind the gateway (that
412 might require a second SA). Networks specified in
413 this SA's "from" or "to" options do not need to be
414 included.
415 access-server address
416 The address of an internal remote access server.
417 iface interface
419 Enable automatic network configuration as initiator. Received ad‐
420 dresses, routes and nameservers will be installed on the specified
421 interface.
422 tag string
424 Add a pf(4) tag to all packets of IPsec SAs created for this con‐
425 nection. This will allow matching packets for this connection by
426 defining rules in pf.conf(5) using the tagged keyword.
427 The following variables can be used in tags to include information
429 from the remote peer on runtime:
430 $id The dstid that was proposed by the remote peer to
432 identify itself. It will be expanded to id-value,
433 e.g. FQDN/foo.example.com. To limit the size of the
434 derived tag, iked(8) will extract the common name
435 ‘CN=’ from ASN1_DN IDs, for example
436 ASN1_ID//C=DE/../CN=10.1.1.1/.. will be expanded to
437 10.1.1.1.
438 $eapid For a connection using EAP, the identity (username)
439 used by the remote peer.
440 $domain Extract the domain from IDs of type FQDN, UFQDN or
441 ASN1_DN.
442 $name The name of the IKEv2 policy that was configured in
443 iked.conf or automatically generated by iked(8).
444 For example, if the ID is FQDN/foo.example.com or
446 UFQDN/user@example.com, “ipsec-$domain” expands to
447 “ipsec-example.com”. The variable expansion for the tag directive
448 occurs only at runtime (not when the file is parsed) and must be
449 quoted, or it will be interpreted as a macro.
450 tap interface
452 Send the decapsulated IPsec traffic to the specified enc(4)
453 interface instead of enc0 for filtering and monitoring. The traf‐
454 fic will be blocked if the specified interface does not exist.
455
457 IPsec traffic appears unencrypted on the enc(4) interface and can be fil‐
458 tered accordingly using the OpenBSD packet filter, pf(4). The grammar
459 for the packet filter is described in pf.conf(5).
460 The following components are relevant to filtering IPsec traffic:
462 external interface
464 Interface for IKE traffic and encapsulated IPsec traffic.
465 proto udp port 500
467 IKE traffic on the external interface.
468 proto udp port 4500
470 IKE NAT-Traversal traffic on the external interface.
471 proto ah | esp
473 Encapsulated IPsec traffic on the external interface.
474 enc0
476 Default interface for outgoing traffic before it's been encapsu‐
477 lated, and incoming traffic after it's been decapsulated. State on
478 this interface should be interface bound; see enc(4) for further
479 information.
480 proto ipencap
482 [tunnel mode only] IP-in-IP traffic flowing between gateways on the
483 enc0 interface.
484 tagged ipsec-example.org
486 Match traffic of IPsec SAs using the tag keyword.
487 If the filtering rules specify to block everything by default, the fol‐
489 lowing rule would ensure that IPsec traffic never hits the packet filter‐
490 ing engine, and is therefore passed:
491 set skip on enc0
493 In the following example, all traffic is blocked by default. IPsec-re‐
495 lated traffic from gateways {192.168.3.1, 192.168.3.2} and networks
496 {10.0.1.0/24, 10.0.2.0/24} is permitted.
497 block on ix0
499 block on enc0
500 pass in on ix0 proto udp from 192.168.3.2 to 192.168.3.1 \
502 port {500, 4500}
503 pass out on ix0 proto udp from 192.168.3.1 to 192.168.3.2 \
504 port {500, 4500}
505 pass in on ix0 proto esp from 192.168.3.2 to 192.168.3.1
507 pass out on ix0 proto esp from 192.168.3.1 to 192.168.3.2
508 pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \
510 keep state (if-bound)
511 pass out on enc0 proto ipencap from 192.168.3.1 to 192.168.3.2 \
512 keep state (if-bound)
513 pass in on enc0 from 10.0.2.0/24 to 10.0.1.0/24 \
514 keep state (if-bound)
515 pass out on enc0 from 10.0.1.0/24 to 10.0.2.0/24 \
516 keep state (if-bound)
517 pf(4) has the ability to filter IPsec-related packets based on an arbi‐
519 trary tag specified within a ruleset. The tag is used as an internal
520 marker which can be used to identify the packets later on. This could be
521 helpful, for example, in scenarios where users are connecting in from
522 differing IP addresses, or to support queue-based bandwidth control,
523 since the enc0 interface does not support it.
524 The following pf.conf(5) fragment uses queues for all IPsec traffic with
526 special handling for developers and employees:
527 queue std on ix0 bandwidth 100M
529 queue deflt parent std bandwidth 10M default
530 queue developers parent std bandwidth 75M
531 queue employees parent std bandwidth 5M
532 queue ipsec parent std bandwidth 10M
533 pass out on ix0 proto esp set queue ipsec
535 pass out on ix0 tagged ipsec-developers.example.com \
537 set queue developers
538 pass out on ix0 tagged ipsec-employees.example.com \
539 set queue employees
540 The following example assigns the tags in the iked.conf configuration and
542 also sets an alternative enc(4) device:
543 ikev2 esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2 \
545 tag "ipsec-$domain" tap "enc1"
546
548 In some network topologies it is desirable to perform NAT on traffic
549 leaving through the VPN tunnel. In order to achieve that, the src argu‐
550 ment is used to negotiate the desired network ID with the peer and the
551 srcnat parameter defines the true local subnet, so that a correct SA can
552 be installed on the local side.
553 For example, if the local subnet is 192.168.1.0/24 and all the traffic
555 for a specific VPN peer should appear as coming from 10.10.10.1, the fol‐
556 lowing configuration is used:
557 ikev2 esp from 10.10.10.1 (192.168.1.0/24) to 192.168.2.0/24 \
559 peer 10.10.20.1
560 Naturally, a relevant NAT rule is required in pf.conf(5). For the exam‐
562 ple above, this would be:
563 match out on enc0 from 192.168.1.0/24 to 192.168.2.0/24 \
565 nat-to 10.10.10.1
566 From the peer's point of view, the local end of the VPN tunnel is de‐
568 clared to be 10.10.10.1 and all the traffic arrives with that source ad‐
569 dress.
570
572 The following authentication types are permitted with the auth keyword:
573 Authentication Key Length Truncated Length Default
575 hmac-md5 128 bits 96 bits
576 hmac-sha1 160 bits 96 bits x
577 hmac-sha2-256 256 bits 128 bits x
578 hmac-sha2-384 384 bits 192 bits x
579 hmac-sha2-512 512 bits 256 bits x
580 The following pseudo-random function types are permitted with the prf
582 keyword:
583 PRF Key Length Default
585 hmac-md5 128 bits [IKE only]
586 hmac-sha1 160 bits x [IKE only]
587 hmac-sha2-256 256 bits x [IKE only]
588 hmac-sha2-384 384 bits x [IKE only]
589 hmac-sha2-512 512 bits x [IKE only]
590 The following cipher types are permitted with the enc keyword:
592 Cipher Key Length Default
594 3des 168 bits x
595 aes-128 128 bits x
596 aes-192 192 bits x
597 aes-256 256 bits x
598 aes-128-ctr 160 bits [ESP only]
599 aes-192-ctr 224 bits [ESP only]
600 aes-256-ctr 288 bits [ESP only]
601 aes-128-gcm 160 bits x
602 aes-192-gcm 224 bits [ESP only]
603 aes-256-gcm 288 bits x
604 aes-128-gcm-12 160 bits [IKE only]
605 aes-256-gcm-12 288 bits [IKE only]
606 blowfish 160 bits [ESP only]
607 cast 128 bits [ESP only]
608 chacha20-poly1305 288 bits [ESP only]
609 The following cipher types provide only authentication, not encryption:
611 aes-128-gmac 160 bits [ESP only]
613 aes-192-gmac 224 bits [ESP only]
614 aes-256-gmac 288 bits [ESP only]
615 null [ESP only]
616 The Extended Sequence Numbers option can be enabled or disabled with the
618 esn or noesn keywords:
619 ESN Default
621 esn x [ESP only]
622 noesn x [ESP only]
623 Transforms followed by [IKE only] can only be used with the ikesa key‐
625 word, transforms with [ESP only] can only be used with the childsa key‐
626 word.
627 Using AES-GMAC or NULL with ESP will only provide authentication. This
629 is useful in setups where AH cannot be used, e.g. when NAT is involved.
630 The following group types are permitted with the group keyword:
632 Name Group Size Type Default
634 modp768 grp1 768 MODP [insecure]
635 modp1024 grp2 1024 MODP x [weak]
636 modp1536 grp5 1536 MODP x [weak]
637 modp2048 grp14 2048 MODP x
638 modp3072 grp15 3072 MODP x
639 modp4096 grp16 4096 MODP x
640 modp6144 grp17 6144 MODP
641 modp8192 grp18 8192 MODP
642 ecp256 grp19 256 ECP x
643 ecp384 grp20 384 ECP x
644 ecp521 grp21 521 ECP x
645 ecp192 grp25 192 ECP
646 ecp224 grp26 224 ECP
647 brainpool224 grp27 224 ECP
648 brainpool256 grp28 256 ECP
649 brainpool384 grp29 384 ECP
650 brainpool512 grp30 512 ECP
651 curve25519 grp31 256 Curve25519 x
652 sntrup761x25519 1190 B Hybrid PQKE
653 The currently supported group types are either MODP (exponentiation
655 groups modulo a prime), ECP (elliptic curve groups modulo a prime), or
656 Curve25519. MODP groups of less than 2048 bits are considered as weak or
657 insecure (see RFC 8247 section 2.4) and only provided for backwards com‐
658 patibility.
659
661 /etc/iked.conf
662 /etc/examples/iked.conf
663
665 The first example is intended for a server with clients connecting to
666 iked(8) as an IPsec gateway, or IKEv2 responder, using mutual public key
667 authentication and additional challenge-based EAP-MSCHAPv2 password au‐
668 thentication:
669 user "test" "password123"
671 ikev2 "win7" esp \
673 from dynamic to 172.16.2.0/24 \
674 peer 10.0.0.0/8 local 192.168.56.0/24 \
675 eap "mschap-v2" \
676 config address 172.16.2.1 \
677 tag "$name-$id"
678 The next example allows peers to authenticate using a pre-shared key
680 ‘foobar’:
681 ikev2 "big test" \
683 esp proto tcp \
684 from 10.0.0.0/8 port 23 to 20.0.0.0/8 port 40 \
685 from 192.168.1.1 to 192.168.2.2 \
686 peer any local any \
687 ikesa \
688 enc aes-128-gcm \
689 group ecp256 group curve25519 \
690 ikesa \
691 enc aes-128 auth hmac-sha2-256 \
692 group ecp256 group curve25519 \
693 childsa enc aes-128-gcm \
694 childsa enc aes-128 auth hmac-sha2-256 \
695 srcid host.example.com \
696 dstid 192.168.0.254 \
697 psk "foobar"
698 The following example illustrates the last matching policy evaluation for
700 incoming connections on an IKEv2 gateway. The peer 192.168.1.34 will al‐
701 ways match the first policy because of the quick keyword; connections
702 from the peers 192.168.1.3 and 192.168.1.2 will be matched by one of the
703 last two policies; any other connections from 192.168.1.0/24 will be
704 matched by the ‘subnet’ policy; and any other connection will be matched
705 by the ‘catch all’ policy.
706 ikev2 quick esp from 10.10.10.0/24 to 10.20.20.0/24 \
708 peer 192.168.1.34
709 ikev2 "catch all" esp from 10.0.1.0/24 to 10.0.2.0/24 \
710 peer any
711 ikev2 "subnet" esp from 10.0.3.0/24 to 10.0.4.0/24 \
712 peer 192.168.1.0/24
713 ikev2 esp from 10.0.5.0/30 to 10.0.5.4/30 peer 192.168.1.2
714 ikev2 esp from 10.0.5.8/30 to 10.0.5.12/30 peer 192.168.1.3
715 This example encrypts a gre(4) tunnel from local machine A
717 (2001:db8::aa:1) to peer D (2001:db8::dd:4) based on FQDN-based public
718 key authentication; transport mode avoids double encapsulation:
719 ikev2 transport \
721 proto gre \
722 from 2001:db8::aa:1 to 2001:db8::dd:4 \
723 peer D.example.com
724
726 enc(4), ipsec(4), ipsec.conf(5), pf.conf(5), ikectl(8), iked(8)
727
729 The iked.conf file format first appeared in OpenBSD 4.8.
730
732 The iked(8) program was written by Reyk Floeter <reyk@openbsd.org>.
733BSD July 22, 2022 BSD