NAME¶

ipsec.conf - IPsec configuration and connections

DESCRIPTION¶

The optional ipsec.conf file specifies most configuration and control information for the Openswan IPsec subsystem. (The major exception is secrets for authentication; see ipsec.secrets(5).) Its contents are not security-sensitive unless manual keying is being done for more than just testing, in which case the encryption/authentication keys in the descriptions for the manually-keyed connections are very sensitive (and those connection descriptions are probably best kept in a separate file, via the include facility described below).

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

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 considered 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., without having to constantly extract them from the configuration file and then insert them back into it. Note also the also and alsoflip parameters (described below) which permit splitting a single logical section (e.g. a connection description) into several actual sections.

The first significant line of the file must specify the version of this specification that it conforms to:

version 2

A section begins with a line of the form:

type name

where type indicates what type of section follows, and name is an arbitrary 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 section:

also

alsoflip

Parameter names beginning with x- (or X-, or x_, or X_) are reserved for user extensions and will never be assigned meanings by IPsec. Parameters with such names must still observe the syntax rules (limits on characters used in the name; no white space in a non-quoted value; no newlines or double quotes within the value). All other as-yet-unused parameter names are reserved for future IPsec improvements.

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 contain also or alsoflip parameters.

Currently there are two types of section: a config section specifies general configuration information for IPsec, while a conn section specifies an IPsec connection.

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 to ipsec_auto(8) and ipsec_manual(8). Here´s a simple example:

conn snt
	left=10.11.11.1
	leftsubnet=10.0.1.0/24
	leftnexthop=172.16.55.66
	leftsourceip=10.0.1.1
	right=192.168.22.1
	rightsubnet=10.0.2.0/24
	rightnexthop=172.16.88.99
	rightsourceip=10.0.2.1
	keyingtries=%forever

A note on terminology... In automatic keying, 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 data path (a set of “IPsec SAs”) used for user packets is herein referred to as the “connection”; the path used for negotiations (built with “ISAKMP SAs”) is referred to as the “keying channel”.

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 arbitrary; 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 convention 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)”; a parameter required for manual keying need not be included for a connection which will use only automatic keying, and vice versa.

                cipher:                 3des or aes128


                hash:                   sha1 or md5


                pfsgroup (DHgroup):     modp1024 or modp1536

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 ipsec_setup(8)). Here´s an example:

config setup
	interfaces="ipsec0=eth1 ipsec1=ppp0"
	klipsdebug=none
	plutodebug=control
	protostack=auto
	manualstart=

Parameters are optional unless marked “(required)”.

The currently-accepted parameter names in a config setup section are:

myid

protostack

interfaces

listen

nat_traversal

disable_port_floating

force_keepalive

keep_alive

virtual_private

oe

nhelpers

crlcheckinterval

strictcrlpolicy

forwardcontrol

rp_filter

syslog

klipsdebug

plutodebug

uniqueids

plutorestartoncrash

plutoopts

plutostderrlog

pluto

plutowait

prepluto

postpluto

dumpdir

fragicmp

hidetos

overridemtu

IMPLICIT CONNS¶

The system automatically defines several conns to implement default policy groups. Each can be overridden by explicitly defining a new conn with the same name. If the new conn has auto=ignore, the definition is suppressed.

Here are the automatically supplied definitions.

conn clear
	type=passthrough
	authby=never
	left=%defaultroute
	right=%group
	auto=route
conn clear-or-private
	type=passthrough
	left=%defaultroute
	leftid=%myid
	right=%opportunisticgroup
	failureshunt=passthrough
	keyingtries=3
	ikelifetime=1h
	salifetime=1h
	rekey=no
	auto=route
conn private-or-clear
	type=tunnel
	left=%defaultroute
	leftid=%myid
	right=%opportunisticgroup
	failureshunt=passthrough
	keyingtries=3
	ikelifetime=1h
	salifetime=1h
	rekey=no
	auto=route
conn private
	type=tunnel
	left=%defaultroute
	leftid=%myid
	right=%opportunisticgroup
	failureshunt=drop
	keyingtries=3
	ikelifetime=1h
	salifetime=1h
	rekey=no
	auto=route
conn block
	type=reject
	authby=never
	left=%defaultroute
	right=%group
	auto=route
# default policy
conn packetdefault
	type=tunnel
	left=%defaultroute
	leftid=%myid
	left=0.0.0.0/0
	right=%opportunistic
	failureshunt=passthrough
	keyingtries=3
	ikelifetime=1h
	salifetime=1h
	rekey=no
	auto=route

These conns are not affected by anything in conn %default. They will only work if %defaultroute works. The leftid will be the interfaces IP address; this requires that reverse DNS records be set up properly.

The implicit conns are defined after all others. It is appropriate and reasonable to use also=private-or-clear (for example) in any other opportunistic conn.

POLICY GROUP FILES¶

The optional files under /etc/ipsec.d/policy, including

/etc/ipsec.d/policies/clear
/etc/ipsec.d/policies/clear-or-private
/etc/ipsec.d/policies/private-or-clear
/etc/ipsec.d/policies/private
/etc/ipsec.d/policies/block

may contain policy group configuration information to supplement ipsec.conf. Their contents are not security-sensitive.

These files are text files. Each consists of a list of CIDR blocks, one per line. White space followed by # followed by anything to the end of the line is a comment and is ignored, as are empty lines.

A connection in ipsec.conf which has right=%group or right=%opportunisticgroup is a policy group connection. When a policy group file of the same name is loaded, with

     ipsec auto --rereadgroups

or at system start, the connection is instantiated such that each CIDR block serves as an instance´s right value. The system treats the resulting instances as normal connections.

For example, given a suitable connection definition private, and the file /etc/ipsec.d/policy/private with an entry 192.0.2.3, the system creates a connection instance private#192.0.2.3. This connection inherits all details from private, except that its right client is 192.0.2.3.

DEFAULT POLICY GROUPS¶

The standard Openswan install includes several policy groups which provide a way of classifying possible peers into IPsec security classes: private (talk encrypted only), private-or-clear (prefer encryption), clear-or-private (respond to requests for encryption), clear and block. Implicit policy groups apply to the local host only, and are implemented by the IMPLICIT CONNECTIONS described above.

CHOOSING A CONNECTION [THIS SECTION IS EXTREMELY OUT OF DATE¶

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 subnets 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 earlier 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/policies/clear
/etc/ipsec.d/policies/clear-or-private
/etc/ipsec.d/policies/private-or-clear
/etc/ipsec.d/policies/private
/etc/ipsec.d/policies/block

SEE ALSO¶

ipsec(8), ipsec_ttoaddr(8), ipsec_auto(8), ipsec_manual(8), ipsec_rsasigkey(8)

HISTORY¶

Designed for the FreeS/WAN project <http://www.freeswan.org> by Henry Spencer.

BUGS¶

Before reporting new bugs, please ensure you are using the latest version of Openswan, and if not using KLIPS, please ensure you are using the latest kernel code for your IPsec stack.

When type or failureshunt is set to drop or reject, Openswan blocks outbound packets using eroutes, but assumes inbound blocking is handled by the firewall. Openswan offers firewall hooks via an “updown” script. However, the default ipsec _updown provides no help in controlling a modern firewall.

Including attributes of the keying channel (authentication methods, ikelifetime, etc.) as an attribute of a connection, rather than of a participant pair, is dubious and incurs limitations.

The use of %any with the protoport= option is ambiguous. Should the SA permits any port through or should the SA negotiate any single port through? The first is a basic conn with a wildcard. The second is a template. The second is the current behaviour, and it´s wrong for quite a number of uses involving TCP. The keyword %one may be introduced in the future to separate these two cases.

ipsec_manual is not nearly as generous about the syntax of subnets, addresses, etc. as the usual Openswan user interfaces. Four-component dotted-decimal must be used for all addresses. It is smart enough to translate bit-count netmasks to dotted-decimal form.

It would be good to have a line-continuation syntax, especially for the very long lines involved in RSA signature keys.

First packet caching is only implemented for the KLIPS(NG) and MAST stacks. NETKEY returns POSIX-breaking responses, visiable as connect: Resource temporarily unavailable errors. This affects Opportunistic Encryption and DPD. Functionality on the BSD and Windows stacks is unknown.

Some state information is only available when using KLIPS, and will return errors on other IPsec stacks. These include ipsec eroute, ipsec spi and ipsec look.

Multiple L2TP clients behind the same NAT router, and multiple L2TP clients behind different NAT routers using the same Virtual IP is currently only working for the KLIPSNG stack.

The ability to specify different identities, authby, and public keys for different automatic-keyed connections between the same participants is misleading; this doesn´t work dependably because the identity of the participants is not known early enough. This is especially awkward for the “Road Warrior” case, where the remote IP address is specified as 0.0.0.0, and that is considered to be the “participant” for such connections.

In principle it might be necessary to control MTU on an interface-by-interface basis, rather than with the single global override that overridemtu provides. This feature is planned for a future release.

A number of features which could be implemented in both manual and automatic keying actually are not yet implemented for manual keying. This is unlikely to be fixed any time soon.

If conns are to be added before DNS is available, left=FQDN, leftnextop=FQDN, and leftrsasigkey=%dnsonload will fail. ipsec_pluto(8) does not actually use the public key for our side of a conn but it isn´t generally known at a add-time which side is ours (Road Warrior and Opportunistic conns are currently exceptions).

The myid option does not affect explicit ipsec auto --add or ipsec auto --replace commands for implicit conns.