Project

General

Profile

ipsec.conf: conn Reference » History » Version 14

« Previous - Version 14/101 (diff) - Next » - Current version
Martin Willi, 02.10.2007 19:04
changed force_encap to forceencaps


= 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'').
  • ''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|sim''
    defines the EAP type to be used if ''authby=eap'' is selected. Currently supported values are ''aka''
    for EAP-AKA and ''sim'' for EAP-SIM.
  • ''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.
  • ''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.
  • ''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|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;
    ''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'' and ''transport'' 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|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|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|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|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
    into Charon.