ipsec.conf: conn Reference » History » Version 20
= conn <name> =
'''general per connection parameters:'''
- ''ah = ''<algorithms>
AH authentication algorithm to be used for the connection, e.g. ''hmac-md5''.
- ''also = ''<section name>
includes conn section <name>.
- ''auth = '''esp'''|ah''
whether authentication should be done as part of ESP encryption, or separately using the AH protocol.
The IKEv2 daemon currently supports ESP only.
- ''authby = '''rsasig'''|psk|secret|xauthrsasig|xauthpsk|eap|never''
how the two security gateways should authenticate each other; acceptable values are '''secret''' or '''psk'''
for shared secrets, '''rsasig''' for RSA digital signatures, and '''never''' if negotiation is never to be
attempted or accepted (useful for shunt-only conns). Digital signatures are superior in every way to shared
secrets. In IKEv2, the two ends must not agree on this parameter, it is relevant for the out-bound
authentication method only. IKEv1 additionally supports the values '''xauthpsk''' and '''xauthrsasig''' that
will enable ''eXtended AUTHentication (XAUTH)'' in addition to IKEv1 main mode based on shared secrets
or digital RSA signatures, respectively. IKEv2 additionally supports the value '''eap''', which indicates
an initiator to request EAP authentication. The EAP method to use is selected by the server (see ''eap'').
This parameter is deprecated for IKEv2 connections, as two peers do ot need to agree on an authentication
method. Use the ''left|rightauth'' parameter to define authentication methods in IKEv2.
- ''auto = '''ignore'''|add|route|start''
what operation, if any, should be done automatically at IPsec startup. '''add''' loads a connection without
starting it. '''route''' loads a connection and installs kernel 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 = yes|'''no'''''
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). 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 = '''none'''|clear|hold|restart''
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 periodically sent in order to check the liveliness of the
IPsec peer. The values '''clear''', '''hold''', and '''restart''' all activate 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 = ''<time>
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 = ''<time>
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.
- ''eap = aka|gtc|md5|mschapv2|radius|sim|<type>|<type>-<vendor>''
defines the EAP type to be used if ''authby=eap'' is selected. Currently supported values are '''aka'''
for EAP-AKA, '''gtc''' for EAP-GTC, '''md5''' for EAP-MD5, '''mschapv2''' for EAP-MS-CHAPv2, '''radius''' for the
EAP-RADIUS proxy and '''sim''' for EAP-SIM.
Additionally, IANA assigned EAP method numbers are accepted, or a definition in the form '''eap=type-vendor'''
(e.g. eap=7-12345 ) can be used to specify vendor specific EAP types. For IKEv2 this parameter is deprecated
in favour of ''left|rightauth''.
defines the identity the client uses to reply to an 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 identity.
- ''esp = ''<cipher suites>
comma-separated list of ESP encryption/authentication algorithms to be used for the connection, e.g.
''3des-md5''. The notation is ''encryption-integrity-[dhgroup]''. If ''dh-group'' is specified,
CHILD_SA setup and rekeying include a separate Diffe-Hellman exchange (IKEv2 only).
- ''forceencaps = yes|'''no'''''
Force UDP encapsulation for ESP packets even if no NAT situation is detected.
This may help to surmount restrictive firewalls. In order to force the peer to
encapsulate packets, NAT detection payloads are faked (IKEv2 only).
- ''ike = ''<cipher suites>
comma-separated list of IKE/ISAKMP SA encryption/authentication algorithms to be used, e.g.
''aes128-sha1-modp2048''. The notation is ''encryption-integrity-dhgroup''. In IKEv2, multiple algorithms
and proposals may be included, such as ''aes128-aes256-sha1-modp1536-modp2048,3des-sha1-md5-modp1024''.
- ''ikelifetime = '''3h'''|''<time>
how long the keying channel of a connection (''ISAKMP or IKE SA'') should last before being renegotiated.
- ''installpolicy = '''yes'''|no''
decides whether IPsec policies are installed in the kernel by the IKEv2 charon daemon for a given connection.
Allows peaceful cooperation e.g. with the Mobile IPv6 ''mip6d'' daemon who wants to control the kernel policies.
- ''keyexchange = '''ike'''|ikev1|ikev2''
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 handled by the correct daemon, unaffected from the ''keyexchange'' setting. The default
value '''ike''' currently is a synonym for '''ikev1'''.
- ''keyingtries = '''%forever'''''|<number>
how many attempts (a whole number or ''%forever'') should be made to negotiate a connection, or a replacement
for one, before giving up. The value ''%forever'' means 'never give up'. Relevant only locally, other end need
not agree on it.
- ''keylife = '''1h'''|''<time>
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 renegotiated (via the
keying channel) before it expires. The two ends need not exactly agree on ''keylife'', although if they
do not, there will be some clutter of superseded connections on the end which thinks the lifetime is longer.
- ''mobike = '''yes'''|no''
enables the IKEv2 [wiki:MobIke MOBIKE] protocol defined by RFC 4555. If set to '''no''', the IKEv2 charon
daemon will not actively propose [wiki:MobIke MOBIKE] but will still accept and support the mobility protocol
as a responder.
- ''modeconfig = push|'''pull'''''
defines which mode is used to assign a virtual IP. Currently relevant for IKEv1 only since IKEv2 always uses
the configuration payload in '''pull''' mode. Cisco VPN gateways usually operate in '''push''' mode.
- ''pfs = '''yes'''|no''
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). IKEv2 always uses
PFS for IKE_SA rekeying whereas for CHILD_SA rekeying PFS is enforced by defining a Diffie-Hellman dhgroup
in the ''esp'' parameter.
- ''pfsgroup = ''<modp group>
defines a Diffie-Hellman group for ''perfect forward secrecy'' in IKEv1 Quick Mode differing from the DH group
used for IKEv1 Main Mode (IKEv1 pluto daemon only).
- ''reauth = '''yes'''|no''
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 = '''yes'''|no''
whether a connection should be renegotiated when it is about to expire. The two ends need not agree, but
while a value of no prevents Pluto/Charon from requesting renegotiation, it does not prevent responding
to renegotiation requested from the other end, so no will be largely ineffective unless both ends agree on it.
- ''rekeyfuzz = '''100%'''|''<percentage>
maximum percentage by which rekeymargin should be randomly increased to randomize rekeying intervals (important
for hosts with many connections); acceptable values are an integer, which may exceed 100, followed by a '%' .
The value of ''rekeymargin'', after this random increase, must not exceed ''keylife''. The value ''0%'' will
suppress time randomization. Relevant only locally, other end need not agree on it.
- ''rekeymargin = '''9m'''|''<time>
how long before connection expiry or keying-channel expiry should attempts to negotiate a replacement begin.
Relevant only locally, other end need not agree on it.
- ''type = '''tunnel'''|transport|transport_proxy|passthrough|drop|reject''
the type of the connection; currently the accepted values are '''tunnel''', signifying a host-to-host,
host-to-subnet, or subnet-to-subnet tunnel; '''transport''', signifying host-to-host transport mode;
'''transport_proxy''', signifying 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 currently supports only '''tunnel'', '''transport''', and '''transport_proxy''' connection types.
- ''xauth = '''client'''|server''
specifies the role in the XAUTH protocol if activated by ''authby=xauthpsk'' or ''authby=xauthrsasig''.
'''left|right end parameters:'''
- ''left|right = ''<ip address>|<fqdn>|''%defaultroute|%any''
(required) the IP address of the left participant's public-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 ''leftallowany=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.
- ''left|rightallowany = yes|'''no'''''
a modifier for ''left|right'', 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.
- ''left|rightauth = ''<auth method>
Authentication method to use locally (left) or require from the remote (right) side. This parameter is
supported in IKEv2 only. Acceptable values are '''pubkey''' for public key encryption (RSA/ECDSA), '''psk'''
for pre-shared key authentication, 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.
- ''left|rightauth2 = ''<auth method>
Same as ''left|rightauth'', but defines a second authentication exchange. IKEv2 supports multiple authentication
rounds using ''Multiple Authentication Exchanges'' defined in [http://tools.ietf.org/html/rfc4739 RFC 4739].
This allows e.g. a separate authentication of host and user (IKEv2 only).
- ''left|rightca = ''<issuer dn>|''%same''
the distinguished name of a certificate authority which is required to lie in the trust path going from the
''left|right'' participant's certificate up to the root certification authority.
- ''left|rightca2 = ''<issuer dn>|''%same''
Same as ''left|rightca'' but defines an additional authentication exchange. IKEv2 supports multiple
authentication rounds using ''Multiple Authentication Exchanges' defined in [http://tools.ietf.org/html/rfc4739 RFC 4739].
This allows e.g. separate authentication of host and user (IKev2 only).
- ''left|rightcert = ''<path>
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
[wiki:IpsecDirectoryCerts /etc/ipsec.d/certs] are accepted. By default ''left|rightcert'' sets ''left|rightid''
to the distinguished name of the certificate's subject and ''left|rightca'' to the distinguished name of
the certificate's issuer. The ''left|right'' participant's ID can be overridden by specifying a ''left|rightid''
value which must be certified by the certificate, though.
- ''left|rightcert2 = ''<path>
Same as ''left|rightcert'' but for the second authentication round (IKEv2 only).
- ''left|rightfirewall = yes|'''no'''''
whether the ''left|right'' participant is doing forwarding-firewalling (including masquerading)
using iptables for traffic from ''left|rightsubnet'', which should be turned off for traffic to the
other subnet) once the connection is established. May not be used in the same connection description with
''left|rightupdown''. Implemented as a parameter to the default ''ipsec _updown'' script. 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
''ipsec _updown'' script (see pluto(8)).
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.
- ''left|rightgroups = ''<group list>
a comma-separated list of group names. If the ''left|rightgroups'' 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 certificate stored in [wiki:IpsecDirectoryAcerts /etc/ipsec.d/acerts/] thas has been issued
to the peer by a trusted Authorization Authority stored in [wiki:IpsecDirectoryAacerts /etc/ipsec.d/aacerts/].
Attribute certificates are not supported in IKEv2 yet.
- ''left|righthostaccess = yes|'''no'''''
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.
- ''left|rightid = ''<id>
how the ''left|right'' participant should be identified for authentication; defaults to ''left|right''.
Can be an IP address (in any ttoaddr(3) syntax) or a fully-qualified domain name preceded by ''@''
(which is used as a literal string and not resolved).
- ''left|rightid2 = ''<id>
Identity to use for the second authentication of the left participant (IKEv2 only).
Defaults to ''left|rightid''.
- ''left|rightnexthop = %direct|%defaultroute|''<ip address>|<fqdn>
this parameter is usually not needed any more because the NETKEY IPsec stack does not require
explicit routing entries for the traffic to be tunneled. If ''left|sourceip'' is used with IKEv1
then ''left|rightnexthop'' must still be set in order for the source routes to work properly.
- ''left|rightprotoport = ''<protocol>/<port>
restrict the traffic selector to a single protocol and/or port. Examples: ''leftprotoport=tcp/http''
or ''leftprotoport=6/80'' or ''rightprotoport=udp''
- ''left|rightrsasigkey = '''%cert'''|''<raw rsa public key>
the left participantâs public key for RSA signature authentication, in RFC 2537 format using ttodata(3)
encoding. The default value ''%cert'' means that the key is extracted from a certificate.
- ''left|rightsendcert = never|no|'''ifasked'''|always|yes''
Accepted values are '''never''' or '''no''', '''always''' or '''yes''', and '''ifasked''', the latter meaning that
the peer must send a certificate request (CR) payload in order to get a certificate in return.
- ''left|rightsourceip = %config|%cfg|%modeconfig|%modecfg|''<ip address>
The internal source IP to use in a tunnel, also known as [wiki:VirtualIp virtual IP].
If the value is one of the synonyms ''%modeconfig, %modecfg, %config'', or ''%cfg'', an address is
requested from the peer. In IKEv2, a statically defined address is also requested, since the server
may change it.
If ''leftsourceip=%config'' is set to request a [wiki:VirtualIp virtual IP] from the peer then the
responder must define the address-to-be-assigned using a separate conn section with a ''rightsourceip''
statement for each client.
- ''left|rightsubnet = ''<ip subnet>
private subnet behind the left participant, expressed as network/netmask (actually, any form acceptable to
ttosubnet(3)); if omitted, essentially assumed to be left/32, signifying that the ''left|right'' end of the
connection goes to the ''left|right'' participant only. When using IKEv2, the configured subnet of the peers
may differ, the protocol narrows it to the greatest common subnet.
- ''left|rightsubnetwithin = ''<ip subnet>
the peer can propose any subnet or single IP address that fits within the range defined by
''left|rightsubnetwithin''. Not relevant for IKEv2, as subnets are narrowed.
- ''left|rightupdown = ''<path>
what ''updown'' script to run to adjust routing and/or firewalling when the status of the connection
changes (default ''ipsec _updown''). Relevant only locally, other end need not agree on it.
IKEv2 uses the ''updown'' script to insert firewall rules only, since routing has been implemented directly