1 Content-type: text/html
3 <HTML><HEAD><TITLE>Manpage of IPSEC.CONF
</TITLE>
6 Section: File Formats (
5)
<BR>Updated:
26 Nov
2001<BR><A HREF=
"#index">Index
</A>
7 <A HREF=
"http://localhost/cgi-bin/man/man2html">Return to Main Contents
</A><HR>
10 <A NAME=
"lbAB"> </A>
13 ipsec.conf - IPsec configuration and connections
14 <A NAME=
"lbAC"> </A>
21 specifies most configuration and control information for the
22 FreeS/WAN IPsec subsystem.
23 (The major exception is secrets for authentication;
25 <I><A HREF=
"ipsec.secrets.5.html">ipsec.secrets
</A></I>(
5).)
27 Its contents are not security-sensitive
30 manual keying is being done for more than just testing,
31 in which case the encryption/authentication keys in the
32 descriptions for the manually-keyed connections are very sensitive
33 (and those connection descriptions
34 are probably best kept in a separate file,
35 via the include facility described below).
38 The file is a text file, consisting of one or more
41 White space followed by
44 followed by anything to the end of the line
45 is a comment and is ignored,
46 as are empty lines which are not within a section.
52 and a file name, separated by white space,
53 is replaced by the contents of that file,
54 preceded and followed by empty lines.
55 If the file name is not a full pathname,
56 it is considered to be relative to the directory containing the
58 Such inclusions can be nested.
59 Only a single filename may be supplied, and it may not contain white space,
60 but it may include shell wildcards (see
61 <I><A HREF=
"sh.1.html">sh
</A></I>(
1));
72 The intention of the include facility is mostly to permit keeping
73 information on connections, or sets of connections,
74 separate from the main configuration file.
75 This permits such connection descriptions to be changed,
76 copied to the other security gateways involved, etc.,
77 without having to constantly extract them from the configuration
78 file and then insert them back into it.
85 parameters (described below) which permit splitting a single logical section
86 (e.g. a connection description) into several actual sections.
89 The first significant line of the file must specify the version
90 of this specification that it conforms to:
97 begins with a line of the form:
109 indicates what type of section follows, and
112 is an arbitrary name which distinguishes the section from others
114 (Names must start with a letter and may contain only
115 letters, digits, periods, underscores, and hyphens.)
116 All subsequent non-empty lines
117 which begin with white space are part of the section;
118 comments within a section must begin with white space too.
119 There may be only one section of a given type with a given name.
122 Lines within the section are generally of the form
125 <I>parameter
</I><B>=
</B><I>value
</I>
128 (note the mandatory preceding white space).
129 There can be white space on either side of the
132 Parameter names follow the same syntax as section names,
133 and are specific to a section type.
134 Unless otherwise explicitly specified,
135 no parameter name may appear more than once in a section.
141 stands for the system default value (if any) of the parameter,
142 i.e. it is roughly equivalent to omitting the parameter line entirely.
146 may contain white space only if the entire
149 is enclosed in double quotes (
<B>"</B>);
153 cannot itself contain a double quote,
154 nor may it be continued across more than one line.
157 Numeric values are specified to be either an ``integer''
158 (a sequence of digits) or a ``decimal number''
159 (sequence of digits optionally followed by `.' and another sequence of digits).
162 There is currently one parameter which is available in any type of
168 the value is a section name;
169 the parameters of that section are appended to this section,
170 as if they had been written as part of it.
171 The specified section must exist, must follow the current one,
172 and must have the same section type.
173 (Nesting is permitted,
174 and there may be more than one
178 although it is forbidden to append the same section more than once.)
179 This allows, for example, keeping the encryption keys
180 for a connection in a separate file
181 from the rest of the description, by using both an
188 (Caution, see BUGS below for some restrictions.)
199 that flips the referenced section's entries left-for-right.
203 Parameter names beginning with
215 are reserved for user extensions and will never be assigned meanings
217 Parameters with such names must still observe the syntax rules
218 (limits on characters used in the name;
219 no white space in a non-quoted value;
220 no newlines or double quotes within the value).
221 All other as-yet-unused parameter names are reserved for future IPsec
228 specifies defaults for sections of the same type.
229 For each parameter in it,
230 any section of that type which does not have a parameter of the same name
231 gets a copy of the one from the
235 There may be multiple
238 sections of a given type,
239 but only one default may be supplied for any specific parameter name,
243 sections of a given type must precede all non-
<B>%default
</B>
245 sections of that type.
248 sections may not contain
257 Currently there are two types of section:
261 section specifies general configuration information for IPsec,
265 section specifies an IPsec connection.
266 <A NAME=
"lbAD"> </A>
267 <H2>CONN SECTIONS
</H2>
273 <I>connection specification
</I>,
275 defining a network connection to be made using IPsec.
276 The name given is arbitrary, and is used to identify the connection to
277 <I><A HREF=
"ipsec_auto.8.html">ipsec_auto
</A></I>(
8)
280 <I><A HREF=
"ipsec_manual.8.html">ipsec_manual
</A></I>(
8).
282 Here's a simple example:
290 leftsubnet=
10.0.1.0/
24
291 leftnexthop=
172.16.55.66
293 rightsubnet=
10.0.2.0/
24
294 rightnexthop=
172.16.88.99
300 A note on terminology...
301 In automatic keying, there are two kinds of communications going on:
302 transmission of user IP packets, and gateway-to-gateway negotiations for
303 keying, rekeying, and general control.
304 The data path (a set of ``IPsec SAs'') used for user packets is herein
305 referred to as the ``connection'';
306 the path used for negotiations (built with ``ISAKMP SAs'') is referred to as
307 the ``keying channel''.
310 To avoid trivial editing of the configuration file to suit it to each system
311 involved in a connection,
312 connection specifications are written in terms of
319 rather than in terms of local and remote.
320 Which participant is considered
327 IPsec figures out which one it is being run on based on internal information.
328 This permits using identical connection specifications on both ends.
329 There are cases where there is no symmetry; a good convention is to
333 for the local side and
336 for the remote side (the first letters are a good mnemonic).
339 Many of the parameters relate to one participant or the other;
343 are listed here, but every parameter whose name begins with
350 whose description is the same but with
359 Parameters are optional unless marked ``(required)'';
360 a parameter required for manual keying need not be included for
361 a connection which will use only automatic keying, and vice versa.
362 <A NAME=
"lbAE"> </A>
363 <H3>CONN PARAMETERS: GENERAL
</H3>
365 The following parameters are relevant to both automatic and manual keying.
366 Unless otherwise noted,
367 for a connection to work,
368 in general it is necessary for the two ends to agree exactly
369 on the values of these parameters.
374 the type of the connection; currently the accepted values
379 signifying a host-to-host, host-to-subnet, or subnet-to-subnet tunnel;
382 signifying host-to-host transport mode;
385 signifying that no IPsec processing should be done at all;
388 signifying that packets should be discarded; and
391 signifying that packets should be discarded and a diagnostic ICMP returned.
396 the IP address of the left participant's public-network interface,
397 in any form accepted by
398 <I><A HREF=
"ipsec_ttoaddr.3.html">ipsec_ttoaddr
</A></I>(
3)
400 or one of several magic values.
402 <B>%defaultroute
</B>,
413 specification contains
414 <B>%defaultroute,
</B>
418 will be filled in automatically with the local address
419 of the default-route interface (as determined at IPsec startup time);
420 this also overrides any value supplied for
430 <B>%defaultroute
</B>,
436 signifies an address to be filled in (by automatic keying) during
439 <B>%opportunistic
</B>
447 are to be filled in (by automatic keying) from DNS data for
455 <B>%opportunisticgroup
</B>
457 makes this a policy group conn: one that will be instantiated
458 into a regular or opportunistic conn for each CIDR block listed in the
459 policy group file with the same name as the conn.
460 <DT><B>leftsubnet
</B>
463 private subnet behind the left participant, expressed as
464 <I>network
</I><B>/
</B><I>netmask
</I>
465 (actually, any form acceptable to
466 <I><A HREF=
"ipsec_ttosubnet.3.html">ipsec_ttosubnet
</A></I>(
3));
468 if omitted, essentially assumed to be
<I>left
</I><B>/
32</B>,
469 signifying that the left end of the connection goes to the left participant only
470 <DT><B>leftnexthop
</B>
473 next-hop gateway IP address for the left participant's connection
474 to the public network;
481 If the value is to be overridden by the
482 <B>left=%defaultroute
</B>
485 an explicit value must
489 If that method is not being used,
494 <B>%defaultroute
</B>,
497 <B>interfaces=%defaultroute
</B>
505 the next-hop gateway address of the default-route interface
510 signifies a value to be filled in (by automatic keying)
511 with the peer's address.
512 Relevant only locally, other end need not agree on it.
513 <DT><B>leftupdown
</B>
516 what ``updown'' script to run to adjust routing and/or firewalling
517 when the status of the connection
519 <B>ipsec _updown
</B>).
521 May include positional parameters separated by white space
522 (although this requires enclosing the whole string in quotes);
523 including shell metacharacters is unwise.
525 <I><A HREF=
"ipsec_pluto.8.html">ipsec_pluto
</A></I>(
8)
528 Relevant only locally, other end need not agree on it.
529 <DT><B>leftfirewall
</B>
532 whether the left participant is doing forwarding-firewalling
533 (including masquerading) for traffic from
<I>leftsubnet
</I>,
534 which should be turned off (for traffic to the other subnet)
535 once the connection is established;
536 acceptable values are
542 May not be used in the same connection description with
545 Implemented as a parameter to the default
550 Relevant only locally, other end need not agree on it.
554 If one or both security gateways are doing forwarding firewalling
555 (possibly including masquerading),
556 and this is specified using the firewall parameters,
557 tunnels established with IPsec are exempted from it
558 so that packets can flow unchanged through the tunnels.
559 (This means that all subnets connected in this manner must have
560 distinct, non-overlapping subnet address blocks.)
561 This is done by the default
565 <I><A HREF=
"ipsec_pluto.8.html">ipsec_pluto
</A></I>(
8)).
569 The implementation of this makes certain assumptions about firewall setup,
570 notably the use of the old
573 interface to the firewall.
574 In situations calling for more control,
575 it may be preferable for the user to supply his own
579 which makes the appropriate adjustments for his system.
580 <A NAME=
"lbAF"> </A>
581 <H3>CONN PARAMETERS: AUTOMATIC KEYING
</H3>
583 The following parameters are relevant only to automatic keying,
584 and are ignored in manual keying.
585 Unless otherwise noted,
586 for a connection to work,
587 in general it is necessary for the two ends to agree exactly
588 on the values of these parameters.
590 <DT><B>keyexchange
</B>
593 method of key exchange;
594 the default and currently the only accepted value is
600 what operation, if any, should be done automatically at IPsec startup;
601 currently-accepted values are
611 (signifying that plus an
618 (signifying that plus an
635 (also the default) (signifying no automatic startup operation).
642 Relevant only locally, other end need not agree on it
643 (but in general, for an intended-to-be-permanent connection,
647 to ensure that any reboot causes immediate renegotiation).
651 whether authentication should be done as part of
652 ESP encryption, or separately using the AH protocol;
653 acceptable values are
662 how the two security gateways should authenticate each other;
663 acceptable values are
669 for RSA digital signatures (the default),
675 if negotiation is never to be attempted or accepted (useful for shunt-only conns).
676 Digital signatures are superior in every way to shared secrets.
682 should be identified for authentication;
686 Can be an IP address (in any
687 <I><A HREF=
"ipsec_ttoaddr.3.html">ipsec_ttoaddr
</A></I>(
3)
690 or a fully-qualified domain name preceded by
693 (which is used as a literal string and not resolved).
697 stands for the current setting of
<I>myid
</I>.
698 This is set in
<B>config setup
</B> or by
<I><A HREF=
"ipsec_whack.8.html">ipsec_whack
</A></I>(
8)), or, if not set,
699 it is the IP address in
<B>%defaultroute
</B> (if that is supported by a TXT record in its reverse domain), or otherwise
700 it is the system's hostname (if that is supported by a TXT record in its forward domain), or otherwise it is undefined.
701 <DT><B>leftrsasigkey
</B>
704 the left participant's
705 public key for RSA signature authentication,
706 in RFC
2537 format using
707 <I><A HREF=
"ipsec_ttodata.3.html">ipsec_ttodata
</A></I>(
3)
713 means the same as not specifying a value (useful to override a default).
718 means the key is to be fetched from DNS at the time it is needed.
722 means the key is to be fetched from DNS at the time
723 the connection description is read from
726 currently this will be treated as
733 <B>right=%opportunistic
</B>.
738 is currently treated as
745 The identity used for the left participant
746 must be a specific host, not
749 or another magic value.
752 if two connection descriptions
753 specify different public keys for the same
756 confusion and madness will ensue.
757 <DT><B>leftrsasigkey2
</B>
760 if present, a second public key.
761 Either key can authenticate the signature, allowing for key rollover.
765 whether Perfect Forward Secrecy of keys is desired on the connection's
767 (with PFS, penetration of the key-exchange protocol
768 does not compromise keys negotiated earlier);
769 acceptable values are
779 how long a particular instance of a connection
780 (a set of encryption/authentication keys for user packets) should last,
781 from successful negotiation to expiry;
782 acceptable values are an integer optionally followed by
786 or a decimal number followed by
795 in minutes, hours, or days respectively)
802 Normally, the connection is renegotiated (via the keying channel)
804 The two ends need not exactly agree on
807 although if they do not,
808 there will be some clutter of superseded connections on the end
809 which thinks the lifetime is longer.
813 whether a connection should be renegotiated when it is about to expire;
814 acceptable values are
821 The two ends need not agree,
825 prevents Pluto from requesting renegotiation,
826 it does not prevent responding to renegotiation requested from the other end,
830 will be largely ineffective unless both ends agree on it.
831 <DT><B>rekeymargin
</B>
834 how long before connection expiry or keying-channel expiry
836 negotiate a replacement
837 begin; acceptable values as for
843 Relevant only locally, other end need not agree on it.
847 maximum percentage by which
850 should be randomly increased to randomize rekeying intervals
851 (important for hosts with many connections);
852 acceptable values are an integer,
853 which may exceed
100,
856 <I><A HREF=
"ipsec_pluto.8.html">ipsec_pluto
</A></I>(
8),
864 after this random increase,
871 will suppress time randomization.
872 Relevant only locally, other end need not agree on it.
873 <DT><B>keyingtries
</B>
876 how many attempts (a whole number or
<B>%forever
</B>) should be made to
877 negotiate a connection, or a replacement for one, before giving up
881 The value
<B>%forever
</B>
882 means ``never give up'' (obsolete: this can be written
<B>0</B>).
883 Relevant only locally, other end need not agree on it.
884 <DT><B>ikelifetime
</B>
887 how long the keying channel of a connection (buzzphrase: ``ISAKMP SA'')
888 should last before being renegotiated;
889 acceptable values as for
893 <I><A HREF=
"ipsec_pluto.8.html">ipsec_pluto
</A></I>(
8),
901 The two-ends-disagree case is similar to that of
907 whether IPComp compression of content is proposed on the connection
908 (link-level compression does not work on encrypted data,
909 so to be effective, compression must be done
<I>before
</I> encryption);
910 acceptable values are
917 The two ends need not agree.
921 causes IPsec to propose both compressed and uncompressed,
922 and prefer compressed.
926 prevents IPsec from proposing compression;
927 a proposal to compress will still be accepted.
928 <DT><B>disablearrivalcheck
</B>
931 whether KLIPS's normal tunnel-exit check
932 (that a packet emerging from a tunnel has plausible addresses in its header)
934 acceptable values are
941 Tunnel-exit checks improve security and do not break any normal configuration.
942 Relevant only locally, other end need not agree on it.
943 <DT><B>failureshunt
</B>
946 what to do with packets when negotiation fails.
958 have the obvious meanings.
960 <A NAME=
"lbAG"> </A>
961 <H3>CONN PARAMETERS: MANUAL KEYING
</H3>
963 The following parameters are relevant only to manual keying,
964 and are ignored in automatic keying.
965 Unless otherwise noted,
966 for a connection to work,
967 in general it is necessary for the two ends to agree exactly
968 on the values of these parameters.
970 connection must specify at least one of AH or ESP.
978 required for manual keying)
979 the SPI number to be used for the connection (see
980 <I><A HREF=
"ipsec_manual.8.html">ipsec_manual
</A></I>(
8));
982 must be of the form
<B>0x
</B><I>hex
</I><B></B>,
986 is one or more hexadecimal digits
987 (note, it will generally be necessary to make
993 to be acceptable to KLIPS,
994 and use of SPIs in the range
995 <B>0x100</B>-
<B>0xfff</B>
1004 required for manual keying)
1005 the base number for the SPIs to be used for the connection (see
1006 <I><A HREF=
"ipsec_manual.8.html">ipsec_manual
</A></I>(
8));
1008 must be of the form
<B>0x
</B><I>hex
</I><B>0</B>,
1012 is one or more hexadecimal digits
1013 (note, it will generally be necessary to make
1019 for the resulting SPIs
1020 to be acceptable to KLIPS,
1021 and use of numbers in the range
1022 <B>0x100</B>-
<B>0xff0</B>
1028 ESP encryption/authentication algorithm to be used
1029 for the connection, e.g.
1032 (must be suitable as a value of
1033 <I><A HREF=
"ipsec_spi.8.html">ipsec_spi
</A></I>(
8)'s
1038 default is not to use ESP
1039 <DT><B>espenckey
</B>
1043 (must be suitable as a value of
1044 <I><A HREF=
"ipsec_spi.8.html">ipsec_spi
</A></I>(
8)'s
1049 (may be specified separately for each direction using
1050 <B>leftespenckey
</B>
1054 <B>rightespenckey
</B>
1057 <DT><B>espauthkey
</B>
1060 ESP authentication key
1061 (must be suitable as a value of
1062 <I><A HREF=
"ipsec_spi.8.html">ipsec_spi
</A></I>(
8)'s
1067 (may be specified separately for each direction using
1068 <B>leftespauthkey
</B>
1072 <B>rightespauthkey
</B>
1075 <DT><B>espreplay_window
</B>
1078 ESP replay-window setting,
1085 default, which turns off replay protection) to
1088 relevant only if ESP authentication is being used
1089 <DT><B>leftespspi
</B>
1092 SPI to be used for the leftward ESP SA, overriding
1093 automatic assignment using
1099 typically a hexadecimal number beginning with
1105 AH authentication algorithm to be used
1106 for the connection, e.g.
1109 (must be suitable as a value of
1110 <I><A HREF=
"ipsec_spi.8.html">ipsec_spi
</A></I>(
8)'s
1115 default is not to use AH
1122 is present) AH authentication key
1123 (must be suitable as a value of
1124 <I><A HREF=
"ipsec_spi.8.html">ipsec_spi
</A></I>(
8)'s
1129 (may be specified separately for each direction using
1137 <DT><B>ahreplay_window
</B>
1140 AH replay-window setting,
1147 default, which turns off replay protection) to
1150 <DT><B>leftahspi
</B>
1153 SPI to be used for the leftward AH SA, overriding
1154 automatic assignment using
1160 typically a hexadecimal number beginning with
1164 <A NAME=
"lbAH"> </A>
1165 <H2>CONFIG SECTIONS
</H2>
1167 At present, the only
1170 section known to the IPsec software is the one named
1173 which contains information used when the software is being started
1175 <I><A HREF=
"ipsec_setup.8.html">ipsec_setup
</A></I>(
8)).
1184 interfaces=
"ipsec0=eth1 ipsec1=ppp0
"
1192 Parameters are optional unless marked ``(required)''.
1193 The currently-accepted
1206 the identity to be used for
1211 is used in the implicit policy group conns and can be used as
1212 an identity in explicit conns.
1216 is set to the IP address in
<B>%defaultroute
</B> (if that is supported by a TXT record in its reverse domain), or otherwise
1217 the system's hostname (if that is supported by a TXT record in its forward domain), or otherwise it is undefined.
1218 An explicit value generally starts with ``
<B>@
</B>''.
1219 <DT><B>interfaces
</B>
1222 virtual and physical interfaces for IPsec to use:
1224 <I>virtual
</I><B>=
</B><I>physical
</I> pair, a (quoted!) list of pairs separated
1228 One of the pairs may be written as
1229 <B>%defaultroute
</B>,
1231 which means: find the interface
<I>d
</I> that the default route points to,
1232 and then act as if the value was ``
<B>ipsec0=
</B><I>d
</I>''.
1233 <B>%defaultroute
</B>
1238 must be used to denote no interfaces.
1240 <B>%defaultroute
</B>
1242 is used (implicitly or explicitly)
1243 information about the default route and its interface is noted for
1245 <I><A HREF=
"ipsec_manual.8.html">ipsec_manual
</A></I>(
8)
1248 <I><A HREF=
"ipsec_auto.8.html">ipsec_auto
</A></I>(
8).)
1250 <DT><B>forwardcontrol
</B>
1256 should turn IP forwarding on
1257 (if it's not already on) as IPsec is started,
1258 and turn it off again (if it was off) as IPsec is stopped;
1259 acceptable values are
1265 For this to have full effect, forwarding must be
1266 disabled before the hardware interfaces are brought
1268 <B>net.ipv4.ip_forward
=
0</B>
1271 <I>/etc/sysctl.conf
</I>),
1273 because IPsec doesn't get control early enough to do that.
1274 <DT><B>rp_filter
</B>
1280 should adjust the reverse path filtering mechanism for the
1281 physical devices to be used.
1282 Values are
<B>%unchanged
</B> (to leave it alone)
1283 or
<B>0</B>,
<B>1</B>,
<B>2</B> (values to set it to).
1284 <I>/proc/sys/net/ipv4/conf/PHYS/rp_filter
</I>
1285 is badly documented; it must be
<B>0</B> in many cases
1286 for ipsec to function.
1287 The default value for the parameter is
<B>0</B>.
1292 <I><A HREF=
"syslog.2.html">syslog
</A></I>(
2)
1294 ``facility'' name and priority to use for
1295 startup/shutdown log messages,
1297 <B>daemon.error
</B>.
1299 <DT><B>klipsdebug
</B>
1302 how much KLIPS debugging output should be logged.
1307 means no debugging output (the default).
1312 Otherwise only the specified types of output
1313 (a quoted list, names separated by white space) are enabled;
1314 for details on available debugging types, see
1315 <I><A HREF=
"ipsec_klipsdebug.8.html">ipsec_klipsdebug
</A></I>(
8).
1317 <DT><B>plutodebug
</B>
1320 how much Pluto debugging output should be logged.
1325 means no debugging output (the default).
1330 Otherwise only the specified types of output
1331 (a quoted list, names without the
1335 separated by white space) are enabled;
1336 for details on available debugging types, see
1337 <I><A HREF=
"ipsec_pluto.8.html">ipsec_pluto
</A></I>(
8).
1339 <DT><B>plutoopts
</B>
1342 additional options to pass to pluto upon startup. See
1343 <I><A HREF=
"ipsec_pluto.8.html">ipsec_pluto
</A></I>(
8).
1345 <DT><B>plutostderrlog
</B>
1348 do not use syslog, but rather log to stderr, and direct stderr to the
1353 in what directory should things started by
1356 (notably the Pluto daemon) be allowed to
1358 The empty value (the default) means they are not
1360 <DT><B>manualstart
</B>
1363 which manually-keyed connections to set up at startup
1364 (empty, a name, or a quoted list of names separated by white space);
1366 <I><A HREF=
"ipsec_manual.8.html">ipsec_manual
</A></I>(
8).
1372 whether to start Pluto or not;
1380 (useful only in special circumstances).
1381 <DT><B>plutowait
</B>
1384 should Pluto wait for each
1385 negotiation attempt that is part of startup to
1386 finish before proceeding with the next?
1397 shell command to run before starting Pluto
1398 (e.g., to decrypt an encrypted copy of the
1399 <I>ipsec.secrets
</I>
1402 It's run in a very simple way;
1403 complexities like I/O redirection are best hidden within a script.
1404 Any output is redirected for logging,
1405 so running interactive commands is difficult unless they use
1408 or equivalent for their interaction.
1410 <DT><B>postpluto
</B>
1413 shell command to run after starting Pluto
1414 (e.g., to remove a decrypted copy of the
1415 <I>ipsec.secrets
</I>
1418 It's run in a very simple way;
1419 complexities like I/O redirection are best hidden within a script.
1420 Any output is redirected for logging,
1421 so running interactive commands is difficult unless they use
1424 or equivalent for their interaction.
1429 whether a tunnel's need to fragment a packet should be reported
1430 back with an ICMP message,
1431 in an attempt to make the sender lower his PMTU estimate;
1432 acceptable values are
1442 whether a tunnel packet's TOS field should be set to
1445 rather than copied from the user packet inside;
1446 acceptable values are
1453 <DT><B>uniqueids
</B>
1456 whether a particular participant ID should be kept unique,
1457 with any new (automatically keyed)
1458 connection using an ID from a different IP address
1459 deemed to replace all old ones using that ID;
1460 acceptable values are
1467 Participant IDs normally
<I>are
</I> unique,
1468 so a new (automatically-keyed) connection using the same ID is
1469 almost invariably intended to replace an old one.
1470 <DT><B>overridemtu
</B>
1473 value that the MTU of the ipsec
<I>n
</I> interface(s) should be set to,
1474 overriding IPsec's (large) default.
1475 This parameter is needed only in special situations.
1477 <A NAME=
"lbAI"> </A>
1478 <H2>IMPLICIT CONNS
</H2>
1482 The system automatically defines several conns to implement
1483 default policy groups. Each can be overridden by explicitly
1484 defining a new conn with the same name. If the new conn has
<B>auto=ignore
</B>,
1485 the definition is suppressed.
1488 Here are the automatically supplied definitions.
1501 conn clear-or-private
1505 right=%opportunisticgroup
1506 failureshunt=passthrough
1513 conn private-or-clear
1517 right=%opportunisticgroup
1518 failureshunt=passthrough
1529 right=%opportunisticgroup
1550 right=%opportunistic
1551 failureshunt=passthrough
1561 These conns are
<I>not
</I> affected by anything in
<B>conn %default
</B>.
1562 They will only work if
<B>%defaultroute
</B> works.
1563 The
<B>leftid
</B> will be the interfaces IP address; this
1564 requires that reverse DNS records be set up properly.
1567 The implicit conns are defined after all others. It is
1568 appropriate and reasonable to use
<B>also=private-or-clear
</B>
1569 (for example) in any other opportunistic conn.
1570 <A NAME=
"lbAJ"> </A>
1571 <H2>POLICY GROUP FILES
</H2>
1575 The optional files under
1576 <I>/etc/ipsec.d/policy
</I>,
1581 /etc/ipsec.d/policies/clear
1582 /etc/ipsec.d/policies/clear-or-private
1583 /etc/ipsec.d/policies/private-or-clear
1584 /etc/ipsec.d/policies/private
1585 /etc/ipsec.d/policies/block
1589 may contain policy group configuration information to
1593 Their contents are not security-sensitive.
1596 These files are text files.
1597 Each consists of a list of CIDR blocks, one per line.
1598 White space followed by # followed by anything to the end of the line
1599 is a comment and is ignored, as are empty lines.
1603 <I>/etc/ipsec.conf
</I>
1609 <B>right=%opportunisticgroup
</B>
1611 is a policy group connection.
1612 When a policy group file of the same name is loaded, with
1615 <B>ipsec auto --rereadgroups
</B>
1618 or at system start, the connection is instantiated such that each
1619 CIDR block serves as an instance's
1622 value. The system treats the
1623 resulting instances as normal connections.
1626 For example, given a suitable connection definition
1630 <I>/etc/ipsec.d/policy/private
</I>
1632 with an entry
192.0.2.3,
1633 the system creates a connection instance
1634 <B>private#
192.0.2.3.
</B>
1636 This connection inherits all details from
1639 except that its right client is
192.0.2.3.
1640 <A NAME=
"lbAK"> </A>
1641 <H2>DEFAULT POLICY GROUPS
</H2>
1645 The standard FreeS/WAN install includes several policy groups
1646 which provide a way of classifying possible peers into IPsec security classes:
1649 (talk encrypted only),
1650 <B>private-or-clear
</B>
1652 (prefer encryption),
1653 <B>clear-or-private
</B>
1655 (respond to requests for encryption),
1661 Implicit policy groups apply to the local host only,
1662 and are implemented by the
1663 <B>IMPLICIT CONNECTIONS
</B>
1666 <A NAME=
"lbAL"> </A>
1667 <H2>CHOOSING A CONNECTION
</H2>
1671 When choosing a connection to apply to an outbound packet caught with a
1674 the system prefers the one with the most specific eroute that
1675 includes the packet's source and destination IP addresses.
1676 Source subnets are examined before destination subnets.
1677 For initiating, only routed connections are considered. For responding,
1678 unrouted but added connections are considered.
1681 When choosing a connection to use to respond to a negotiation which
1682 doesn't match an ordinary conn, an opportunistic connection
1683 may be instantiated. Eventually, its instance will be /
32 -
> /
32, but
1684 for earlier stages of the negotiation, there will not be enough
1685 information about the client subnets to complete the instantiation.
1686 <A NAME=
"lbAM"> </A>
1691 /etc/ipsec.d/policies/clear
1692 /etc/ipsec.d/policies/clear-or-private
1693 /etc/ipsec.d/policies/private-or-clear
1694 /etc/ipsec.d/policies/private
1695 /etc/ipsec.d/policies/block
1698 <A NAME=
"lbAN"> </A>
1701 <A HREF=
"ipsec.8.html">ipsec
</A>(
8),
<A HREF=
"ipsec_ttoaddr.8.html">ipsec_ttoaddr
</A>(
8),
<A HREF=
"ipsec_auto.8.html">ipsec_auto
</A>(
8),
<A HREF=
"ipsec_manual.8.html">ipsec_manual
</A>(
8),
<A HREF=
"ipsec_rsasigkey.8.html">ipsec_rsasigkey
</A>(
8)
1702 <A NAME=
"lbAO"> </A>
1705 Designed for the FreeS/WAN project
1706 <<A HREF=
"http://www.freeswan.org">http://www.freeswan.org
</A>>
1708 <A NAME=
"lbAP"> </A>
1725 FreeS/WAN blocks outbound packets using eroutes, but assumes inbound
1726 blocking is handled by the firewall. FreeS/WAN offers firewall hooks
1727 via an ``updown'' script. However, the default
1728 <B>ipsec _updown
</B>
1730 provides no help in controlling a modern firewall.
1733 Including attributes of the keying channel
1734 (authentication methods,
1738 as an attribute of a connection,
1739 rather than of a participant pair, is dubious and incurs limitations.
1744 is not nearly as generous about the syntax of subnets,
1745 addresses, etc. as the usual FreeS/WAN user interfaces.
1746 Four-component dotted-decimal must be used for all addresses.
1750 smart enough to translate bit-count netmasks to dotted-decimal form.
1753 It would be good to have a line-continuation syntax,
1754 especially for the very long lines involved in
1758 The ability to specify different identities,
1761 and public keys for different automatic-keyed connections
1762 between the same participants is misleading;
1763 this doesn't work dependably because the identity of the participants
1764 is not known early enough.
1765 This is especially awkward for the ``Road Warrior'' case,
1766 where the remote IP address is specified as
1769 and that is considered to be the ``participant'' for such connections.
1772 In principle it might be necessary to control MTU on an
1773 interface-by-interface basis,
1774 rather than with the single global override that
1780 A number of features which
<I>could
</I> be implemented in
1781 both manual and automatic keying
1782 actually are not yet implemented for manual keying.
1783 This is unlikely to be fixed any time soon.
1786 If conns are to be added before DNS is available,
1787 <B>left=
</B><I>FQDN
</I>,
1788 <B>leftnextop=
</B><I>FQDN
</I>,
1790 <B>leftrsasigkey=%dnsonload
</B>
1793 <I><A HREF=
"ipsec_pluto.8.html">ipsec_pluto
</A></I>(
8)
1795 does not actually use the public key for our side of a conn but it
1796 isn't generally known at a add-time which side is ours (Road Warrior
1797 and Opportunistic conns are currently exceptions).
1800 The
<B>myid
</B> option does not affect explicit
<B> ipsec auto --add
</B> or
<B>ipsec auto --replace
</B> commands for implicit conns.
1804 <A NAME=
"index"> </A><H2>Index
</H2>
1806 <DT><A HREF=
"#lbAB">NAME
</A><DD>
1807 <DT><A HREF=
"#lbAC">DESCRIPTION
</A><DD>
1808 <DT><A HREF=
"#lbAD">CONN SECTIONS
</A><DD>
1810 <DT><A HREF=
"#lbAE">CONN PARAMETERS: GENERAL
</A><DD>
1811 <DT><A HREF=
"#lbAF">CONN PARAMETERS: AUTOMATIC KEYING
</A><DD>
1812 <DT><A HREF=
"#lbAG">CONN PARAMETERS: MANUAL KEYING
</A><DD>
1814 <DT><A HREF=
"#lbAH">CONFIG SECTIONS
</A><DD>
1815 <DT><A HREF=
"#lbAI">IMPLICIT CONNS
</A><DD>
1816 <DT><A HREF=
"#lbAJ">POLICY GROUP FILES
</A><DD>
1817 <DT><A HREF=
"#lbAK">DEFAULT POLICY GROUPS
</A><DD>
1818 <DT><A HREF=
"#lbAL">CHOOSING A CONNECTION
</A><DD>
1819 <DT><A HREF=
"#lbAM">FILES
</A><DD>
1820 <DT><A HREF=
"#lbAN">SEE ALSO
</A><DD>
1821 <DT><A HREF=
"#lbAO">HISTORY
</A><DD>
1822 <DT><A HREF=
"#lbAP">BUGS
</A><DD>
1825 This document was created by
1826 <A HREF=
"http://localhost/cgi-bin/man/man2html">man2html
</A>,
1827 using the manual pages.
<BR>
1828 Time:
21:
40:
17 GMT, November
11,
2003
projects / thirdparty / strongswan.git / blob