Project

General

Profile

ipsec.conf: conn Reference » History » Version 38

« Previous - Version 38/101 (diff) - Next » - Current version
Andreas Steffen, 11.10.2010 06:28
updated keyexchange entry


conn <name>

general per connection parameters

aaa_identity = <id>

defines the identity of the AAA backend used during IKEv2 EAP authentication. This is required if
the EAP client uses a method that verifies the server identity (such as EAP-TLS), but it does not
match the IKEv2 gateway identity.

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 = pubkey | rsasig | ecdsasig | psk | secret | xauthrsasig | xauthpsk | eap | never

how the two security gateways should authenticate each other; acceptable values are secret or psk
for pre-shared secrets, pubkey 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 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.

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.

inactivity = <time>

defines the timeout interval, after which a CHILD_SA is closed if it did not send or receive any traffic.
Currently supported in IKEv2 connections only.

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.

eap_identity = <id>

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. Starting with
strongSwan 4.5 the default value ike is a synonym for ikev2, whereas in older strongSwan releases ikev1
was assumed.

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

synonym for lifetime.

lifebytes = <number>

the number of bytes transmitted over an IPsec SA before it expires (IKEv2 only).

lifepackets = <number>

the number of packets transmitted over an IPsec SA before it expires (IKEv2 only).

lifetime = 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 (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 = <number>

how many bytes before IPsec SA expiry (see lifebytes) should attempts to negotiate a replacement begin (IKEv2 only).

marginpackets = <number>

how many packets before IPsec SA expiry (see lifepackets) should attempts to negotiate a replacement begin (IKEv2 only).

margintime = 9m | <time>

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.

mark = <value>[/<mask>]

sets an XFRM mark in the inbound and outbound IPsec SAs and policies. If the mask is missing then
a default mask of 0xffffffff is assumed.

mark_in = <value>[/<mask>]

sets an XFRM mark in the inbound IPsec SA and policy. If the mask is missing then
a default mask of 0xffffffff is assumed.

mark_out = <value>[/<mask>]

sets an XFRM mark in the outbound IPsec SA and policy. If the mask is missing then
a default mask of 0xffffffff is assumed.

mobike = yes | no

enables the IKEv2 MOBIKE protocol defined by RFC 4555. If set to no, the IKEv2 charon
daemon will not actively propose 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 marginbytes, marginpackets and margintime 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 marginTYPE, after this random increase, must not exceed lifeTYPE (where TYPE is one of bytes, packets or type).
The value 0% will suppress randomization. Relevant only locally, other end need not agree on it.

rekeymargin

synonym for margintime.

reqid

sets the reqid for a given connection to a pre-configured fixed value (IKEv2 only).

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

Connection descriptions are defined in terms of a left endpoint and a right endpoint. For example, the
two parameters leftid and rightid specify the identity of the left and the right endpoint. For every
connection description an attempt is made to figure out whether the local endpoint should act as the left or
the right endpoint. This is done by matching the IP addresses defined for both endpoints with the
IP addresses assigned to local network interfaces. If a match is found then the role (left or right) that
matches is going to be considered "local". If no match is found during startup, "left" is considered "local".

left|right = <ip address> | <fqdn> | %defaultroute | %any

(required) the IP address of the participant's public-network interface or one of several magic values.
If it is %defaultroute, the value will be filled in automatically with the local address of
the default-route interface (as determined at IPsec startup time and during configuration
update). Either left or right may be %defaultroute, but not both. 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.

In case of an IKEv2 connection, the value %any for the local endpoint signifies an address to be filled in
(by automatic keying) during negotiation. If the local peer initiates the connection setup the routing table
will be queried to determine the correct local IP address. In case the local peer is responding to a connection
setup then any IP address that is assigned to a local interface will be accepted. Note that specifying %any
for the local endpoint is not supported by the IKEv1 pluto daemon.

If %any is used for the remote endpoint it literally means any IP address.

Please note that with the usage of wildcards multiple connection descriptions might match a given incoming
connection attempt. The most specific description is used in that case.

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.
eap-7-12345).

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 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 for the second authentication (IKev2 only).

left|rightcert = <path>

the path to the left|right participant's X.509 certificate. The file can be coded either in PEM or DER format.
OpenPGP certificates are supported as well (IKEv1 only). Both absolute paths or paths relative to
/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 /etc/ipsec.d/acerts that 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.

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 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.

leftikeport = <port>

UDP port the left participant uses for IKE communication. Currently supported in IKEv2 connections only.
If unspecified, port 500 is used with the port floating to 4500 if a NAT is detected or MOBIKE is enabled.
Specifying a local IKE port different from the default additionally requires a socket implementation that
listens to this port.

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.

leftsourceip = %config | %cfg | %modeconfig | %modecfg | <ip address>

The internal source IP to use in a tunnel, also known as 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 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.

rightsourceip = %config | <network>/<netmask> | %poolname

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 an address which is then echoed back. Also supported are 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 (see virtual IP for details).

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. Further, IKEv2 supports multiple
subnets separated by commas. IKEv1 only interprets the first subnet of such a definition.

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
into Charon.