IPSEC.CONF(5)IPSEC.CONF(5)NAME
ipsec.conf - IPsec configuration and connections
DESCRIPTION
The optional ipsec.conf file specifies most configuration and control
information for the strongSwan IPsec subsystem. (The major exception
is secrets for authentication; see ipsec.secrets(5).) Its contents are
not security-sensitive.
The file 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 which are not within a sec‐
tion.
A line which 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 consid‐
ered to be relative to the directory containing 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:
include ipsec.*.conf
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., with‐
out having to constantly extract them from the configuration file and
then insert them back into it. Note also the also parameter (described
below) which permits splitting a single logical section (e.g. a connec‐
tion description) into several actual sections.
A section begins with a line of the form:
type name
where type indicates what type of section follows, and name is an arbi‐
trary name which 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 which 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
parameter=value
(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 which is available in any type of sec‐
tion:
also the value is a section name; the parameters of that section are
appended to this section, as if they had been written as part of
it. The specified section must exist, must follow the current
one, and must have the same section type. (Nesting is permit‐
ted, and there may be more than one also in a single section,
although it is forbidden to append the same section more than
once.)
A section with name %default specifies defaults for sections of the
same type. For each parameter in it, any section of that type which
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, and all %default sections of a given type must precede
all non-%default sections of that type. %default sections may not con‐
tain the also parameter.
Currently there are three types of sections: a config section specifies
general configuration information for IPsec, a conn section specifies
an IPsec connection, while a ca section specifies special properties of
a certification authority.
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. Here's a simple example:
conn snt
left=192.168.0.1
leftsubnet=10.1.0.0/16
right=192.168.0.2
rightsubnet=10.1.0.0/16
keyingtries=%forever
auto=add
A note on terminology: 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 path to control the
connection is called 'ISAKMP SA' in IKEv1 and level data path, is
called 'IPsec SA'. strongSwan currently uses two separate keying dae‐
mons. Pluto handles all IKEv1 connections, Charon is the new daemon
supporting the IKEv2 protocol. Charon does not support all keywords
yet.
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 arbi‐
trary; 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 conven‐
tion 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
Unless otherwise noted, for a connection to work, in general it is nec‐
essary for the two ends to agree exactly on the values of these parame‐
ters.
ah AH authentication algorithm to be used for the connec‐
tion, e.g. hmac-md5.
auth whether authentication should be done as part of ESP
encryption, or separately using the AH protocol; accept‐
able values are esp (the default) and ah. The IKEv2 dae‐
mon currently supports only ESP.
authby how the two security gateways should authenticate each
other; acceptable values are secret or psk for pre-shared
secrets, pubkey (the default) for public key signatures
as well as the synonyms rsasig for RSA digital signatures
and ecdsasig for Elliptic Curve DSA signatures. never
can be used if negotiation is never to be attempted or
accepted (useful for shunt-only conns). Digital signa‐
tures are superior in every way to shared secrets. IKEv1
additionally supports the values xauthpsk and xauthrsasig
that will enable eXtended AUTHentication (XAUTH) in addi‐
tion to IKEv1 main mode based on shared secrets or digi‐
tal RSA signatures, respectively. This parameter is dep‐
recated for IKEv2 connections, as two peers do not need
to agree on an authentication method. Use the leftauth
parameter instead to define authentication methods in
IKEv2.
auto what operation, if any, should be done automatically at
IPsec startup; currently-accepted values are add , route
, start and ignore. add loads a connection without
starting it. route loads a connection and installs ker‐
nel traps. If traffic is detected between leftsubnet and
rightsubnet , a connection is established. start loads a
connection and brings it up immediatly. ignore ignores
the connection. This is equal to delete a connection from
the config file. Relevant only locally, other end need
not agree on it (but in general, for an intended-to-be-
permanent connection, both ends should use auto=start to
ensure that any reboot causes immediate renegotiation).
compress whether IPComp compression of content is proposed on the
connection (link-level compression does not work on
encrypted data, so to be effective, compression must be
done before encryption); acceptable values are yes and no
(the default). A value of yes causes IPsec to propose
both compressed and uncompressed, and prefer compressed.
A value of no prevents IPsec from proposing compression;
a proposal to compress will still be accepted. IKEv2
does not support IP compression yet.
dpdaction controls the use of the Dead Peer Detection protocol
(DPD, RFC 3706) where R_U_THERE notification messages
(IKEv1) or empty INFORMATIONAL messages (IKEv2) are peri‐
odically sent in order to check the liveliness of the
IPsec peer. The values clear, hold, and restart all acti‐
vate DPD. If no activity is detected, all connections
with a dead peer are stopped and unrouted ( clear ), put
in the hold state ( hold ) or restarted ( restart ). For
IKEv1, the default is none which disables the active
sending of R_U_THERE notifications. Nevertheless pluto
will always send the DPD Vendor ID during connection set
up in order to signal the readiness to act passively as a
responder if the peer wants to use DPD. For IKEv2, none
does't make sense, since all messages are used to detect
dead peers. If specified, it has the same meaning as the
default ( clear ).
dpddelay defines the period time interval with which R_U_THERE
messages/INFORMATIONAL exchanges are sent to the peer.
These are only sent if no other traffic is received. In
IKEv2, a value of 0 sends no additional INFORMATIONAL
messages and uses only standard messages (such as those
to rekey) to detect dead peers.
dpdtimeout defines the timeout interval, after which all connections
to a peer are deleted in case of inactivity. This only
applies to IKEv1, in IKEv2 the default retransmission
timeout applies, as every exchange is used to detect dead
peers.
inactivity defines the timeout interval, after which a CHILD_SA is
closed if it did not send or receive any traffic. Cur‐
rently supported in IKEv2 connections only.
eap defines the EAP type to propose as server if the client
requests EAP authentication. This parameter is deprecated
in the favour of leftauth.
To forward EAP authentication to a RADIUS server using
the EAP-RADIUS plugin, set eap=radius
eap_identity defines the identity the client uses to reply to a EAP
Identity request. If defined on the EAP server, the
defined identity will be used as peer identity during EAP
authentication. The special value %identity uses the EAP
Identity method to ask the client for a EAP identity. If
not defined, the IKEv2 identity will be used as EAP iden‐
tity.
esp ESP encryption/authentication algorithm to be used for
the connection, e.g. 3des-md5 (encryption-integrity-[dh-
group]). If dh-group is specified, CHILD_SA setup and
rekeying include a separate diffe hellman exchange (IKEv2
only).
forceencaps Force UDP encapsulation for ESP packets even if no NAT
situation is detected. This may help to hurdle restric‐
tive firewalls. To enforce the peer to encapsulate pack‐
ets, NAT detection payloads are faked (IKEv2 only).
ike IKE/ISAKMP SA encryption/authentication algorithm to be
used, e.g. aes128-sha1-modp2048 (encryption-integrity-
dhgroup). In IKEv2, multiple algorithms and proposals may
be included, such as
aes128-aes256-sha1-modp1536-modp2048,3des-
sha1-md5-modp1024.
ikelifetime how long the keying channel of a connection ('ISAKMP/IKE
SA') should last before being renegotiated.
installpolicy decides whether IPsec policies are installed in the ker‐
nel by the IKEv2 charon daemon for a given connection.
Allows peaceful co-existence e.g. with the Mobile IPv6
daemon mip6d who wants to control the kernel policies.
Acceptable values are yes (the default) and no.
keyexchange method of key exchange; which protocol should be used to
initialize the connection. Connections marked with ikev1
are initiated with pluto, those marked with ikev2 with
charon. An incoming request from the remote peer is han‐
dled by the correct daemon, unaffected from the keyex‐
change setting. The default value ike currently behaves
exactly as ikev1.
keyingtries how many attempts (a whole number or %forever) should be
made to negotiate a connection, or a replacement for one,
before giving up (default %forever). The value %forever
means 'never give up'. Relevant only locally, other end
need not agree on it.
keylife synonym for lifetime.
left (required) the IP address of the left participant's pub‐
lic-network interface, in any form accepted by ttoaddr(3)
or one of several magic values. If it is %defaultroute,
left will be filled in automatically with the local
address of the default-route interface (as determined at
IPsec startup time). (Either left or right may be
%defaultroute, but not both.) The value %any signifies
an address to be filled in (by automatic keying) during
negotiation. The prefix % in front of a fully-qualified
domain name or an IP address will implicitly set leftal‐
lowany=yes. If the domain name cannot be resolved into
an IP address at IPsec startup or update time then
left=%any and leftallowany=no will be assumed.
leftallowany a modifier for left , making it behave as %any although a
concrete IP address has been assigned. Recommended for
dynamic IP addresses that can be resolved by DynDNS at
IPsec startup or update time. Acceptable values are yes
and no (the default).
leftauth Authentication method to use (local) or require (remote)
in this connection. This parameter is supported in IKEv2
only. Acceptable values are pubkey for public key authen‐
tication (RSA/ECDSA), psk for pre-shared key authentica‐
tion and eap to (require the) use of the Extensible
Authentication Protocol. In the case of eap, an optional
EAP method can be appended. Currently defined methods are
eap-aka, eap-sim, eap-gtc, eap-md5 and eap-mschapv2.
Alternatively, IANA assigned EAP method numbers are
accepted. Vendor specific EAP methods are defined in the
form eap-type-vendor (e.g. eap-7-12345 ).
leftauth2 Same as leftauth, but defines an additional authentica‐
tion exchange. IKEv2 supports multiple authentication
rounds using "Multiple Authentication Exchanges" defined
in RFC4739. This allows, for example, separated authenti‐
cation of host and user (IKEv2 only).
leftca the distinguished name of a certificate authority which
is required to lie in the trust path going from the left
participant's certificate up to the root certification
authority.
leftca2 Same as leftca, but for the second authentication round
(IKEv2 only).
leftcert the path to the left participant's X.509 certificate. The
file can be coded either in PEM or DER format. OpenPGP
certificates are supported as well. Both absolute paths
or paths relative to /etc/ipsec.d/certs are accepted. By
default leftcert sets leftid to the distinguished name of
the certificate's subject and leftca to the distinguished
name of the certificate's issuer. The left participant's
ID can be overriden by specifying a leftid value which
must be certified by the certificate, though.
leftcert2 Same as leftcert, but for the second authentication round
(IKEv2 only).
leftfirewall whether the left participant is doing forwarding-fire‐
walling (including masquerading) using iptables for traf‐
fic from leftsubnet, which should be turned off (for
traffic to the other subnet) once the connection is
established; acceptable values are yes and no (the
default). May not be used in the same connection
description with leftupdown. Implemented as a parameter
to the default ipsec _updown script. See notes below.
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 pack‐
ets can flow unchanged through the tunnels. (This means
that all subnets connected in this manner must have dis‐
tinct, non-overlapping subnet address blocks.) This is
done by the default ipsec _updown script (see pluto(8)).
In situations calling for more control, it may be prefer‐
able for the user to supply his own updown script, which
makes the appropriate adjustments for his system.
leftgroups a comma separated list of group names. If the leftgroups
parameter is present then the peer must be a member of at
least one of the groups defined by the parameter. Group
membership must be certified by a valid attribute cer‐
tificate stored in /etc/ipsec.d/acerts/ thas has been
issued to the peer by a trusted Authorization Authority
stored in /etc/ipsec.d/aacerts/. Attribute certificates
are not supported in IKEv2 yet.
lefthostaccess
inserts a pair of INPUT and OUTPUT iptables rules using
the default ipsec _updown script, thus allowing access to
the host itself in the case where the host's internal
interface is part of the negotiated client subnet.
Acceptable values are yes and no (the default).
leftid how the left participant should be identified for authen‐
tication; defaults to left. Can be an IP address (in any
ttoaddr(3) syntax) or a fully-qualified domain name pre‐
ceded by @ (which is used as a literal string and not
resolved).
leftid2 identity to use for a second authentication for the left
participant (IKEv2 only); defaults to leftid.
leftikeport UDP port the left participant uses for IKE communication.
Currently supported in IKEv2 connections only. If unspec‐
ified, port 500 is used with port floating to 4500 if NAT
is detected or MOBIKE enabled. Specifying a local IKE
port different from the default additionally requires a
socket implementation that listens to this port.
leftnexthop this parameter is not needed any more because the NETKEY
IPsec stack does not require explicit routing entries for
the traffic to be tunneled.
leftprotoport restrict the traffic selector to a single protocol and/or
port. Examples: leftprotoport=tcp/http or leftproto‐
port=6/80 or leftprotoport=udp
leftrsasigkey the left participant's public key for RSA signature
authentication, in RFC 2537 format using ttodata(3)
encoding. The magic value %none means the same as not
specifying a value (useful to override a default). The
value %cert (the default) means that the key is extracted
from a certificate. The identity used for the left par‐
ticipant must be a specific host, not %any or another
magic value. Caution: if two connection descriptions
specify different public keys for the same leftid, confu‐
sion and madness will ensue.
leftsendcert Accepted values are never or no, always or yes, and
ifasked.
leftsourceip The internal source IP to use in a tunnel, also known as
virtual IP. If the value is %modeconfig, %modecfg, %con‐
fig, or %cfg, an address is requested from the peer. In
IKEv2, a defined address is requested, but the server may
change it. If the server does not support it, the address
is enforced.
rightsourceip The internal source IP to use in a tunnel for the remote
peer. If the value is %config on the responder side, the
initiator must propose a address which is then echoed
back. The IKEv2 daemon also supports address pools
expressed as network/netmask or the use of an external IP
address pool using %poolname , where poolname is the name
of the IP address pool used for the lookup.
leftsubnet private subnet behind the left participant, expressed as
network/netmask (actually, any form acceptable to ttosub‐
net(3)); if omitted, essentially assumed to be left/32,
signifying that the left end of the connection goes to
the left participant only. When using IKEv2, the config‐
ured subnet of the peers may differ, the protocol narrows
it to the greatest common subnet. Further, IKEv2 supports
multiple subnets separated by commas. IKEv1 only inter‐
prets the first subnet of such a definition.
leftsubnetwithin
the peer can propose any subnet or single IP address that
fits within the range defined by leftsubnetwithin. Not
relevant for IKEv2, as subnets are narrowed.
leftupdown what ``updown'' script to run to adjust routing and/or
firewalling when the status of the connection changes
(default ipsec _updown). May include positional parame‐
ters separated by white space (although this requires
enclosing the whole string in quotes); including shell
metacharacters is unwise. See pluto(8) for details.
Relevant only locally, other end need not agree on it.
IKEv2 uses the updown script to insert firewall rules
only. Routing is not support and will be implemented
directly into Charon.
lifebytes the number of bytes transmitted over an IPsec SA before
it expires (IKEv2 only).
lifepackets the number of packets transmitted over an IPsec SA before
it expires (IKEv2 only).
lifetime how long a particular instance of a connection (a set of
encryption/authentication keys for user packets) should
last, from successful negotiation to expiry; acceptable
values are an integer optionally followed by s (a time in
seconds) or a decimal number followed by m, h, or d (a
time in minutes, hours, or days respectively) (default
1h, maximum 24h). Normally, the connection is renegoti‐
ated (via the keying channel) before it expires (see
margintime). The two ends need not exactly agree on
lifetime, although if they do not, there will be some
clutter of superseded connections on the end which thinks
the lifetime is longer.
marginbytes how many bytes before IPsec SA expiry (see lifebytes)
should attempts to negotiate a replacement begin (IKEv2
only).
marginpackets how many packets before IPsec SA expiry (see lifepackets)
should attempts to negotiate a replacement begin (IKEv2
only).
margintime how long before connection expiry or keying-channel
expiry should attempts to negotiate a replacement begin;
acceptable values as for lifetime (default 9m). Relevant
only locally, other end need not agree on it.
mobike enables the IKEv2 MOBIKE protocol defined by RFC 4555.
Accepted values are yes (the default) and no. If set to
no, the IKEv2 charon daemon will not actively propose
MOBIKE as initiator and ignore the MOBIKE_SUPPORTED
notify as responder.
modeconfig defines which mode is used to assign a virtual IP.
Accepted values are push and pull (the default). Cur‐
rently relevant for IKEv1 only since IKEv2 always uses
the configuration payload in pull mode.
pfs whether Perfect Forward Secrecy of keys is desired on the
connection's keying channel (with PFS, penetration of the
key-exchange protocol does not compromise keys negotiated
earlier); acceptable values are yes (the default) and no.
IKEv2 always uses PFS for IKE_SA rekeying whereas for
CHILD_SA rekeying PFS is enforced by defining a Diffie-
Hellman modp group in the esp parameter.
pfsgroup defines a Diffie-Hellman group for perfect forward
secrecy in IKEv1 Quick Mode differing from the DH group
used for IKEv1 Main Mode (IKEv1 only).
reauth whether rekeying of an IKE_SA should also reauthenticate
the peer. In IKEv1, reauthentication is always done. In
IKEv2, a value of no rekeys without uninstalling the
IPsec SAs, a value of yes (the default) creates a new
IKE_SA from scratch and tries to recreate all IPsec SAs.
rekey whether a connection should be renegotiated when it is
about to expire; acceptable values are yes (the default)
and no. The two ends need not agree, but while a value
of no prevents Pluto/Charon from requesting renegotia‐
tion, it does not prevent responding to renegotiation
requested from the other end, so no will be largely inef‐
fective unless both ends agree on it.
rekeyfuzz maximum percentage by which marginbytes, marginpackets
and margintime should be randomly increased to randomize
rekeying intervals (important for hosts with many connec‐
tions); acceptable values are an integer, which may
exceed 100, followed by a `%' (defaults to 100%). The
value of marginTYPE, after this random increase, must not
exceed lifeTYPE (where TYPE is one of bytes, packets or
time). The value 0% will suppress randomization. Rele‐
vant only locally, other end need not agree on it.
rekeymargin synonym for margintime.
type the type of the connection; currently the accepted values
are tunnel (the default) signifying a host-to-host, host-
to-subnet, or subnet-to-subnet tunnel; transport, signi‐
fying host-to-host transport mode; transport_proxy, sig‐
nifying the special Mobile IPv6 transport proxy mode;
passthrough, signifying that no IPsec processing should
be done at all; drop, signifying that packets should be
discarded; and reject, signifying that packets should be
discarded and a diagnostic ICMP returned. Charon cur‐
rently supports tunnel, transport, and tunnel_proxy con‐
nection types, only .
xauth specifies the role in the XAUTH protocol if activated by
authby=xauthpsk or authby=xauthrsasig. Accepted values
are server and client (the default).
CONN PARAMETERS: IKEv2 MEDIATION EXTENSION
The following parameters are relevant to IKEv2 Mediation Extension
operation only.
mediation whether this connection is a mediation connection, ie.
whether this connection is used to mediate other connec‐
tions. Mediation connections create no child SA. Accept‐
able values are no (the default) and yes.
mediated_by the name of the connection to mediate this connection
through. If given, the connection will be mediated
through the named mediation connection. The mediation
connection must set mediation=yes.
me_peerid ID as which the peer is known to the mediation server,
ie. which the other end of this connection uses as its
leftid on its connection to the mediation server. This
is the ID we request the mediation server to mediate us
with. If me_peerid is not given, the rightid of this
connection will be used as peer ID.
CA SECTIONS
This are optional sections that can be used to assign special parame‐
ters to a Certification Authority (CA). These parameters are not sup‐
ported in IKEv2 yet.
auto currently can have either the value ignore or add
cacert defines a path to the CA certificate either relative to
/etc/ipsec.d/cacerts or as an absolute path.
crluri defines a CRL distribution point (ldap, http, or file URI)
crluri1 synonym for crluri.
crluri2 defines an alternative CRL distribution point (ldap, http, or
file URI)
ldaphost defines an ldap host. Currently used by IKEv1 only.
ocspuri defines an OCSP URI.
ocspuri1 synonym for ocspuri.
ocspuri2 defines an alternative OCSP URI. Currently used by IKEv2
only. certuribase defines the base URI for the Hash and URL
feature supported by IKEv2. Instead of exchanging complete
certificates, IKEv2 allows to send an URI that resolves to
the DER encoded certificate. The certificate URIs are built
by appending the SHA1 hash of the DER encoded certificates to
this base URI.
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 starter(8)). Here's an example:
config setup
plutodebug=all
crlcheckinterval=10m
strictcrlpolicy=yes
Parameters are optional unless marked ``(required)''. The currently-
accepted parameter names in a config setup section affecting both dae‐
mons are:
cachecrls certificate revocation lists (CRLs) fetched via http or
ldap will be cached in /etc/ipsec.d/crls/ under a unique
file name derived from the certification authority's pub‐
lic key. Accepted values are yes and no (the default).
charonstart whether to start the IKEv2 Charon daemon or not.
Accepted values are yes or no. The default is yes if
starter was compiled with IKEv2 support.
dumpdir in what directory should things started by ipsec starter
(notably the Pluto and Charon daemons) be allowed to dump
core? The empty value (the default) means they are not
allowed to. This feature is currently not yet supported
by ipsec starter.
plutostart whether to start the IKEv1 Pluto daemon or not. Accepted
values are yes or no. The default is yes if starter was
compiled with IKEv1 support.
strictcrlpolicy
defines if a fresh CRL must be available in order for the
peer authentication based on RSA signatures to succeed.
Accepted values are yes and no (the default). IKEv2
additionally recognizes ifuri which reverts to yes if at
least one CRL URI is defined and to no if no URI is
known.
uniqueids whether a particular participant ID should be kept
unique, with any new (automatically keyed) connection
using an ID from a different IP address deemed to replace
all old ones using that ID; acceptable values are yes
(the default) and no. Participant IDs normally are
unique, so a new (automatically-keyed) connection using
the same ID is almost invariably intended to replace an
old one. The IKEv2 daemon also accepts the value replace
wich is identical to yes and the value keep to reject new
IKE_SA setups and keep the duplicate established earlier.
The following config section parameters are used by the IKEv1 Pluto
daemon only:
crlcheckinterval
interval in seconds. CRL fetching is enabled if the value is
greater than zero. Asynchronous, periodic checking for fresh
CRLs is currently done by the IKEv1 Pluto daemon only.
keep_alive
interval in seconds between NAT keep alive packets, the default
being 20 seconds.
nat_traversal
activates NAT traversal by accepting source ISAKMP ports differ‐
ent from udp/500 and being able of floating to udp/4500 if a NAT
situation is detected. Accepted values are yes and no (the
default). Used by IKEv1 only, NAT traversal always being active
in IKEv2.
nocrsend
no certificate request payloads will be sent. Accepted values
are yes and no (the default).
pkcs11initargs
non-standard argument string for PKCS#11 C_Initialize() func‐
tion; required by NSS softoken.
pkcs11module
defines the path to a dynamically loadable PKCS #11 library.
pkcs11keepstate
PKCS #11 login sessions will be kept during the whole lifetime
of the keying daemon. Useful with pin-pad smart card readers.
Accepted values are yes and no (the default).
pkcs11proxy
Pluto will act as a PKCS #11 proxy accessible via the whack
interface. Accepted values are yes and no (the default).
plutodebug
how much Pluto debugging output should be logged. An empty
value, or the magic value none, means no debugging output (the
default). The magic value all means full output. Otherwise
only the specified types of output (a quoted list, names without
the --debug- prefix, separated by white space) are enabled; for
details on available debugging types, see pluto(8).
plutostderrlog
Pluto will not use syslog, but rather log to stderr, and redi‐
rect stderr to the argument file.
postpluto
shell command to run after starting Pluto (e.g., to remove a
decrypted copy of the ipsec.secrets file). It's run in a very
simple way; complexities like I/O redirection are best hidden
within a script. Any output is redirected for logging, so run‐
ning interactive commands is difficult unless they use /dev/tty
or equivalent for their interaction. Default is none.
prepluto
shell command to run before starting Pluto (e.g., to decrypt an
encrypted copy of the ipsec.secrets file). It's run in a very
simple way; complexities like I/O redirection are best hidden
within a script. Any output is redirected for logging, so run‐
ning interactive commands is difficult unless they use /dev/tty
or equivalent for their interaction. Default is none.
virtual_private
defines private networks using a wildcard notation.
The following config section parameters are used by the IKEv2 Charon
daemon only:
charondebug
how much Charon debugging output should be logged. A comma sep‐
arated list containing type level/pairs may be specified, e.g:
dmn 3, ike 1, net -1. Acceptable values for types are dmn, mgr,
ike, chd, job, cfg, knl, net, enc, lib and the level is one of
-1, 0, 1, 2, 3, 4 (for silent, audit, control, controlmore, raw,
private).
The following config section parameters only make sense if the KLIPS
IPsec stack is used instead of the default NETKEY stack of the Linux
2.6 kernel:
fragicmp
whether a tunnel's need to fragment a packet should be reported
back with an ICMP message, in an attempt to make the sender
lower his PMTU estimate; acceptable values are yes (the default)
and no.
hidetos
whether a tunnel packet's TOS field should be set to 0 rather
than copied from the user packet inside; acceptable values are
yes (the default) and no
interfaces
virtual and physical interfaces for IPsec to use: a single vir‐
tual=physical pair, a (quoted!) list of pairs separated by white
space, or %none. One of the pairs may be written as %default‐
route, which means: find the interface d that the default route
points to, and then act as if the value was ``ipsec0=d''.
%defaultroute is the default; %none must be used to denote no
interfaces.
overridemtu
value that the MTU of the ipsecn interface(s) should be set to,
overriding IPsec's (large) default.
CHOOSING A CONNECTION
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 sub‐
nets 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 which
doesn't match an ordinary conn, an opportunistic connection may be
instantiated. Eventually, its instance will be /32 -> /32, but for ear‐
lier stages of the negotiation, there will not be enough information
about the client subnets to complete the instantiation.
FILES
/etc/ipsec.conf
/etc/ipsec.d/aacerts
/etc/ipsec.d/acerts
/etc/ipsec.d/cacerts
/etc/ipsec.d/certs
/etc/ipsec.d/crls
SEE ALSOipsec(8), pluto(8), starter(8), ttoaddr(3), ttodata(3)HISTORY
Written for the FreeS/WAN project by Henry Spencer. Extended for
the strongSwan project <http://www.strongswan.org> by Andreas Steffen.
IKEv2-specific features by Martin Willi.
BUGS
If conns are to be added before DNS is available, left=FQDN will fail.
27 Jun 2007 IPSEC.CONF(5)