NAME¶ipsec.conf - IPsec configuration and connections
DESCRIPTION¶The ipsec.conf file specifies most configuration and control information for the Libreswan IPsec subsystem. (The major exception is secrets for authentication; see ipsec.secrets(5).) Its contents are not security-sensitive. Configurations can be added using this configuration file or by using ipsec whack directly. This means that technically, the ipsec.conf file is optional, but a few warnings might show up when this file is missing.
ipsec.conf is a text file, consisting of one or more sections. White space followed by # followed by anything to the end of the line is a comment and is ignored, as are empty lines that are not within a section.
A line that contains include and a file name, separated by white space, is replaced by the contents of that file, preceded and followed by empty lines. If the file name is not a full pathname, it is considered to be relative to the directory that contains the including file. Such inclusions can be nested. Only a single filename may be supplied, and it may not contain white space, but it may include shell wildcards (see sh(1)); for example:
The intention of the include facility is mostly to permit keeping information on connections, or sets of connections, separate from the main configuration file. This permits such connection descriptions to be changed, copied to the other security gateways involved, etc., without having to constantly extract them from the configuration file and then insert them back into it. Note also the also and alsoflip parameters (described below) which permit splitting a single logical section (e.g. a connection description) into several distinct sections.
The first significant line of the file may specify a version of this specification for backwards compatibility with freeswan and openswan. It is ignored and unused. For compatibility with openswan, specify:
A section begins with a line of the form:
where type indicates what type of section follows, and name is an arbitrary name that distinguishes the section from others of the same type. (Names must start with a letter and may contain only letters, digits, periods, underscores, and hyphens.) All subsequent non-empty lines that begin with white space are part of the section; comments within a section must begin with white space too. There may be only one section of a given type with a given name.
Lines within the section are generally of the form
(note the mandatory preceding white space). There can be white space on either side of the =. Parameter names follow the same syntax as section names, and are specific to a section type. Unless otherwise explicitly specified, no parameter name may appear more than once in a section.
An empty value stands for the system default value (if any) of the parameter, i.e. it is roughly equivalent to omitting the parameter line entirely. A value may contain white space only if the entire value is enclosed in double quotes ("); a value cannot itself contain a double quote, nor may it be continued across more than one line.
Numeric values are specified to be either an “integer” (a sequence of digits) or a “decimal number” (sequence of digits optionally followed by `.' and another sequence of digits).
There is currently one parameter that is available in any type of section:
Parameter names beginning with x- (or X-, or x_, or X_) are reserved for user extensions and will never be assigned meanings by IPsec. Parameters with such names must still observe the syntax rules (limits on characters used in the name; no white space in a non-quoted value; no newlines or double quotes within the value). All other as-yet-unused parameter names are reserved for future IPsec improvements.
A section with name %default specifies defaults for sections of the same type. For each parameter in it, any section of that type that does not have a parameter of the same name gets a copy of the one from the %default section. There may be multiple %default sections of a given type, but only one default may be supplied for any specific parameter name. %default sections may not contain also or alsoflip parameters.
Currently there are two types of section: a config section specifies general configuration information for IPsec, while a conn section specifies an IPsec connection.
CONN SECTIONS¶A conn section contains a connection specification, defining a network connection to be made using IPsec. The name given is arbitrary, and is used to identify the connection to ipsec_auto(8) Here's a simple example:
conn snt left=10.11.11.1 leftsubnet=10.0.1.0/24 leftnexthop=172.16.55.66 leftsourceip=10.0.1.1 right=192.168.22.1 rightsubnet=10.0.2.0/24 rightnexthop=172.16.88.99 rightsourceip=10.0.2.1 keyingtries=%forever
A note on terminology... In automatic keying, there are two kinds of communications going on: transmission of user IP packets, and gateway-to-gateway negotiations for keying, rekeying, and general control. The data path (a set of “IPsec SAs”) used for user packets is herein referred to as the “connection”; the path used for negotiations (built with “ISAKMP SAs”) is referred to as the “keying channel”.
To avoid trivial editing of the configuration file to suit it to each system involved in a connection, connection specifications are written in terms of left and right participants, rather than in terms of local and remote. Which participant is considered left or right is arbitrary; IPsec figures out which one it is being run on based on internal information. This permits using identical connection specifications on both ends. There are cases where there is no symmetry; a good convention is to use left for the local side and right for the remote side (the first letters are a good mnemonic).
Many of the parameters relate to one participant or the other; only the ones for left are listed here, but every parameter whose name begins with left has a right counterpart, whose description is the same but with left and right reversed.
Parameters are optional unless marked “(required)”
CONN PARAMETERS: GENERAL¶The following parameters are relevant to IKE automatic keying. Unless otherwise noted, for a connection to work, in general it is necessary for the two ends to agree exactly on the values of these parameters.
If using IP addresses in combination with NAT, always use the actual local machine's (NATed) IP address, and if the remote (eg right=) is NATed as well, the remote's public (not NATed) IP address. Note that this makes the configuration no longer symmetrical on both sides, so you cannot use an identical configuration file on both hosts.
It supports two magic shorthands vhost: and vnet:, which can list subnets in the same syntax as virtual-private. The value %priv expands to the networks specified in virtual-private. The value %no means no subnet. A common use for allowing roadwarriors to come in on public IPs or via accepted NATed networks from RFC1918 is to use leftsubnet=vhost:%no,%priv. The vnet: option can be used to allow RFC1918 subnets without hardcoding them. When using vnet the connection will instantiate, allowing for multiple tunnels with different subnets.
When leftaddresspool= is specified, the connection may not specify either leftsubnet= or leftsubnets=. Address pools are fully allocated when the connection is loaded, so the ranges should be sane. For example, specifying a range rightaddresspool=10.0.0.0-22.214.171.124 will lead to massive memory allocation. Address pools specifying the exact same range are shared between different connections. Different addresspools should not be defined to partially overlap.
To filter on specific icmp type and code, use the higher 8 bits for type and the lower 8 bits for port. For example, to allow icmp echo packets (type 8, code 0) the 'port' would be 0x0800, or 2048 in decimal, so you configure leftprotoport=icmp/2048. Similarly, to allow ipv6-icmp Neighbour Discovery which has type 136 (0x88) and code 0(0x00) this becomes 0x8800 or in decimal 34816 resulting in leftprotoport=ipv6-icmp/34816 .
Some clients, notably older Windows XP and some Mac OSX clients, use a random high port as source port. In those cases rightprotoport=17/%any can be used to allow all UDP traffic on the connection. Note that this option is part of the proposal, so it cannot be arbitrarily left out if one end does not care about the traffic selection over this connection - both peers have to agree. The Port Selectors show up in the output of ipsec eroute and ipsec auto --status eg:"l2tp": 126.96.36.199[@aivd.libreswan.org]:7/1701...%any:17/1701 This option only filters outbound traffic. Inbound traffic selection must still be based on firewall rules activated by an updown script. The variables $PLUTO_MY_PROTOCOL, $PLUTO_PEER_PROTOCOL, $PLUTO_MY_PORT, and $PLUTO_PEER_PORT are available for use in updown scripts. Older workarounds for bugs involved a setting of 17/0 to denote any single UDP port (not UDP port 0). Some clients, most notably OSX, uses a random high port, instead of port 1701 for L2TP.
leftupdown="ipsec _updown --route yes"
To disable calling an updown script, set it to the empty string, eg leftupdown="" or leftupdown="%disabled".
See ipsec_pluto(8) for details. Relevant only locally, other end need not agree on it.
If one or both security gateways are doing forwarding firewalling (possibly including masquerading), and this is specified using the firewall parameters, tunnels established with IPsec are exempted from it so that packets can flow unchanged through the tunnels. (This means that all subnets connected in this manner must have distinct, non-overlapping subnet address blocks.) This is done by the default updown script (see ipsec_pluto(8)).
The implementation of this makes certain assumptions about firewall setup, and the availability of the Linux Advanced Routing tools. In situations calling for more control, it may be preferable for the user to supply his own updown script, which makes the appropriate adjustments for his system.
CONN PARAMETERS: AUTOMATIC KEYING¶The following parameters are relevant to automatic keying via IKE. Unless otherwise noted, for a connection to work, in general it is necessary for the two ends to agree exactly on the values of these parameters.
The option ondemand used to be called route
If asymmetric authentication is requested, IKEv2 must be enabled, and the options leftauth= and rightauth= should be used instead of authby.
Digital signatures are superior in every way to shared secrets. Especially IKEv1 in Aggressive Mode is vulnerable to offline dictionary attacks and is performed routinely by at least the NSA on monitored internet traffic globally. The never option is only used for connections that do not actually start an IKE negotiation, such as type=passthrough connections. The auth method null is used for "anonymous opportunistic IPsec" and should not be used for regular pre-configured IPsec VPNs.
Note that AES-GCM is an AEAD algorithm, meaning that it performs encryption+authentication in one step. This means that AES-GCM must not specify an authentication algorithm. However, it does require a PRF function, so the second argument to an AEAD algorithm denotes the PRF. So ike=aes_gcm-sha2 means propose AES_GCM with no authentication and using SHA2 as the prf. Note that for phase2alg, there is no prf, so AES-GCM is specified for ESP as phase2alg=aes_gcm-null. The AES-GCM and AES-CCM algorithms support 8,12 and 16 byte ICV's. These can be specified using a postfix, for example aes_gcm_a (for 8), aes_gcm_b (for 12) and aes_gcm_c (for 16). The default (aes_gcm without postfix) refers to the 16 byte ICV version. It is strongly recommended to NOT use the 8 or 12 byte versions of GCM or CCM.
Weak algorithms are regularly removed from libreswan. Currently, 1DES and modp768 have been removed and modp1024 will be removed in the near future. Additionally, md5 and sha1 will be removed within the next few years. Null encryption is available, and should only be used for testing or benchmarking purposes. Please do not request for insecure algorithms to be re-added to libreswan.
Diffie-Hellman groups 19,20 and 21 from RFC- 5903 and 22, 23 and 24 from RFC-5114 are also supported. For all groups, the "dh" keyword can be used. For the MODP based groups, the modp= keyword can be used. for example ike=3des-sha1;dh19. The RFC-5114 DH groups are extremely controversial and MUST NOT be used unless forced (administratively) by the other party. Support for these groups will most likely be removed in 2017, as it cannot be proven these DH groups do not have a cryptographic trapdoor embedded in them (a backdoor by the USG who provided these primes without revealing the seeds and generation process used). Due the the weakness od DH22, support for this group is not compiled in by default and can be re-enabled using USE_DH22=true.
The modp syntax will be removed in favour of the dh syntax in the future
The very first IPsec designs called for use of AH plus ESP to offer authentication, integrity and confidentiality. That dual protocol use was a significant burden, so ESP was extended to offer all three services, and AH remained as an auth/integ. The old mode of ah+esp is no longer supported in compliance with RFC 8221 Section 4. Additionally, AH does not play well with NATs, so it is strongly recommended to use ESP with the null cipher if you require unencrypted authenticated transport.
The default values are the same as for ike= Note also that not all ciphers available to the kernel (eg through CryptoAPI) are necessarily supported here.
The format for ESP is ENC-AUTH followed by one optional PFSgroup. For instance, "3des-md5" or "aes256-sha1;modp2048" or "aes-sha1,aes-md5". When specifying multiple algorithms, specify the PFSgroup last, e.g. "3des-md5,aes256-sha1;modp2048".
For RFC-5114 DH groups, use the "dh" keyword, eg "aes256-sha1;dh23". These specific DH groups are extremely controversial and MUST NOT be used unless forced (administratively) by the other party. Support for these groups will most likely be removed in 2017, as it cannot be proven these DH groups do not have a cryptographic trapdoor embedded in them (a backdoor by the USG who gave us these primes without revealing the seeds and generation process)
The format for AH is AUTH followed by an optional PFSgroup. For instance, "md5" or "sha1;modp1536".
AEAD algorithms such as AES-GCM and AES-CCM require null for the authentication algorithm, for example phase2alg=aes_ccm-null or phase2alg=aes_gcm-null. Note that the ike= syntax for aes_gcm does not specify a null authentication but specifies the prf instead. The supported key sizes are 128, 192 and 256, which are specified similarly to plain aes, i.e. phase2alg=aes_gcm256. A subscript of _c, _b or _a can be used to refer to the different ICV variants where a means 8 bytes, b means 12 bytes and c means 16 bytes. The default when not using a subscript is the 16 byte ICV, the recommended value by RFC-4106. Therefor phase2alg=aes_gcm256-null is equivalent to phase2alg=aes_gcm_c256-null. It is recommended to migrate to the _c versions (without specifying _c), as support for smaller ICV's might be removed in the near future.
The supported algorithms depend on the libreswan version, OS and kernel stack used. Possible ciphers are aes, 3des, aes_ctr, aes_gcm, aes_ccm, camellia, serpent and twofish.
Note that openswan and versions of libreswan up to 3.6 require manually adding the salt size to the key size. Therefor, to configure an older version of openswan or libreswan, use: "phase2alg=aes_ccm_c-280-null" to interop with a new libreswan using "phase2alg=aes_ccm256". For CCM, the 'keysize' needs to be increased by 24, resulted in valid keysizes of 152, 215 and 280. For GCM the 'keysize' needs to be increased by 32, resulting valid 'keysizes' of 160, 224 and 288.
This option enables using the draft 96 bits version to interop with those implementations. Currently the accepted values are no, (the default) signifying default RFC truncation of 128 bits, or yes, signifying the draft 96 bits truncation.
Another workaround is to switch from sha2_256 to sha2_128 or sha2_512.
This option allows fine tuning which of the NAT-T payloads to consider for sending and processing. Currently the accepted values are drafts, rfc, both (the default) and none. To interoperate with known broken devices, use nat-ikev1-method=drafts. To prevent the other end from triggering IKEv1 NAT-T encapsulation, set this to none. This will omit the NAT-T payloads used to determine NAT, forcing the other end not to use encapsulation.
IKEv1 fragmentation capabilities are negotiated via a well-known private vendor id. IKEv2 fragmentation support is implemented using RFC 7383. If pluto does not receive the fragmentation payload, no IKE fragments will be sent, regardless of the fragmentation= setting. When set to yes, IKE fragmentation will be attempted on the first re-transmit of an IKE packet of a size larger then 576 bytes for IPv4 and 1280 bytes for IPv6. If fragmentation is set to force, IKE fragmentation is used on initial transmits of such sized packets as well. When we have received IKE fragments for a connection, pluto behaves as if in force mode.
IKE padding is allowed in IKEv1 but has been known to cause interoperability issues. The ikepad= option can be used to disable IKEv1 padding. This used to be required for some devices (such as Checkpoint in Aggressive Mode) that reject padded IKEv1 packets. A bug was fixed in libreswan 3.25 that applied wrong IKE padding in XAUTH, so it is suspected that Checkpoint padding issue bas been resolved. And this option should not be needed by anyone. In IKEv2, no padding is allowed, and this option has no effect. If you find a device that seems to require IKE padding, please contact the libreswan developers. This option should almost never be enabled and might be removed in a future version.
If the ikev2= setting is set to permit or propose, Libreswan will try and detect a "bid down" attack from IKEv2 to IKEv1. Since there is no standard for transmitting the IKEv2 capability with IKEv1, Libreswan uses a special Vendor ID "CAN-IKEv2". If a fall back from IKEv2 to IKEv1 was detected, and the IKEv1 negotiation contains Vendor ID "CAN-IKEv2", Libreswan will immediately attempt and IKEv2 rekey and refuse to use the IKEv1 connection. With an ikev2= setting of insist, no IKEv1 negotiation is allowed, and no bid down attack is possible.
VTI and MOBIKE might not work well when used together.
There are security implications in allowing narrowing down the proposal. For one, what should be done with packets that we hoped to tunnel, but cannot. Should these be dropped or send in the clear? Second, this could cause thousands of narrowed down Child SAs to be created if the conn has a broad policy (eg 0/0 to 0/0). One possible good use case scenario is that a remote end (that you fully trust) allows you to define a 0/0 to them, while adjusting what traffic you route via them, and what traffic remains outside the tunnel. However, it is always preferred to setup the exact tunnel policy you want, as this will be much clearer to the user.
When using certificate based ID's, one need to specify the full RDN, optionally using wildcard matching (eg CN='*'). If the RDN contains a comma, this can be masked using a comma (eg OU='Foo,, Bar and associates')
If asymmetric authentication is requested, IKEv1 must be disabled. If symmetric authentication is required, use authby= instead of leftauth/rightauth. If leftauth is set, rightauth must also be set and authby= must not be set. Asymmetric authentication cannot use secret (psk) on one side and null on the other side - use psk on both ends instead.
Be aware that the symmetric keyword is authby= but the asymmetric keyword is leftauth and rightauth (without the "by").
For supported password hashing methods, see crypt(3). If pluto is running in FIPS mode, some hash methods, such as MD5, might not be available. Threads are used to launch an xauth authentication helper for file as well as PAM methods.
The alwaysok should only be used if the XAUTH user authentication is not really used, but is required for interoperability, as it defeats the whole point of XAUTH which is to rely on a secret only known by a human. See also pam-authorize=yes
modecfgdns, modecfgdomains, modecfgbanner
The modecfgdns option takes a comma or space separated list of IP addresses that can be used for DNS resolution. The modecfgdomains option takes a comma or space separated list of internal domain names that are reachable via the supplied modecfgdns DNS servers.
The IKEv1 split tunnel directive will be sent automatically if the xauth server side has configured a network other than 0.0.0.0/0. For IKEv2, this is automated via narrowing.
Vendor ID's can be useful in tracking interoperability problems. However, specific vendor identification and software versions can be useful to an attacker when there are known vulnerabilities to a specific vendor/version.
The prefix OE stands for "Opportunistic Encryption". This prefix was historically used by The FreeS/WAN Project and The Openswan Project (openswan up to version 2.6.38) and in one Xeleranized openswan versions (2.6.39). Further Xeleranized openswan's use the prefix OSW.
Note that connection instances created by the Opportunistic Encryption or PKIX (x.509) instantiation system are distinct internally. They will inherit this policy bit.
The default is no.
This feature is only available with kernel drivers that support SAs to overlapping conns. At present only the (klips) mast protocol stack supports this feature.
Automatically generated reqids use a range of 0-3 (eg 16380-16383 for the first reqid). These are used depending on the exact policy (AH, AH+ESP, IPCOMP, etc).
WARNING: Manually assigned reqids are all identical. Instantiations of connections (those using %any wildcards) will all use the same reqid. If you use manual assigning you should make sure your connections only match single road warrior only or you break multiple road warriors behind same NAT router because this feature requires unique reqids to work.
For KLIPS, when using the MAST variant, a different mechanism called SAref is in use. See overlapip and sareftrack.
dpdaction=clear is really only useful on the server of a Road Warrior config.
The value restart_by_peer has been obsoleted and its functionality moved into the regular restart action.
Aggressive Mode is less secure, and more vulnerable to Denial Of Service attacks. It is also vulnerable to brute force attacks with software such as ikecrack. It should not be used, and it should especially not be used with XAUTH and group secrets (PSK). If the remote system administrator insists on staying irresponsible, enable this option.
Aggressive Mode is further limited to only proposals with one DH group as there is no room to negotiate the DH group. Therefor it is mandatory for Aggressive Mode connections that both ike= and phase2alg= options are specified with only one fully specified proposal using one DH group.
The KE payload is created in the first exchange packet when using aggressive mode. The KE payload depends on the DH group used. This is why there cannot be multiple DH groups in IKEv1 aggressive mode. In IKEv2, which uses a similar method to IKEv1 Aggressive Mode, there is an INVALID_KE response payload that can inform the initiator of the responder's desired DH group and so an IKEv2 connection can actually recover from picking the wrong DH group by restarting its negotiation.
The keywords "keylife" and "lifetime" are obsoleted aliases for "salifetime." Change your configs to use "salifetime" instead.
As of libreswan 3.1, both ends must agree. In previous versions of libreswan, openswan and freeswan, compression was always accepted even if not configured. In light of the BEAST attacks on TLS, using compression and encryptions has come under more scrutiny, and it was decided that it should be possible for the local policy of an endpoint to disallow compression. A value of yes causes pluto to propose compression and reject proposals without it. A value of no prevents pluto from proposing compression; a proposal to compress will be rejected.
VTI interfaces are currently only supported on Linux with XFRM/NETKEY. The _updown script handles certain Linux specific interfaces settings required for proper functioning (disable_policy, rp_filter, forwarding, etc). Interface names are limited to 16 characters and may not allow all characters to be used. If marking and vti-routing=yes is used, no manual iptables should be required. However, administrators can use the iptables mangle table to mark traffic manually if desired.
KLIPS and NETKEY use a priority system based on "most specific match first". It uses an internal algorithm to calculate these based on network prefix length, protocol and port selectors. A lower value means a higher priority.
Typical values are about the 2000 range. These can be seen on the NETKEY stack using ip xfrm policy when the connection is up. For "anonymous IPsec" or Opportunistic Encryption based connections, a much lower priority (65535) is used to ensure administrator configured IPsec always takes precedence over opportunistic IPsec.
CONFIG SECTIONS¶At present, the only config section known to the IPsec software is the one named setup, which contains information used when the software is being started (see ipsec_setup(8)). Here's an example:
config setup interfaces="ipsec0=eth1 ipsec1=ppp0" klipsdebug=none plutodebug=control protostack=auto
Parameters are optional unless marked “(required)”.
The currently-accepted parameter names in a config setup section are:
Note: It seems that T-Mobile in the US and Rogers/Fido in Canada have started using 188.8.131.52/8 as their pre-NAT range. This range technically belongs to the Defence Interoperable Network Services Authority (DINSA), an agency of the Ministry of Defence of the United Kingdom. The network range seems to not have been announced for decades, which is probably why these organisations "borrowed" this range. To support roadwarriors on these 3G networks, you might have to add it to the virtual-private= line.
The strict mode refers to the NSS ocspMode_FailureIsVerificationFailure mode, while non-strict mode refers to the NSS ocspMode_FailureIsNotAVerificationFailure mode.
A few special debugging options are not included with all and must be specifically added to be enabled. These special values currently are private (for sensitive key material), crypt (for all crypto related operations), whackwatch (to not release the whack when it normally would), and add-prefix (for special prefix pre-pending)
When the connection is defined to be a server (using xauthserver=) and the connection policy is authby=secret, this option is ignored (as of 3.20) and old connections will never be replaced. This situation is commonly known as clients using a "Group ID".
This option may disappear in the near future. People using identical X.509 certificates on multiple devices are urged to upgrade to use separate certificates per client and device.
When SELinux runs in enforced mode, changing this requires a similar change in the SELinux policy for the pluto daemon.
When SELinux runs in enforced mode, changing this requires a similar change in the SELinux policy for the pluto daemon.
The current default is disabled, but it is expected that in the future this feature will be enabled on all supported operating systems. Similarly, it is expected that further privilege separation will reduce the allowed syscalls - for example for the crypto helpers or DNS helpers.
Warning: The restrictions of pluto are inherited by the updown scripts, so these scripts are also not allowed to use syscalls that are forbidden for pluto.
This feature can be tested using ipsec whack --seccomp-crashtest. Warning: With seccomp=enabled, pluto will be terminated by the kernel. With seccomp=tolerant or seccomp=disabled, pluto will report the results of the seccomp test. SECCOMP will log the forbidden syscall numbers to the audit log, but only with seccomp=enabled. The tool scmp_sys_resolver from the libseccomp development package can be used to translate the syscall number into a name. See programs/pluto/pluto_seccomp.c for the list of allowed syscalls.
IMPLICIT CONNS¶The system automatically defines several conns to implement default policy groups. Each can be overridden by explicitly defining a new conn with the same name. If the new conn has auto=ignore, the definition is suppressed.
Here are the automatically supplied definitions.
conn clear type=passthrough authby=never left=%defaultroute right=%group auto=route conn clear-or-private type=passthrough left=%defaultroute leftid=%myid right=%opportunisticgroup failureshunt=passthrough keyingtries=3 ikelifetime=1h salifetime=1h rekey=no auto=route conn private-or-clear type=tunnel left=%defaultroute leftid=%myid right=%opportunisticgroup failureshunt=passthrough keyingtries=3 ikelifetime=1h salifetime=1h rekey=no auto=route conn private type=tunnel left=%defaultroute leftid=%myid right=%opportunisticgroup failureshunt=drop keyingtries=3 ikelifetime=1h salifetime=1h rekey=no auto=route conn block type=reject authby=never left=%defaultroute right=%group auto=route # default policy conn packetdefault type=tunnel left=%defaultroute leftid=%myid left=0.0.0.0/0 right=%opportunistic failureshunt=passthrough keyingtries=3 ikelifetime=1h salifetime=1h rekey=no auto=route
These conns are not affected by anything in conn %default. They will only work if %defaultroute works. The leftid will be the interfaces IP address; this requires that reverse DNS records be set up properly.
The implicit conns are defined after all others. It is appropriate and reasonable to use also=private-or-clear (for example) in any other opportunistic conn.
POLICY GROUP FILES¶The optional files under /etc/ipsec.d/policies, including
/etc/ipsec.d/policies/clear /etc/ipsec.d/policies/clear-or-private /etc/ipsec.d/policies/private-or-clear /etc/ipsec.d/policies/private /etc/ipsec.d/policies/block
may contain policy group configuration information to supplement ipsec.conf. Their contents are not security-sensitive.
These files are text files. Each consists of a list of CIDR blocks, one per line. White space followed by # followed by anything to the end of the line is a comment and is ignored, as are empty lines.
A connection in ipsec.conf that has right=%group or right=%opportunisticgroup is a policy group connection. When a policy group file of the same name is loaded, with
ipsec auto --rereadgroups
or at system start, the connection is instantiated such that each CIDR block serves as an instance's right value. The system treats the resulting instances as normal connections.
For example, given a suitable connection definition private, and the file /etc/ipsec.d/policies/private with an entry 192.0.2.3, the system creates a connection instance private#192.0.2.3. This connection inherits all details from private, except that its right client is 192.0.2.3.
DEFAULT POLICY GROUPS¶The standard Libreswan install includes several policy groups which provide a way of classifying possible peers into IPsec security classes: private (talk encrypted only), private-or-clear (prefer encryption), clear-or-private (respond to requests for encryption), clear and block. Implicit policy groups apply to the local host only, and are implemented by the IMPLICIT CONNECTIONS described above.
OBSOLETE¶Various options have recently been obsoleted and are ignored. The options prepluto= and plutopost= have been obsoleted because these were used by the (obsoleted) shell wrappers launching the pluto daemon. If this functionality is needed, look at your initsystem for support. For example, the systemd initsystem has the options ExecStartPre= and ExecStopPost= to accomplish the same. The option plutoopts= has also been obsoleted for this reason. A replacement can be found in the PLUTO_OPTS environment variable in the file /etc/sysconfig/pluto (Fedora/RHEL) or /etc/defaults/pluto (Debian/Ubuntu). The last two options obsoleted by the removal of the old shell scripts are pluto= and plutowait=.
The following ipsec commands have been obsoleted: ipsec _confread, ipsec _include, ipsec _plutoload, ipsec _realsetup, ipsec _startklips and ipsec _startnetkey due to the new parsing and startup methods and ipsec copyright, ipsec lwdnsq, ipsec mailkey, ipsec policy, ipsec showdefaults and ipsec showpolicy because they were no longer needed or current.
CHOOSING A CONNECTION [THIS SECTION IS EXTREMELY OUT OF DATE¶When choosing a connection to apply to an outbound packet caught with a %trap, the system prefers the one with the most specific eroute that includes the packet's source and destination IP addresses. Source subnets are examined before destination subnets. For initiating, only routed connections are considered. For responding, unrouted but added connections are considered.
When choosing a connection to use to respond to a negotiation that doesn't match an ordinary conn, an opportunistic connection may be instantiated. Eventually, its instance will be /32 -> /32, but for earlier stages of the negotiation, there will not be enough information about the client subnets to complete the instantiation.
/etc/ipsec.conf /etc/ipsec.d/policies/clear /etc/ipsec.d/policies/clear-or-private /etc/ipsec.d/policies/private-or-clear /etc/ipsec.d/policies/private /etc/ipsec.d/policies/block
SEE ALSO¶ipsec(8), ipsec_auto(8), ipsec_rsasigkey(8)
HISTORY¶Designed for the FreeS/WAN project <http://www.freeswan.org> by Henry Spencer.
BUGS¶Before reporting new bugs, please ensure you are using the latest version of Libreswan, and if not using KLIPS, please ensure you are using the latest kernel code for your IPsec stack.
When type or failureshunt is set to drop or reject, Libreswan blocks outbound packets using eroutes, but assumes inbound blocking is handled by the firewall. Libreswan offers firewall hooks via an “updown” script. However, the default ipsec _updown provides no help in controlling a modern firewall.
Including attributes of the keying channel (authentication methods, ikelifetime, etc.) as an attribute of a connection, rather than of a participant pair, is dubious and incurs limitations.
The use of %any with the protoport= option is ambiguous. Should the SA permits any port through or should the SA negotiate any single port through? The first is a basic conn with a wildcard. The second is a template. The second is the current behaviour, and it's wrong for quite a number of uses involving TCP. The keyword %one may be introduced in the future to separate these two cases.
It would be good to have a line-continuation syntax, especially for the very long lines involved in RSA signature keys.
First packet caching is only implemented for the KLIPS(NG) and MAST stacks. NETKEY returns POSIX-breaking responses, visible as connect: Resource temporarily unavailable errors. This affects Opportunistic Encryption and DPD. Functionality on the BSD and Windows stacks is unknown.
Some state information is only available when using KLIPS, and will return errors on other IPsec stacks. These include ipsec eroute, ipsec spi and ipsec look.
Multiple L2TP clients behind the same NAT router, and multiple L2TP clients behind different NAT routers using the same Virtual IP is currently only working for the KLIPSNG stack.
The ability to specify different identities, authby, and public keys for different automatic-keyed connections between the same participants is misleading; this doesn't work dependably because the identity of the participants is not known early enough. This is especially awkward for the “Road Warrior” case, where the remote IP address is specified as 0.0.0.0, and that is considered to be the “participant” for such connections.
In principle it might be necessary to control MTU on an interface-by-interface basis, rather than with the single global override that overridemtu provides. This feature is planned for a future release.
If conns are to be added before DNS is available, left=FQDN, leftnextop=FQDN, and leftrsasigkey=%dnsonload will fail. ipsec_pluto(8) does not actually use the public key for our side of a conn but it isn't generally known at a add-time which side is ours (Road Warrior and Opportunistic conns are currently exceptions).
The myid option does not affect explicit ipsec auto --add or ipsec auto --replace commands for implicit conns.