ipsec.conf man page on SuSE

Man page or keyword search:  
man Server   14857 pages
apropos Keyword Search (all sections)
Output format
SuSE logo
[printable version]

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 ALSO
       ipsec(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)
[top]

List of man pages available for SuSE

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net