1IPSEC_PLUTO(8) [FIXME: manual] IPSEC_PLUTO(8)
2
6 ipsec_pluto - ipsec whack : IPsec IKE keying daemon and control
7 interface
8
10 ipsec pluto [--help] [--version] [--optionsfrom filename] [--nofork]
11 [--stderrlog] [--use-auto] [--use-klips] [--use-netkey]
12 [--use-nostack] [--uniqueids] [--nat_traversal]
13 [--virtual_private network_list] [--keep_alive delay_sec]
14 [--force_keepalive] [--force_busy] [--disable_port_floating]
15 [--nocrsend] [--strictcrlpolicy] [--crlcheckinterval] [--ocspuri]
16 [--interface interfacename] [--listen ipaddr]
17 [--ikeport portnumber] [--ctlbase path]
18 [--secretsfile secrets-file] [--adns pathname]
19 [--nhelpers number] [--lwdnsq pathname] [--perpeerlog]
20 [--perpeerlogbase dirname] [--ipsecdir dirname]
21 [--coredir dirname] [--noretransmits]
22 ipsec whack [--help] [--version]
24 ipsec whack [--debug-none] [--debug-all] [--debug-raw] [--debug-crypt]
26 [--debug-parsing] [--debug-emitting] [--debug-control]
27 [--debug-lifecycle] [--debug-klips] [--debug-pfkey]
28 [--debug-nat-t] [--debug-dpd] [--debug-dns] [--debug-oppo]
29 [--debug-oppoinfo] [--debug-whackwatch] [--debug-private]
30 ipsec whack --name connection-name [[--ipv4] | [--ipv6]]
32 [[--tunnelipv4] | [--tunnelipv6]]
33 [--id identity] [--host ip-address] [--cert path]
35 [--ca distinguished name] [--groups access control groups]
36 [--sendcert yes | forced | always | ifasked | no | never]
37 [--certtype number] [--ikeport portnumber] [--nexthop ip-address]
38 [[--client subnet] | [--clientwithin subnet]]
39 [--clientprotoport protocol/port] [--srcip ip-address]
40 [--xauthserver] [--xauthclient] [--modecfgserver]
41 [--modecfgclient] [--modecfgdns1] [--modecfgdns2]
42 [--modecfgwins1] [--modecfgwins2] [--dnskeyondemand]
43 [--updown updown]
44 --to
46 [--id identity] [--host ip-address] [--cert path]
48 [--ca distinguished name] [--groups access control groups]
49 [--sendcert yes | always | ifasked | no | never]
50 [--certtype number] [--ikeport port-number]
51 [--nexthop ip-address] [--client subnet] [--clientwithin subnet]
52 [--clientprotoport protocol/port] [--srcip ip-address]
53 [--xauthserver] [--xauthclient] [--modecfgserver]
54 [--modecfgclient] [--modecfgdns1 ip-address]
55 [--modecfgdns2 ip-address] [--modecfgwins1 ip-address]
56 [--modecfgwins2 ip-address] [--dnskeyondemand] [--updown updown]
57 [--tunnel] [--psk] [--rsasig] [--encrypt] [--authenticate]
59 [--compress] [--pfs]
60 [--pfsgroup [modp1024] | [modp1536] | [modp2048] | [modp3072] | [modp4096] | [modp6144] | [modp8192]]
61 [--disablearrivalcheck] [--ikelifetime seconds]
62 [--ipseclifetime seconds] [--rekeymargin seconds]
63 [--rekeyfuzz percentage] [--keyingtries count] [--esp esp-algos]
64 [--dontrekey] [--aggrmode] [--modecfgpull] [[--dpddelay seconds]
65 | [--dpdtimeout seconds]]
66 [--dpdaction [clear] | [hold] | [restart]] [--forceencaps]
67 [[--initiateontraffic] | [--pass] | [--drop] | [--reject]]
68 [[--failnone] | [--failpass] | [--faildrop] | [--failreject]]
69 [--ctlbase path] [--optionsfrom filename] [--label string]
70 ipsec whack --keyid id [--addkey] [--pubkeyrsa key] [--ctlbase path]
72 [--optionsfrom filename] [--label string]
73 ipsec whack --myid id
75 ipsec whack --listen | --unlisten [--ctlbase path]
77 [--optionsfrom filename] [--label string]
78 ipsec whack --route | --unroute --name connection-name
80 [--ctlbase path] [--optionsfrom filename] [--label string]
81 ipsec whack --initiate | --terminate --name connection-name
83 [--xauthuser user] [--xauthpass pass] [--asynchronous]
84 [--ctlbase path] [--optionsfrom filename] [--label string]
85 ipsec whack [[--tunnelipv4] | [--tunnelipv6]] --oppohere ip-address
87 --oppothere ip-address
88 ipsec whack --crash [ipaddress]
90 ipsec whack --whackrecord [filename]
92 ipsec whack --whackstoprecord
94 ipsec whack --name connection-name --delete [--ctlbase path]
96 [--optionsfrom filename] [--label string]
97 ipsec whack --deletestate state-number [--ctlbase path]
99 [--optionsfrom filename] [--label string]
100 ipsec whack [--name connection-name] [--debug-none] [--debug-all]
102 [--debug-raw] [--debug-crypt] [--debug-parsing]
103 [--debug-emitting] [--debug-control] [--debug-controlmore]
104 [--debug-lifecycle] [--debug-klips] [--debug-pfkey] [--debug-dns]
105 [--debug-dpd] [--debug-natt] [--debug-oppo] [--debug-oppoinfo]
106 [--debug-whackwatch] [--debug-private]
107 [--impair-delay-adns-key-answer] [--impair-delay-adns-txt-answer]
108 [--impair-bust-mi2] [--impair-bust-mr2] [--impair-sa-fail]
109 [--impair-die-oninfo] [--impair-jacob-two-two]
110 ipsec whack [--utc] [--listall] [--listpubkeys] [--listcerts]
112 [--listcacerts] [--listacerts] [--listaacerts] [--listocspcerts]
113 [--listgroups] [--listcrls] [--listocsp]
114 ipsec whack [--utc] [--rereadsecrets] [--rereadall] [--rereadcacerts]
116 [--rereadacerts] [--rereadaacerts] [--rereadocspcerts]
117 [--rereadcrls]
118 ipsec whack --purgeocsp
120 ipsec whack --listevents
122 ipsec whack --status [--ctlbase path] [--optionsfrom filename]
124 [--label string]
125 ipsec whack --shutdown [--ctlbase path] [--optionsfrom filename]
127 [--label string]
128
130 pluto is an IKE (“IPsec Key Exchange”) daemon. whack is an auxiliary
131 program to allow requests to be made to a running pluto.
132 pluto is used to automatically build shared “security associations” on
134 a system that has IPsec, the secure IP protocol. In other words, pluto
135 can eliminate much of the work of manual keying. The actual secure
136 transmission of packets is the responsibility of other parts of the
137 system - the kernel. Pluto can talk to various kernel implementations,
138 such as KLIPS, such as NETKEY, and such as KAME IPsec stacks.
139 ipsec_auto(8) provides a more convenient interface to pluto and whack.
140 IKE´s Job
142 A Security Association (SA) is an agreement between two network nodes
143 on how to process certain traffic between them. This processing
144 involves encapsulation, authentication, encryption, or compression.
145 IKE can be deployed on a network node to negotiate Security
147 Associations for that node. These IKE implementations can only
148 negotiate with other IKE implementations, so IKE must be on each node
149 that is to be an endpoint of an IKE-negotiated Security Association. No
150 other nodes need to be running IKE.
151 An IKE instance (i.e. an IKE implementation on a particular network
153 node) communicates with another IKE instance using UDP IP packets, so
154 there must be a route between the nodes in each direction.
155 The negotiation of Security Associations requires a number of choices
157 that involve tradeoffs between security, convenience, trust, and
158 efficiency. These are policy issues and are normally specified to the
159 IKE instance by the system administrator.
160 IKE deals with two kinds of Security Associations. The first part of a
162 negotiation between IKE instances is to build an ISAKMP SA. An ISAKMP
163 SA is used to protect communication between the two IKEs. IPsec SAs can
164 then be built by the IKEs - these are used to carry protected IP
165 traffic between the systems.
166 The negotiation of the ISAKMP SA is known as Phase 1. In theory, Phase
168 1 can be accomplished by a couple of different exchange types.
169 Currently, Main Mode and Aggressive Mode are implemented.
170 Any negotiation under the protection of an ISAKMP SA, including the
172 negotiation of IPsec SAs, is part of Phase 2. The exchange type that we
173 use to negotiate an IPsec SA is called Quick Mode.
174 IKE instances must be able to authenticate each other as part of their
176 negotiation of an ISAKMP SA. This can be done by several mechanisms
177 described in the draft standards.
178 IKE negotiation can be initiated by any instance with any other. If
180 both can find an agreeable set of characteristics for a Security
181 Association, and both recognize each others authenticity, they can set
182 up a Security Association. The standards do not specify what causes an
183 IKE instance to initiate a negotiation.
184 In summary, an IKE instance is prepared to automate the management of
186 Security Associations in an IPsec environment, but a number of issues
187 are considered policy and are left in the system administrator´s hands.
188 Pluto
190 pluto is an implementation of IKE. It runs as a daemon on a network
191 node. Currently, this network node must be a LINUX system running the
192 KLIPS or NETKEY implementation of IPsec, or a FreeBSD/NetBSD/Mac OSX
193 system running the KAME implementation of IPsec.
194 pluto implements a large subset of IKE. This is enough for it to
196 interoperate with other instances of pluto, and many other IKE
197 implementations. It currently supports XAUTH, ModeConfig, X.509, Dead
198 Peer Detection, Opportunistic Encryption and all the NAT Traversal
199 standards.
200 The policy for acceptable characteristics for Security Associations is
202 mostly hardwired into the code of pluto (spdb.c). Eventually this will
203 be moved into a security policy database with reasonable expressive
204 power and more convenience.
205 pluto uses shared secrets or RSA signatures to authenticate peers with
207 whom it is negotiating. These RSA signatures can come from DNS(SEC), a
208 configuration file, or from X.509 and CA certificates.
209 pluto initiates negotiation of a Security Association when it is
211 manually prodded: the program whack is run to trigger this. It will
212 also initiate a negotiation when KLIPS traps an outbound packet for
213 Opportunistic Encryption.
214 pluto implements ISAKMP SAs itself. After it has negotiated the
216 characteristics of an IPsec SA, it directs the kernel to implement it.
217 If necessary, it also invokes a script to adjust any firewall and issue
218 route(8) commands to direct IP packets.
219 When pluto shuts down, it closes all Security Associations.
221 Before Running Pluto
223 pluto runs as a daemon with userid root. Before running it, a few
224 things must be set up.
225 pluto requires a working IPsec stack.
227 pluto supports multiple public networks (that is, networks that are
229 considered insecure and thus need to have their traffic encrypted or
230 authenticated). It discovers the public interfaces to use by looking at
231 all interfaces that are configured (the --interface option can be used
232 to limit the interfaces considered). It does this only when whack tells
233 it to --listen, so the interfaces must be configured by then. Each
234 interface with a name of the form ipsec[0-9] is taken as a KLIPS
235 virtual public interface. Another network interface with the same IP
236 address (the first one found will be used) is taken as the
237 corresponding real public interface. The --listen can be used to limit
238 listening on only 1 IP address of a certain interface. ifconfig(8) or
239 ip(8) with the -a flag will show the name and status of each network
240 interface.
241 pluto requires a database of preshared secrets and RSA private keys.
243 This is described in the ipsec.secrets(5). pluto is told of RSA public
244 keys via whack commands. If the connection is Opportunistic, and no RSA
245 public key is known, pluto will attempt to fetch RSA keys using the
246 Domain Name System.
247 Setting up KLIPS for pluto
249 The most basic network topology that pluto supports has two security
250 gateways negotiating on behalf of client subnets. The diagram of RGB´s
251 testbed is a good example (see klips/doc/rgb_setup.txt).
252 The file INSTALL in the base directory of this distribution explains
254 how to start setting up the whole system, including KLIPS.
255 Make sure that the security gateways have routes to each other. This is
257 usually covered by the default route, but may require issuing route(8)
258 commands. The route must go through a particular IP interface (we will
259 assume it is eth0, but it need not be). The interface that connects the
260 security gateway to its client must be a different one.
261 It is necessary to issue a ipsec_tncfg(8) command on each gateway. The
263 required command is:
264 ipsec tncfg --attach --virtual ipsec0 --physical eth0
266 A command to set up the ipsec0 virtual interface will also need to be
268 run. It will have the same parameters as the command used to set up the
269 physical interface to which it has just been connected using
270 ipsec_tncfg(8).
271 Setting up NETKEY for pluto
273 No special requirements are necessary to use NETKEY - it ships with all
274 modern versions of Linux 2.4 and 2.6. however, note that certain
275 vendors or older distributions use old versions or backports of NETKEY
276 which are broken. If possible use a NETKEY version that is at least
277 based on, or backported from Linux 2.6.11 or newer.
278 ipsec.secrets file
280 A pluto daemon and another IKE daemon (for example, another instance of
281 pluto) must convince each other that they are who they are supposed to
282 be before any negotiation can succeed. This authentication is
283 accomplished by using either secrets that have been shared beforehand
284 (manually) or by using RSA signatures. There are other techniques, but
285 they have not been implemented in pluto.
286 The file /etc/ipsec.secrets is used to keep preshared secret keys, RSA
288 private keys, X.509 encoded keyfiles and XAUTH passwords. Smartcards
289 are handled via NSS. For debugging, there is an argument to the pluto
290 command to use a different file. This file is described in
291 ipsec.secrets(5).
292 Running Pluto
294 To fire up the daemon, just type pluto (be sure to be running as the
295 superuser). The default IKE port number is 500, the UDP port assigned
296 by IANA for IKE Daemons. pluto must be run by the superuser to be able
297 to use the UDP 500 port. If pluto is told to enable NAT-Traversal, then
298 UDP port 4500 is also taken by pluto to listen on.
299 Pluto supports different IPstacks on different operating systems. The
301 option --use-auto, which is also the default, lets pluto find a stack
302 automatically. This behaviour can be changed by explicitly setting the
303 stack using --use-klips, --use-netkey or --use-nostack. The latter is
304 meant for testing only - no actual IPsec connections will be loaded
305 into the kernel.
306 Pluto supports the NAT-Traversal drafts and the final standard, RFC
308 3947, if the --nat_traversal is specified. The allowed range behind the
309 NAT routers is submitted using the --virtual_private option. See
310 ipsec.conf(5) for the syntax. The option --force_keepalive forces the
311 sending of the keep-alive packets, which are send to prevent the NAT
312 router from closing its port when there is not enough traffic on the
313 IPsec connection. The --keep_alive sets the delay (in seconds) of these
314 keep-alive packets. The newer NAT-T standards support port floating,
315 and Openswan enables this per default. It can be disabled using the
316 --disable_port_floating option.
317 Pluto supports the use of X.509 certificates and sends it certificate
319 when needed. This can confuse IKE implementations that do not implement
320 this, such as the old FreeS/WAN implementation. The --nocrsend prevents
321 pluto from sending these. At startup, pluto loads all the X.509 related
322 files from the directories /etc/ipsec.d/certs, /etc/ipsec.d/cacerts,
323 /etc/ipsec.d/aacerts, /etc/ipsec.d/ocspcerts, /etc/ipsec.d/private and
324 /etc/ipsec.d/crls. The Certificate Revocation Lists can also be
325 retrieved from an URL. The option --crlcheckinterval sets the time
326 between checking for CRL expiration and issuing new fetch commands. The
327 first attempt to update a CRL is started at 2*crlcheckinterval before
328 the next update time. Pluto logs a warning if no valid CRL was loaded
329 or obtained for a connection. If --strictcrlpolicy is given, the
330 connection will be rejected until a valid CRL has been loaded. Pluto
331 also has support for the Online Certificate Store Protocol (OSCP) as
332 defined in RFC 2560. The URL to the OSCP store can be given to pluto
333 via the --ocspuri option.
334 Pluto can use the BIND9 secure resolver, which means it has support for
336 DNSSEC, using the BIND9 lwres {} interface, see named.conf(5). Pluto
337 can also use the old adns interface if there is no BIND9 running with
338 lwres {} on the host, but then pluto cannot do any DNSSEC processing.
339 Pluto forks and starts these DNS helpers in separate children. The
340 options --lwdnsq and --adns invoke these resolvers.
341 Pluto can also use helper children to off-load cryptographic
343 operations. This behavior can be fine tuned using the --nhelpers. Pluto
344 will start (n-1) of them, where n is the number of CPU’s you have
345 (including hypherthreaded CPU’s). A value of 0 forces pluto to do all
346 operations in the main process. A value of -1 tells pluto to perform
347 the above calculation. Any other value forces the number to that
348 amount.
349 pluto attempts to create a lockfile with the name
351 /var/run/pluto/pluto.pid. If the lockfile cannot be created, pluto
352 exits - this prevents multiple plutos from competing Any “leftover”
353 lockfile must be removed before pluto will run. pluto writes its pid
354 into this file so that scripts can find it. This lock will not function
355 properly if it is on an NFS volume (but sharing locks on multiple
356 machines doesn´t make sense anyway).
357 pluto then forks and the parent exits. This is the conventional “daemon
359 fork”. It can make debugging awkward, so there is an option to suppress
360 this fork. In certain configurations, pluto might also launch helper
361 programs to assist with DNS queries or to offload cryptographic
362 operations.
363 All logging, including diagnostics, is sent to syslog(3) with
365 facility=authpriv; it decides where to put these messages (possibly in
366 /var/log/secure). Since this too can make debugging awkward, the option
367 --stderrlog is used to steer logging to stderr.
368 If the --perpeerlog option is given, then pluto will open a log file
370 per connection. By default, this is in /var/log/pluto/peer, in a
371 subdirectory formed by turning all dot (.) [IPv4} or colon (:) [IPv6]
372 into slashes (/).
373 The base directory can be changed with the --perpeerlogbase.
375 Once pluto is started, it waits for requests from whack.
377 Pluto´s Internal State
379 To understand how to use pluto, it is helpful to understand a little
380 about its internal state. Furthermore, the terminology is needed to
381 decipher some of the diagnostic messages.
382 Pluto supports food groups, and X.509 certificates. These are located
384 in /etc/ipsec.d, or another directory as specified by --ipsecdir.
385 Pluto may core dump. It will normally do so into the current working
387 directory. The standard scripts have an option dumpdir=, which can set
388 the current directory to determine where the core dump will go. In some
389 cases, it may be more convenient to specify it on the command line
390 using --coredir. A third method is to set the environment variable
391 PLUTO_CORE_DIR. The command line argument takes precedence over the
392 environment variable. The option plutorestartoncrash can be set to no
393 to prevent multiple core files and a looping pluto process. Normally,
394 when pluto crashes, another pluto process is started.
395 At times it may be desireable to turn off all timed events in pluto,
397 this can be done with --noretransmits.
398 The (potential) connection database describes attributes of a
400 connection. These include the IP addresses of the hosts and client
401 subnets and the security characteristics desired. pluto requires this
402 information (simply called a connection) before it can respond to a
403 request to build an SA. Each connection is given a name when it is
404 created, and all references are made using this name.
405 During the IKE exchange to build an SA, the information about the
407 negotiation is represented in a state object. Each state object
408 reflects how far the negotiation has reached. Once the negotiation is
409 complete and the SA established, the state object remains to represent
410 the SA. When the SA is terminated, the state object is discarded. Each
411 State object is given a serial number and this is used to refer to the
412 state objects in logged messages.
413 Each state object corresponds to a connection and can be thought of as
415 an instantiation of that connection. At any particular time, there may
416 be any number of state objects corresponding to a particular
417 connection. Often there is one representing an ISAKMP SA and another
418 representing an IPsec SA.
419 KLIPS hooks into the routing code in a LINUX kernel. Traffic to be
421 processed by an IPsec SA must be directed through KLIPS by routing
422 commands. Furthermore, the processing to be done is specified by ipsec
423 eroute(8) commands. pluto takes the responsibility of managing both of
424 these special kinds of routes.
425 NETKEY requires no special routing.
427 Each connection may be routed, and must be while it has an IPsec SA.
429 The connection specifies the characteristics of the route: the
430 interface on this machine, the “gateway” (the nexthop), and the peer´s
431 client subnet. Two connections may not be simultaneously routed if they
432 are for the same peer´s client subnet but use different interfaces or
433 gateways (pluto´s logic does not reflect any advanced routing
434 capabilities).
435 On KLIPS, each eroute is associated with the state object for an IPsec
437 SA because it has the particular characteristics of the SA. Two eroutes
438 conflict if they specify the identical local and remote clients (unlike
439 for routes, the local clients are taken into account).
440 When pluto needs to install a route for a connection, it must make sure
442 that no conflicting route is in use. If another connection has a
443 conflicting route, that route will be taken down, as long as there is
444 no IPsec SA instantiating that connection. If there is such an IPsec
445 SA, the attempt to install a route will fail.
446 There is an exception. If pluto, as Responder, needs to install a route
448 to a fixed client subnet for a connection, and there is already a
449 conflicting route, then the SAs using the route are deleted to make
450 room for the new SAs. The rationale is that the new connection is
451 probably more current. The need for this usually is a product of Road
452 Warrior connections (these are explained later; they cannot be used to
453 initiate).
454 When pluto needs to install an eroute for an IPsec SA (for a state
456 object), first the state object´s connection must be routed (if this
457 cannot be done, the eroute and SA will not be installed). If a
458 conflicting eroute is already in place for another connection, the
459 eroute and SA will not be installed (but note that the routing
460 exception mentioned above may have already deleted potentially
461 conflicting SAs). If another IPsec SA for the same connection already
462 has an eroute, all its outgoing traffic is taken over by the new
463 eroute. The incoming traffic will still be processed. This
464 characteristic is exploited during rekeying.
465 All of these routing characteristics are expected change when KLIPS and
467 NETKEY merge into a single new stack.
468 Using Whack
470 whack is used to command a running pluto. whack uses a UNIX domain
471 socket to speak to pluto (by default, /var/pluto.ctl).
472 whack has an intricate argument syntax. This syntax allows many
474 different functions to be specified. The help form shows the usage or
475 version information. The connection form gives pluto a description of a
476 potential connection. The public key form informs pluto of the RSA
477 public key for a potential peer. The delete form deletes a connection
478 description and all SAs corresponding to it. The listen form tells
479 pluto to start or stop listening on the public interfaces for IKE
480 requests from peers. The route form tells pluto to set up routing for a
481 connection; the unroute form undoes this. The initiate form tells pluto
482 to negotiate an SA corresponding to a connection. The terminate form
483 tells pluto to remove all SAs corresponding to a connection, including
484 those being negotiated. The status form displays the pluto´s internal
485 state. The debug form tells pluto to change the selection of debugging
486 output “on the fly”. The shutdown form tells pluto to shut down,
487 deleting all SAs.
488 The crash option asks pluto to consider a particularly target IP to
490 have crashed, and to attempt to restart all connections with that IP
491 address as a gateway. In general, you should use Dead Peer Detection to
492 detect this kind of situation automatically, but this is not always
493 possible.
494 Most options are specific to one of the forms, and will be described
496 with that form. There are three options that apply to all forms.
497 --ctlbase path
499 path.ctl is used as the UNIX domain socket for talking to pluto.
500 This option facilitates debugging.
501 --optionsfrom filename
503 adds the contents of the file to the argument list.
504 --label string
506 adds the string to all error messages generated by whack.
507 The help form of whack is self-explanatory.
509 --help
511 display the usage message.
512 --version
514 display the version of whack.
515 The connection form describes a potential connection to pluto. pluto
517 needs to know what connections can and should be negotiated. When pluto
518 is the initiator, it needs to know what to propose. When pluto is the
519 responder, it needs to know enough to decide whether is is willing to
520 set up the proposed connection.
521 The description of a potential connection can specify a large number of
523 details. Each connection has a unique name. This name will appear in a
524 updown shell command, so it should not contain punctuation that would
525 make the command ill-formed.
526 --name connection-name
528 sets the name of the connection
529 The topology of a connection is symmetric, so to save space here is
531 half a picture:
532 client_subnet<-->host:ikeport<-->nexthop<---
534 A similar trick is used in the flags. The same flag names are used for
536 both ends. Those before the --to flag describe the left side and those
537 afterwards describe the right side. When pluto attempts to use the
538 connection, it decides whether it is the left side or the right side of
539 the connection, based on the IP numbers of its interfaces.
540 --id id
542 the identity of the end. Currently, this can be an IP address
543 (specified as dotted quad or as a Fully Qualified Domain Name,
544 which will be resolved immediately) or as a Fully Qualified Domain
545 Name itself (prefixed by “@” to signify that it should not be
546 resolved), or as user@FQDN, or an X.509 DN, or as the magic value
547 %myid. Pluto only authenticates the identity, and does not use it
548 for addressing, so, for example, an IP address need not be the one
549 to which packets are to be sent. If the option is absent, the
550 identity defaults to the IP address specified by --host. %myid
551 allows the identity to be separately specified (by the pluto or
552 whack option --myid or by the ipsec.conf(5) config setup parameter
553 myid). Otherwise, pluto tries to guess what %myid should stand for:
554 the IP address of %defaultroute, if it is supported by a suitable
555 TXT record in the reverse domain for that IP address, or the
556 system´s hostname, if it is supported by a suitable TXT record in
557 its forward domain.
558 --host ip-address, --host %any, --host %opportunistic
560 the IP address of the end (generally the public interface). If
561 pluto is to act as a responder for IKE negotiations initiated from
562 unknown IP addresses (the “Road Warrior” case), the IP address
563 should be specified as %any (currently, the obsolete notation
564 0.0.0.0 is also accepted for this). If pluto is to
565 opportunistically initiate the connection, use %opportunistic
566 --cert filename
568 The filename of the X.509 certificate. This must be the public key
569 certificate only, and cannot be the PKCS#12 certificate file. See
570 ipsec.conf(5) on how to extrac this from the PKCS#12 file.
571 --ca distinguished name
573 the X.509 Certificate Authority´s Distinguished Name (DN) used as
574 trust anchor for this connection. This is the CA certificate that
575 signed the host certificate, as well as the certificate of the
576 incoming client.
577 --groups access control groups
579 the access control groups used.
580 --sendcert yes|forced|always|ifasked|no|never
582 Wether or not to send our X.509 certificate credentials. This could
583 potentially give an attacker too much information about which
584 identities are allowed to connect to this host. The default is to
585 use ifasked when we are a Responder, and to use yes (which is the
586 same as forced and always if we are an Initiator. The values no and
587 never are equivalent. NOTE: "forced" does not seem to be actually
588 implemented - do not use it.
589 --certtype number
591 The X.509 certificate type number.
592 --ikeport port-number
594 the UDP port that IKE listens to on that host. The default is 500.
595 (pluto on this machine uses the port specified by its own command
596 line argument, so this only affects where pluto sends messages.)
597 --nexthop ip-address
599 where to route packets for the peer´s client (presumably for the
600 peer too, but it will not be used for this). When pluto installs an
601 IPsec SA, it issues a route command. It uses the nexthop as the
602 gateway. The default is the peer´s IP address (this can be
603 explicitly written as %direct; the obsolete notation 0.0.0.0 is
604 accepted). This option is necessary if pluto´s host´s interface
605 used for sending packets to the peer is neither point-to-point nor
606 directly connected to the peer.
607 --client subnet
609 the subnet for which the IPsec traffic will be destined. If not
610 specified, the host will be the client. The subnet can be specified
611 in any of the forms supported by ipsec_atosubnet(3). The general
612 form is address/mask. The address can be either a domain name or
613 four decimal numbers (specifying octets) separated by dots. The
614 most convenient form of the mask is a decimal integer, specifying
615 the number of leading one bits in the mask. So, for example,
616 10.0.0.0/8 would specify the class A network “Net 10”.
617 --clientwithin subnet
619 This option is obsolete and will be removed. Do not use this option
620 anymore.
621 --clientprotoport protocol/port
623 specify the Port Selectors (filters) to be used on this connection.
624 The general form is protocol/port. This is most commonly used to
625 limit the connection to L2TP traffic only by specifying a value of
626 17/1701 for UDP (protocol 17) and port 1701. The notation 17/%any
627 can be used to allow all UDP traffic and is needed for L2TP
628 connections with Windows XP machines before Service Pack 2.
629 --srcip ip-address
631 the IP address for this host to use when transmitting a packet to
632 the remote IPsec gateway itself. This option is used to make the
633 gateway itself use its internal IP, which is part of the --client
634 subnet. Otherwise it will use its nearest IP address, which is its
635 public IP address, which is not part of the subnet-subnet IPsec
636 tunnel, and would therefor not get encrypted.
637 --xauthserver
639 this end is an xauthserver. It will lookup the xauth user name and
640 password and verify this before allowing the connection to get
641 established.
642 --xauthclient
644 this end is an xauthclient. To bring this connection up with the
645 --initiate also requires the client to specify --xauthuser username
646 and --xauthpass password
647 --xauthuser
649 The username for the xauth authentication.This option is normally
650 passed along by ipsec_auto(8) when an xauth connection is started
651 using ipsec auto --up conn
652 --xauthpass
654 The password for the xauth authentication. This option is normally
655 passed along by ipsec_auto(8) when an xauth connection is started
656 using ipsec auto --up conn
657 --modecfgserver
659 this end is an Mode Config server
660 --modecfgclient
662 this end is an Mode Config client
663 --modecfgdns1
665 The IP address of the first DNS server to pass along to the
666 ModeConfig Client
667 --modecfgdns2
669 The IP address of the second DNS server to pass along to the
670 ModeConfig Client
671 --modecfgwins1
673 The IP address of the first WINS server to pass along to the
674 ModeConfig Client
675 --modecfgwins2
677 The IP address of the second WINS server to pass along to the
678 ModeConfig Client
679 --dnskeyondemand
681 specifies that when an RSA public key is needed to authenticate
682 this host, and it isn´t already known, fetch it from DNS.
683 --updown updown
685 specifies an external shell command to be run whenever pluto brings
686 up or down a connection. The script is used to build a shell
687 command, so it may contain positional parameters, but ought not to
688 have punctuation that would cause the resulting command to be
689 ill-formed. The default is ipsec _updown. Pluto passes a dozen
690 environment variables to the script about the connection involved.
691 --to
693 separates the specification of the left and right ends of the
694 connection. Pluto tries to decide wether it is left or right based
695 on the information provided on both sides of this option.
696 The potential connection description also specifies characteristics of
698 rekeying and security.
699 --psk
701 Propose and allow preshared secret authentication for IKE peers.
702 This authentication requires that each side use the same secret.
703 May be combined with --rsasig; at least one must be specified.
704 --rsasig
706 Propose and allow RSA signatures for authentication of IKE peers.
707 This authentication requires that each side have have a private key
708 of its own and know the public key of its peer. May be combined
709 with --psk; at least one must be specified.
710 --encrypt
712 All proposed or accepted IPsec SAs will include non-null ESP. The
713 actual choices of transforms are wired into pluto.
714 --authenticate
716 All proposed IPsec SAs will include AH. All accepted IPsec SAs will
717 include AH or ESP with authentication. The actual choices of
718 transforms are wired into pluto. Note that this has nothing to do
719 with IKE authentication.
720 --compress
722 All proposed IPsec SAs will include IPCOMP (compression). This will
723 be ignored if KLIPS is not configured with IPCOMP support.
724 --tunnel
726 the IPsec SA should use tunneling. Implicit if the SA is for
727 clients. Must only be used with --authenticate or --encrypt.
728 --ipv4
730 The host addresses will be interpreted as IPv4 addresses. This is
731 the default. Note that for a connection, all host addresses must be
732 of the same Address Family (IPv4 and IPv6 use different Address
733 Families).
734 --ipv6
736 The host addresses (including nexthop) will be interpreted as IPv6
737 addresses. Note that for a connection, all host addresses must be
738 of the same Address Family (IPv4 and IPv6 use different Address
739 Families).
740 --tunnelipv4
742 The client addresses will be interpreted as IPv4 addresses. The
743 default is to match what the host will be. This does not imply
744 --tunnel so the flag can be safely used when no tunnel is actually
745 specified. Note that for a connection, all tunnel addresses must be
746 of the same Address Family.
747 --tunnelipv6
749 The client addresses will be interpreted as IPv6 addresses. The
750 default is to match what the host will be. This does not imply
751 --tunnel so the flag can be safely used when no tunnel is actually
752 specified. Note that for a connection, all tunnel addresses must be
753 of the same Address Family.
754 --pfs
756 There should be Perfect Forward Secrecy - new keying material will
757 be generated for each IPsec SA rather than being derived from the
758 ISAKMP SA keying material. Since the group to be used cannot be
759 negotiated (a dubious feature of the standard), pluto will propose
760 the same group that was used during Phase 1. We don´t implement a
761 stronger form of PFS which would require that the ISAKMP SA be
762 deleted after the IPSEC SA is negotiated.
763 --pfsgroup modp-group
765 Sets the Diffie-Hellman group used. Currently the following values
766 are supported: modp1024 (DHgroup 2), modp1536 (DHgroup 5), modp2048
767 (DHgroup 14), modp3072 (DHgroup 15), modp4096 (DHgroup 16),
768 modp6144 (DHgroup 17), and modp8192 (DHgroup 18). It is possible to
769 support the weak and broken modp768 (DHgroup 1), but this requires
770 a manual recompile and is strongly discouraged.
771 --disablearrivalcheck
773 If the connection is a tunnel, allow packets arriving through the
774 tunnel to have any source and destination addresses.
775 --esp esp-algos
777 ESP encryption/authentication algorithm to be used for the
778 connection (phase2 aka IPsec SA). The options must be suitable as a
779 value of ipsec_spi(8). See ipsec.conf(5) for a detailed description
780 of the algorithm format.
781 --aggrmode
783 This tunnel is using aggressive mode ISAKMP negotiation. The
784 default is main mode. Aggressive mode is less secure than main mode
785 as it reveals your identity to an eavesdropper, but is needed to
786 support road warriors using PSK keys or to interoperate with other
787 buggy implementations insisting on using aggressive mode.
788 --modecfgpull
790 Pull the Mode Config network information from the peer.
791 --dpddelay seconds
793 Set the delay (in seconds) between Dead Peer Dectection (RFC 3706)
794 keepalives (R_U_THERE, R_U_THERE_ACK) that are sent for this
795 connection (default 30 seconds).
796 --timeout seconds
798 Set the length of time (in seconds) we will idle without hearing
799 either an R_U_THERE poll from our peer, or an R_U_THERE_ACK reply.
800 After this period has elapsed with no response and no traffic, we
801 will declare the peer dead, and remove the SA (default 120
802 seconds).
803 --dpdaction action
805 When a DPD enabled peer is declared dead, what action should be
806 taken. hold(default) means the eroute will be put into %hold
807 status, while clearmeans the eroute and SA with both be cleared.
808 Clear is really only useful on the server of a Road Warrior config.
809 The action restart is used on tunnels that need to be permanently
810 up, and have static IP addresses.
811 --forceencaps
813 In some cases, for example when ESP packets are filtered or when a
814 broken IPsec peer does not properly recognise NAT, it can be useful
815 to force RFC-3948 encapsulation using this option. It causes pluto
816 lie and tell the remote peer that RFC-3948 encapsulation (ESP in
817 UDP port 4500 packets) is required. For this option to have any
818 effect, pluto must have been started with the --nat_traversal
819 option.
820 If none of the --encrypt, --authenticate, --compress, or --pfs flags is
822 given, the initiating the connection will only build an ISAKMP SA. For
823 such a connection, client subnets have no meaning and must not be
824 specified.
825 Apart from initiating directly using the --initiate option, a tunnel
827 can be loaded with a different policy
828 --initiateontraffic
830 Only initiate the connection when we have traffic to send over the
831 connection
832 --pass
834 Allow unencrypted traffic to flow until the tunnel is initiated.
835 --drop
837 Drop unencrypted traffic silently.
838 --reject
840 Drop unencrypted traffic silently, but send an ICMP message
841 notifying the other end.
842 These options need to be documented
844 --failnone
846 to be documented
847 --failpass
849 to be documented
850 --faildrop
852 to be documented
853 --failreject
855 to be documented
856 pluto supports various X.509 Certificate related options.
858 --utc
860 display all times in UTC.
861 --listall
863 lists all of the X.509 information known to pluto.
864 --listpubkeys
866 list all the public keys that have been successfully loaded.
867 --listcerts
869 list all the X.509 certificates that are currently loaded.
870 --listcacerts
872 list all the X.509 Certificate Authority (CA) certificates that are
873 currently loaded.
874 --listacerts
876 list all the X.509 Attribute certificates that are currently loaded
877 --listaacerts
879 --ocspcerts
881 list all of the X.509 certificates obtained via the Online
882 Certificate Store Protocol (OCSP)
883 --listgroups
885 --listcrls
887 list all the loaded Certificate Revocation Lists (CRLs)
888 The corresponding options --rereadsecrets, --rereadall,
890 --rereadcacerts, --rereadacerts, --rereadaacerts, --rereadocspcerts
891 --rereadcrls, and --purgeocsp, options reread this information from
892 their respective sources, and purge all the online obtained
893 information. The option --listevents lists all pending CRL fetch
894 commands.
895 More work is needed to allow for flexible policies. Currently policy is
897 hardwired in the source file spdb.c. The ISAKMP SAs may use Oakley
898 groups MODP1024 and MODP1536; AES or 3DES encryption; SHA1-96 and
899 MD5-96 authentication. The IPsec SAs may use AES or 3DES and MD5-96 or
900 SHA1-96 for ESP, or just MD5-96 or SHA1-96 for AH. IPCOMP Compression
901 is always Deflate.
902 --ikelifetime seconds
904 how long pluto will propose that an ISAKMP SA be allowed to live.
905 The default is 3600 (one hour) and the maximum is 86400 (1 day).
906 This option will not affect what is accepted. pluto will reject
907 proposals that exceed the maximum.
908 --ipseclifetime seconds
910 how long pluto will propose that an IPsec SA be allowed to live.
911 The default is 28800 (eight hours) and the maximum is 86400 (one
912 day). This option will not affect what is accepted. pluto will
913 reject proposals that exceed the maximum.
914 --rekeymargin seconds
916 how long before an SA´s expiration should pluto try to negotiate a
917 replacement SA. This will only happen if pluto was the initiator.
918 The default is 540 (nine minutes).
919 --rekeyfuzz percentage
921 maximum size of random component to add to rekeymargin, expressed
922 as a percentage of rekeymargin. pluto will select a delay
923 uniformly distributed within this range. By default, the percentage
924 will be 100. If greater determinism is desired, specify 0. It may
925 be appropriate for the percentage to be much larger than 100.
926 --keyingtries count
928 how many times pluto should try to negotiate an SA, either for the
929 first time or for rekeying. A value of 0 is interpreted as a very
930 large number: never give up. The default is three.
931 --dontrekey
933 A misnomer. Only rekey a connection if we were the Initiator and
934 there was recent traffic on the existing connection. This applies
935 to Phase 1 and Phase 2. This is currently the only automatic way
936 for a connection to terminate. It may be useful with Road Warrior
937 or Opportunistic connections. Since SA lifetime negotiation is
938 take-it-or-leave it, a Responder normally uses the shorter of the
939 negotiated or the configured lifetime. This only works because if
940 the lifetime is shorter than negotiated, the Responder will rekey
941 in time so that everything works. This interacts badly with
942 --dontrekey. In this case, the Responder will end up rekeying to
943 rectify a shortfall in an IPsec SA lifetime; for an ISAKMP SA, the
944 Responder will accept the negotiated lifetime.
945 --delete
947 when used in the connection form, it causes any previous connection
948 with this name to be deleted before this one is added. Unlike a
949 normal delete, no diagnostic is produced if there was no previous
950 connection to delete. Any routing in place for the connection is
951 undone.
952 --delete, --name connection-name
954 The delete form deletes a named connection description and any SAs
955 established or negotiations initiated using this connection. Any
956 routing in place for the connection is undone.
957 --deletestate state-number
959 The deletestate form deletes the state object with the specified
960 serial number. This is useful for selectively deleting instances of
961 connections.
962 The route form of the whack command tells pluto to set up routing for a
964 connection. Although like a traditional route, it uses an ipsec device
965 as a virtual interface. Once routing is set up, no packets will be sent
966 “in the clear” to the peer´s client specified in the connection. A TRAP
967 shunt eroute will be installed; if outbound traffic is caught, Pluto
968 will initiate the connection. An explicit whack route is not always
969 needed: if it hasn´t been done when an IPsec SA is being installed, one
970 will be automatically attempted.
971 --route, --name connection-name
973 When a routing is attempted for a connection, there must not
974 already be a routing for a different connection with the same
975 subnet but different interface or destination, or if there is, it
976 must not be being used by an IPsec SA. Otherwise the attempt will
977 fail.
978 --unroute, --name connection-name
980 The unroute form of the whack command tells pluto to undo a
981 routing. pluto will refuse if an IPsec SA is using the connection.
982 If another connection is sharing the same routing, it will be left
983 in place. Without a routing, packets will be sent without
984 encryption or authentication.
985 The initiate form tells pluto to initiate a negotiation with another
987 pluto (or other IKE daemon) according to the named connection.
988 Initiation requires a route that --route would provide; if none is in
989 place at the time an IPsec SA is being installed, pluto attempts to set
990 one up.
991 --initiate, --name connection-name, --asynchronous
993 The initiate form of the whack command will relay back from pluto
994 status information via the UNIX domain socket (unless
995 --asynchronous is specified). The status information is meant to
996 look a bit like that from FTP. Currently whack simply copies this
997 to stderr. When the request is finished (eg. the SAs are
998 established or pluto gives up), pluto closes the channel, causing
999 whack to terminate.
1000 The opportunistic initiate form is mainly used for debugging.
1002 --tunnelipv4, --tunnelipv6, --oppohere ip-address,
1004 --oppothere ip-address
1005 This will cause pluto to attempt to opportunistically initiate a
1006 connection from here to the there, even if a previous attempt had
1007 been made. The whack log will show the progress of this attempt.
1008 Ending an connection
1010 --terminate, --name connection-name
1012 the terminate form tells pluto to delete any sas that use the
1013 specified connection and to stop any negotiations in process. it
1014 does not prevent new negotiations from starting (the delete form
1015 has this effect).
1016 --crash ip-address
1018 If the remote peer has crashed, and therefor did not notify us, we
1019 keep sending encrypted traffic, and rejecting all plaintext
1020 (non-IKE) traffic from that remote peer. The --crash brings our end
1021 down as well for all the known connections to the specified
1022 ip-address
1023 --whackrecordfilename, --whackstoprecord
1025 this causes plutoto open the given filename for write, and record
1026 each of the messages received from whack or addconn. This continues
1027 until the whackstoprecord option is used. This option may not be
1028 combined with any other command. The start/stop commands are not
1029 recorded themselves. These files are usually used to create input
1030 files for unit tests, particularly for complex setups where
1031 policies may in fact overlap.
1032 The format of the file consists of a line starting with
1034 #!pluto-whack and the date that the file was started, as well as
1035 the hostname, and a linefeed. What follows are binary format
1036 records consisting of a 32-bit record length in bytes, (including
1037 the length record itself), a 64-bit timestamp, and then the literal
1038 contents of the whack message that was received. All integers are
1039 in host format. In order to unambigously determine the host order,
1040 the first record is an empty record that contains only the current
1041 WHACK_MAGIC value. This record is 16 bytes long.
1042 ip-address
1044 If the remote peer has crashed, and therefor did not notify us, we
1045 keep sending encrypted traffic, and rejecting all plaintext
1046 (non-IKE) traffic from that remote peer. The --crash brings our end
1047 down as well for all the known connections to the specified
1048 ip-address
1049 The public key for informs pluto of the RSA public key for a potential
1051 peer. Private keys must be kept secret, so they are kept in
1052 ipsec.secrets(5).
1053 --keyid id
1055 specififies the identity of the peer for which a public key should
1056 be used. Its form is identical to the identity in the connection.
1057 If no public key is specified, pluto attempts to find KEY records
1058 from DNS for the id (if a FQDN) or through reverse lookup (if an IP
1059 address). Note that there several interesting ways in which this is
1060 not secure.
1061 --addkey
1063 specifies that the new key is added to the collection; otherwise
1064 the new key replaces any old ones.
1065 --pubkeyrsa key
1067 specifies the value of the RSA public key. It is a sequence of
1068 bytes as described in RFC 2537 “RSA/MD5 KEYs and SIGs in the Domain
1069 Name System (DNS)”. It is denoted in a way suitable for
1070 ipsec_ttodata(3). For example, a base 64 numeral starts with 0s.
1071 The listen form tells pluto to start listening for IKE requests on its
1073 public interfaces. To avoid race conditions, it is normal to load the
1074 appropriate connections into pluto before allowing it to listen. If
1075 pluto isn´t listening, it is pointless to initiate negotiations, so it
1076 will refuse requests to do so. Whenever the listen form is used, pluto
1077 looks for public interfaces and will notice when new ones have been
1078 added and when old ones have been removed. This is also the trigger for
1079 pluto to read the ipsec.secrets file. So listen may useful more than
1080 once.
1081 --listen
1083 start listening for IKE traffic on public interfaces.
1084 --unlisten
1086 stop listening for IKE traffic on public interfaces.
1087 The status form will display information about the internal state of
1089 pluto: information about each potential connection, about each state
1090 object, and about each shunt that pluto is managing without an
1091 associated connection.
1092 --status
1094 The shutdown form is the proper way to shut down pluto. It will tear
1096 down the SAs on this machine that pluto has negotiated. It does not
1097 inform its peers, so the SAs on their machines remain.
1098 --shutdown
1100 Examples
1102 It would be normal to start pluto in one of the system initialization
1103 scripts. It needs to be run by the superuser. Generally, no arguments
1104 are needed. To run in manually, the superuser can simply type
1105 ipsec pluto
1107 The command will immediately return, but a pluto process will be left
1109 running, waiting for requests from whack or a peer.
1110 Using whack, several potential connections would be described:
1112 ipsec whack --name silly --host 127.0.0.1 --to --host 127.0.0.2
1114 --ikelifetime 900 --ipseclifetime 800 --keyingtries 3
1115 Since this silly connection description specifies neither encryption,
1117 authentication, nor tunneling, it could only be used to establish an
1118 ISAKMP SA.
1119 ipsec whack --name secret --host 10.0.0.1 --client 10.0.1.0/24 --to
1121 --host 10.0.0.2 --client 10.0.2.0/24 --encrypt
1122 This is something that must be done on both sides. If the other side is
1124 pluto, the same whack command could be used on it (the command syntax
1125 is designed to not distinguish which end is ours).
1126 Now that the connections are specified, pluto is ready to handle
1128 requests and replies via the public interfaces. We must tell it to
1129 discover those interfaces and start accepting messages from peers:
1130 ipsec whack --listen
1132 If we don´t immediately wish to bring up a secure connection between
1134 the two clients, we might wish to prevent insecure traffic. The routing
1135 form asks pluto to cause the packets sent from our client to the peer´s
1136 client to be routed through the ipsec0 device; if there is no SA, they
1137 will be discarded:
1138 ipsec whack --route secret
1140 Finally, we are ready to get pluto to initiate negotiation for an IPsec
1142 SA (and implicitly, an ISAKMP SA):
1143 ipsec whack --initiate --name secret
1145 A small log of interesting events will appear on standard output (other
1147 logging is sent to syslog).
1148 whack can also be used to terminate pluto cleanly, tearing down all SAs
1150 that it has negotiated.
1151 ipsec whack --shutdown
1153 Notification of any IPSEC SA deletion, but not ISAKMP SA deletion is
1155 sent to the peer. Unfortunately, such Notification is not reliable.
1156 Furthermore, pluto itself ignores Notifications.
1157 XAUTH
1159 If pluto needs additional authentication, such as defined by the XAUTH
1160 specifications, then it may ask whack to prompt the operator for
1161 username or passwords. Typically, these will be entered interactively.
1162 A GUI that wraps around whack may look for the 041 (username) or 040
1163 (password) prompts, and display them to the user.
1164 For testing purposes, the options --xauthuser user --xauthpass pass may
1166 be be given prior to the --initiate to provide responses to the
1167 username and password prompts.
1168 The updown command
1170 Whenever pluto brings a connection up or down, it invokes the updown
1171 command. This command is specified using the --updown option. This
1172 allows for customized control over routing and firewall manipulation.
1173 The updown is invoked for five different operations. Each of these
1175 operations can be for our client subnet or for our host itself.
1176 prepare-host or prepare-client
1178 is run before bringing up a new connection if no other connection
1179 with the same clients is up. Generally, this is useful for deleting
1180 a route that might have been set up before pluto was run or perhaps
1181 by some agent not known to pluto.
1182 route-host or route-client
1184 is run when bringing up a connection for a new peer client subnet
1185 (even if prepare-host or prepare-client was run). The command
1186 should install a suitable route. Routing decisions are based only
1187 on the destination (peer´s client) subnet address, unlike eroutes
1188 which discriminate based on source too.
1189 unroute-host or unroute-client
1191 is run when bringing down the last connection for a particular peer
1192 client subnet. It should undo what the route-host or route-client
1193 did.
1194 up-host or up-client
1196 is run when bringing up a tunnel eroute with a pair of client
1197 subnets that does not already have a tunnel eroute. This command
1198 should install firewall rules as appropriate. It is generally a
1199 good idea to allow IKE messages (UDP port 500) travel between the
1200 hosts.
1201 down-host or down-client
1203 is run when bringing down the eroute for a pair of client subnets.
1204 This command should delete firewall rules as appropriate. Note that
1205 there may remain some inbound IPsec SAs with these client subnets.
1206 The script is passed a large number of environment variables to specify
1208 what needs to be done.
1209 PLUTO_VERSION
1211 indicates what version of this interface is being used. This
1212 document describes version 1.1. This is upwardly compatible with
1213 version 1.0.
1214 PLUTO_VERB
1216 specifies the name of the operation to be performed (prepare-host,r
1217 prepare-client, up-host, up-client, down-host, or down-client). If
1218 the address family for security gateway to security gateway
1219 communications is IPv6, then a suffix of -v6 is added to the verb.
1220 PLUTO_CONNECTION
1222 is the name of the connection for which we are routing.
1223 PLUTO_NEXT_HOP
1225 is the next hop to which packets bound for the peer must be sent.
1226 PLUTO_INTERFACE
1228 is the name of the ipsec interface to be used.
1229 PLUTO_ME
1231 is the IP address of our host.
1232 PLUTO_MY_CLIENT
1234 is the IP address / count of our client subnet. If the client is
1235 just the host, this will be the host´s own IP address / max (where
1236 max is 32 for IPv4 and 128 for IPv6).
1237 PLUTO_MY_CLIENT_NET
1239 is the IP address of our client net. If the client is just the
1240 host, this will be the host´s own IP address.
1241 PLUTO_MY_CLIENT_MASK
1243 is the mask for our client net. If the client is just the host,
1244 this will be 255.255.255.255.
1245 PLUTO_PEER
1247 is the IP address of our peer.
1248 PLUTO_PEER_CLIENT
1250 is the IP address / count of the peer´s client subnet. If the
1251 client is just the peer, this will be the peer´s own IP address /
1252 max (where max is 32 for IPv4 and 128 for IPv6).
1253 PLUTO_PEER_CLIENT_NET
1255 is the IP address of the peer´s client net. If the client is just
1256 the peer, this will be the peer´s own IP address.
1257 PLUTO_PEER_CLIENT_MASK
1259 is the mask for the peer´s client net. If the client is just the
1260 peer, this will be 255.255.255.255.
1261 PLUTO_MY_PROTOCOL
1263 lists the protocols allowed over this IPsec SA.
1264 PLUTO_PEER_PROTOCOL
1266 lists the protocols the peer allows over this IPsec SA.
1267 PLUTO_MY_PORT
1269 lists the ports allowed over this IPsec SA.
1270 PLUTO_PEER_PORT
1272 lists the ports the peer allows over this IPsec SA.
1273 PLUTO_MY_ID
1275 lists our id.
1276 PLUTO_PEER_ID
1278 Dlists our peer´s id.
1279 PLUTO_PEER_CA
1281 lists the peer´s CA.
1282 All output sent by the script to stderr or stdout is logged. The script
1284 should return an exit status of 0 if and only if it succeeds.
1285 Pluto waits for the script to finish and will not do any other
1287 processing while it is waiting. The script may assume that pluto will
1288 not change anything while the script runs. The script should avoid
1289 doing anything that takes much time and it should not issue any command
1290 that requires processing by pluto. Either of these activities could be
1291 performed by a background subprocess of the script.
1292 Rekeying
1294 When an SA that was initiated by pluto has only a bit of lifetime left,
1295 pluto will initiate the creation of a new SA. This applies to ISAKMP
1296 and IPsec SAs. The rekeying will be initiated when the SA´s remaining
1297 lifetime is less than the rekeymargin plus a random percentage, between
1298 0 and rekeyfuzz, of the rekeymargin.
1299 Similarly, when an SA that was initiated by the peer has only a bit of
1301 lifetime left, pluto will try to initiate the creation of a
1302 replacement. To give preference to the initiator, this rekeying will
1303 only be initiated when the SA´s remaining lifetime is half of
1304 rekeymargin. If rekeying is done by the responder, the roles will be
1305 reversed: the responder for the old SA will be the initiator for the
1306 replacement. The former initiator might also initiate rekeying, so
1307 there may be redundant SAs created. To avoid these complications, make
1308 sure that rekeymargin is generous.
1309 One risk of having the former responder initiate is that perhaps none
1311 of its proposals is acceptable to the former initiator (they have not
1312 been used in a successful negotiation). To reduce the chances of this
1313 happening, and to prevent loss of security, the policy settings are
1314 taken from the old SA (this is the case even if the former initiator is
1315 initiating). These may be stricter than those of the connection.
1316 pluto will not rekey an SA if that SA is not the most recent of its
1318 type (IPsec or ISAKMP) for its potential connection. This avoids
1319 creating redundant SAs.
1320 The random component in the rekeying time (rekeyfuzz) is intended to
1322 make certain pathological patterns of rekeying unstable. If both sides
1323 decide to rekey at the same time, twice as many SAs as necessary are
1324 created. This could become a stable pattern without the randomness.
1325 Another more important case occurs when a security gateway has SAs with
1327 many other security gateways. Each of these connections might need to
1328 be rekeyed at the same time. This would cause a high peek requirement
1329 for resources (network bandwidth, CPU time, entropy for random
1330 numbers). The rekeyfuzz can be used to stagger the rekeying times.
1331 Once a new set of SAs has been negotiated, pluto will never send
1333 traffic on a superseded one. Traffic will be accepted on an old SA
1334 until it expires.
1335 Selecting a Connection When Responding: Road Warrior Support
1337 When pluto receives an initial Main Mode message, it needs to decide
1338 which connection this message is for. It picks based solely on the
1339 source and destination IP addresses of the message. There might be
1340 several connections with suitable IP addresses, in which case one of
1341 them is arbitrarily chosen. (The ISAKMP SA proposal contained in the
1342 message could be taken into account, but it is not.)
1343 The ISAKMP SA is negotiated before the parties pass further identifying
1345 information, so all ISAKMP SA characteristics specified in the
1346 connection description should be the same for every connection with the
1347 same two host IP addresses. At the moment, the only characteristic that
1348 might differ is authentication method.
1349 Up to this point, all configuring has presumed that the IP addresses
1351 are known to all parties ahead of time. This will not work when either
1352 end is mobile (or assigned a dynamic IP address for other reasons). We
1353 call this situation “Road Warrior”. It is fairly tricky and has some
1354 important limitations, most of which are features of the IKE protocol.
1355 Only the initiator may be mobile: the initiator may have an IP number
1357 unknown to the responder. When the responder doesn´t recognize the IP
1358 address on the first Main Mode packet, it looks for a connection with
1359 itself as one end and %any as the other. If it cannot find one, it
1360 refuses to negotiate. If it does find one, it creates a temporary
1361 connection that is a duplicate except with the %any replaced by the
1362 source IP address from the packet; if there was no identity specified
1363 for the peer, the new IP address will be used.
1364 When pluto is using one of these temporary connections and needs to
1366 find the preshared secret or RSA private key in ipsec.secrets, and and
1367 the connection specified no identity for the peer, %any is used as its
1368 identity. After all, the real IP address was apparently unknown to the
1369 configuration, so it is unreasonable to require that it be used in this
1370 table.
1371 Part way into the Phase 1 (Main Mode) negotiation using one of these
1373 temporary connection descriptions, pluto will be receive an Identity
1374 Payload. At this point, pluto checks for a more appropriate connection,
1375 one with an identity for the peer that matches the payload but which
1376 would use the same keys so-far used for authentication. If it finds
1377 one, it will switch to using this better connection (or a temporary
1378 derived from this, if it has %any for the peer´s IP address). It may
1379 even turn out that no connection matches the newly discovered identity,
1380 including the current connection; if so, pluto terminates negotiation.
1381 Unfortunately, if preshared secret authentication is being used, the
1383 Identity Payload is encrypted using this secret, so the secret must be
1384 selected by the responder without knowing this payload. This limits
1385 there to being at most one preshared secret for all Road Warrior
1386 systems connecting to a host. RSA Signature authentications does not
1387 require that the responder know how to select the initiator´s public
1388 key until after the initiator´s Identity Payload is decoded (using the
1389 responder´s private key, so that must be preselected).
1390 When pluto is responding to a Quick Mode negotiation via one of these
1392 temporary connection descriptions, it may well find that the subnets
1393 specified by the initiator don´t match those in the temporary
1394 connection description. If so, it will look for a connection with
1395 matching subnets, its own host address, a peer address of %any and
1396 matching identities. If it finds one, a new temporary connection is
1397 derived from this one and used for the Quick Mode negotiation of IPsec
1398 SAs. If it does not find one, pluto terminates negotiation.
1399 Be sure to specify an appropriate nexthop for the responder to send a
1401 message to the initiator: pluto has no way of guessing it (if
1402 forwarding isn´t required, use an explicit %direct as the nexthop and
1403 the IP address of the initiator will be filled in; the obsolete
1404 notation 0.0.0.0 is still accepted).
1405 pluto has no special provision for the initiator side. The current
1407 (possibly dynamic) IP address and nexthop must be used in defining
1408 connections. These must be properly configured each time the
1409 initiator´s IP address changes. pluto has no mechanism to do this
1410 automatically.
1411 Although we call this Road Warrior Support, it could also be used to
1413 support encrypted connections with anonymous initiators. The
1414 responder´s organization could announce the preshared secret that would
1415 be used with unrecognized initiators and let anyone connect. Of course
1416 the initiator´s identity would not be authenticated.
1417 If any Road Warrior connections are supported, pluto cannot reject an
1419 exchange initiated by an unknown host until it has determined that the
1420 secret is not shared or the signature is invalid. This must await the
1421 third Main Mode message from the initiator. If no Road Warrior
1422 connection is supported, the first message from an unknown source would
1423 be rejected. This has implications for ease of debugging configurations
1424 and for denial of service attacks.
1425 Although a Road Warrior connection must be initiated by the mobile
1427 side, the other side can and will rekey using the temporary connection
1428 it has created. If the Road Warrior wishes to be able to disconnect, it
1429 is probably wise to set --keyingtries to 1 in the connection on the
1430 non-mobile side to prevent it trying to rekey the connection.
1431 Unfortunately, there is no mechanism to unroute the connection
1432 automatically.
1433 Debugging
1435 pluto accepts several optional arguments, useful mostly for debugging.
1436 Except for --interface, each should appear at most once.
1437 --interface interfacename
1439 specifies that the named real public network interface should be
1440 considered. The interface name specified should not be ipsecN. If
1441 the option doesn´t appear, all interfaces are considered. To
1442 specify several interfaces, use the option once for each. One use
1443 of this option is to specify which interface should be used when
1444 two or more share the same IP address.
1445 --ikeport port-number
1447 changes the UDP port that pluto will use (default, specified by
1448 IANA: 500)
1449 --ctlbase path
1451 basename for control files. path.ctl is the socket through which
1452 whack communicates with pluto. path.pid is the lockfile to prevent
1453 multiple pluto instances. The default is /var/run/pluto/pluto).
1454 --secretsfile file
1456 specifies the file for authentication secrets (default:
1457 /etc/ipsec.secrets). This name is subject to “globbing” as in
1458 sh(1), so every file with a matching name is processed. Quoting is
1459 generally needed to prevent the shell from doing the globbing.
1460 --adns path to adns, --lwdnsq path to lwdnsq
1462 specifies where to find pluto´s helper program for asynchronous DNS
1463 lookup. pluto can be built to use one of two helper programs:
1464 _pluto_adns or lwdnsq. You must use the program for which it was
1465 built. By default, pluto will look for the program in $IPSEC_DIR
1466 (if that environment variable is defined) or, failing that, in the
1467 same directory as pluto.
1468 --nofork
1470 disable “daemon fork” (default is to fork). In addition, after the
1471 lock file and control socket are created, print the line “Pluto
1472 initialized” to standard out.
1473 --uniqueids
1475 if this option has been selected, whenever a new ISAKMP SA is
1476 established, any connection with the same Peer ID but a different
1477 Peer IP address is unoriented (causing all its SAs to be deleted).
1478 This helps clean up dangling SAs when a connection is lost and then
1479 regained at another IP address.
1480 --force_busy
1482 if this option has been selected, pluto will be forced to be
1483 "busy". In this state, which happens when there is a Denial of
1484 Service attack, will force pluto to use cookies before accepting
1485 new incoming IKE packets. Cookies are send and required in ikev1
1486 Aggressive Mode and in ikev2. This option is mostly used for
1487 testing purposes, but can be selected by paranoid administrators as
1488 well.
1489 --stderrlog
1491 log goes to standard out {default is to use syslogd(8))
1492 For example
1494 pluto --secretsfile ipsec.secrets --ctlbase pluto.base --ikeport 8500
1496 --nofork --use-nostack --stderrlog
1497 lets one test pluto without using the superuser account.
1499 pluto is willing to produce a prodigious amount of debugging
1501 information. To do so, it must be compiled with -DDEBUG. There are
1502 several classes of debugging output, and pluto may be directed to
1503 produce a selection of them. All lines of debugging output are prefixed
1504 with “| ” to distinguish them from error messages.
1505 When pluto is invoked, it may be given arguments to specify which
1507 classes to output. The current options are:
1508 --debug-none
1510 disable all debugging
1511 --debug-all
1513 enable all debugging
1514 --debug-raw
1516 show the raw bytes of messages
1517 --debug-crypt
1519 show the encryption and decryption of messages
1520 --debug-parsing
1522 show the structure of input messages
1523 --debug-emitting
1525 show the structure of output messages
1526 --debug-control
1528 show pluto´s decision making
1529 --debug-controlmore
1531 show even more detailed pluto decision making
1532 --debug-lifecycle
1534 [this option is temporary] log more detail of lifecycle of SAs
1535 --debug-klips
1537 show pluto´s interaction with KLIPS
1538 --debug-pfkey
1540 show pluto´s PFKEYinterface communication
1541 --debug-dns
1543 show pluto´s interaction with DNS for KEY and TXT records
1544 --debug-dpd
1546 show pluto´s Dead Peer Detection handling
1547 --debug-natt
1549 show pluto´s NAT Traversal handling
1550 --debug-oppo
1552 show why pluto didn´t find a suitable DNS TXT record to authorize
1553 opportunistic initiation
1554 --debug-oppoinfo
1556 log when connections are initiated due to acquires from the kernel.
1557 This is often useful to know, but can be extremely chatty on a busy
1558 system.
1559 --debug-whackwatch
1561 if set, causes pluto not to release the whack --initiate channel
1562 until the SA is completely up. This will cause the requestor to
1563 possibly wait forever while pluto unsuccessfully negotiates. Used
1564 often in test cases.
1565 --debug-private
1567 allow debugging output with private keys.
1568 The debug form of the whack command will change the selection in a
1570 running pluto. If a connection name is specified, the flags are added
1571 whenever pluto has identified that it is dealing with that connection.
1572 Unfortunately, this is often part way into the operation being
1573 observed.
1574 For example, to start a pluto with a display of the structure of input
1576 and output:
1577 pluto --debug-emitting --debug-parsing
1579 To later change this pluto to only display raw bytes:
1581 whack --debug-raw
1583 For testing, SSH´s IKE test page is quite useful:
1585 http://isakmp-test.ssh.fi/
1587 Hint: ISAKMP SAs are often kept alive by IKEs even after the IPsec SA
1589 is established. This allows future IPsec SA´s to be negotiated
1590 directly. If one of the IKEs is restarted, the other may try to use the
1591 ISAKMP SA but the new IKE won´t know about it. This can lead to much
1592 confusion. pluto is not yet smart enough to get out of such a mess.
1593 Pluto´s Behaviour When Things Go Wrong
1595 When pluto doesn´t understand or accept a message, it just ignores the
1596 message. It is not yet capable of communicating the problem to the
1597 other IKE daemon (in the future it might use Notifications to
1598 accomplish this in many cases). It does log a diagnostic.
1599 When pluto gets no response from a message, it resends the same message
1601 (a message will be sent at most three times). This is appropriate: UDP
1602 is unreliable.
1603 When pluto gets a message that it has already seen, there are many
1605 cases when it notices and discards it. This too is appropriate for UDP.
1606 Combine these three rules, and you can explain many apparently
1608 mysterious behaviours. In a pluto log, retrying isn´t usually the
1609 interesting event. The critical thing is either earlier (pluto got a
1610 message which it didn´t like and so ignored, so it was still awaiting
1611 an acceptable message and got impatient) or on the other system (pluto
1612 didn´t send a reply because it wasn´t happy with the previous message).
1613 Notes
1615 If pluto is compiled without -DKLIPS, it negotiates Security
1616 Associations but never ask the kernel to put them in place and never
1617 makes routing changes. This allows pluto to be tested on systems
1618 without KLIPS, but makes it rather useless.
1619 Each IPsec SA is assigned an SPI, a 32-bit number used to refer to the
1621 SA. The IKE protocol lets the destination of the SA choose the SPI. The
1622 range 0 to 0xFF is reserved for IANA. Pluto also avoids choosing an
1623 SPI in the range 0x100 to 0xFFF, leaving these SPIs free for manual
1624 keying. Remember that the peer, if not pluto, may well chose SPIs in
1625 this range.
1626 Policies
1628 This catalogue of policies may be of use when trying to configure Pluto
1629 and another IKE implementation to interoperate.
1630 In Phase 1, only Main Mode is supported. We are not sure that
1632 Aggressive Mode is secure. For one thing, it does not support identity
1633 protection. It may allow more severe Denial Of Service attacks.
1634 No Informational Exchanges are supported. These are optional and since
1636 their delivery is not assured, they must not matter. It is the case
1637 that some IKE implementations won´t interoperate without Informational
1638 Exchanges, but we feel they are broken.
1639 No Informational Payloads are supported. These are optional, but
1641 useful. It is of concern that these payloads are not authenticated in
1642 Phase 1, nor in those Phase 2 messages authenticated with HASH(3).
1643 ·
1645 Diffie Hellman Groups MODP 1024 and MODP 1536 (2 and 5) are
1646 supported. Group MODP768 (1) is not supported because it is too
1647 weak.
1648 ·
1650 Host authetication can be done by RSA Signatures or Pre-Shared
1651 Secrets.
1652 ·
1654 3DES CBC (Cypher Block Chaining mode) is the only encryption
1655 supported, both for ISAKMP SAs and IPSEC SAs.
1656 ·
1658 MD5 and SHA1 hashing are supported for packet authentication in
1659 both kinds of SAs.
1660 ·
1662 The ESP, AH, or AH plus ESP are supported. If, and only if, AH and
1663 ESP are combined, the ESP need not have its own authentication
1664 component. The selection is controlled by the --encrypt and
1665 --authenticate flags.
1666 ·
1668 Each of these may be combined with IPCOMP Deflate compression, but
1669 only if the potential connection specifies compression and only if
1670 KLIPS is configured with IPCOMP support.
1671 ·
1673 The IPSEC SAs may be tunnel or transport mode, where appropriate.
1674 The --tunnel flag controls this when pluto is initiating.
1675 ·
1677 When responding to an ISAKMP SA proposal, the maximum acceptable
1678 lifetime is eight hours. The default is one hour. There is no
1679 minimum. The --ikelifetime flag controls this when pluto is
1680 initiating.
1681 ·
1683 When responding to an IPSEC SA proposal, the maximum acceptable
1684 lifetime is one day. The default is eight hours. There is no
1685 minimum. The --ipseclifetime flag controls this when pluto is
1686 initiating.
1687 ·
1689 PFS is acceptable, and will be proposed if the --pfs flag was
1690 specified. The DH group proposed will be the same as negotiated for
1691 Phase 1.
1692
1694 Pluto responds to SIGHUP by issuing a suggestion that ``whack
1695 --listen´´ might have been intended.
1696 Pluto exits when it recieves SIGTERM.
1698
1700 pluto normally forks a daemon process, so the exit status is normally a
1701 very preliminary result.
1702 0
1704 means that all is OK so far.
1705 1
1707 means that something was wrong.
1708 10
1710 means that the lock file already exists.
1711 If whack detects a problem, it will return an exit status of 1. If it
1713 received progress messages from pluto, it returns as status the value
1714 of the numeric prefix from the last such message that was not a message
1715 sent to syslog or a comment (but the prefix for success is treated as
1716 0). Otherwise, the exit status is 0.
1717
1719 /var/run/pluto/pluto.pid
1720 /var/run/pluto/pluto.ctl
1722 /etc/ipsec.secrets
1724 $IPSEC_LIBDIR/_pluto_adns
1726 $IPSEC_EXECDIR/lwdnsq
1728 /dev/urandom
1730
1732 IPSEC_LIBDIR
1733 IPSEC_EXECDIR
1735 IPSECmyid
1737 PLUTO_CORE_DIR
1739
1741 The rest of the Openswan distribution, in particular ipsec(8).
1742 ipsec_auto(8) is designed to make using pluto more pleasant. Use it!
1744 ipsec.secrets(5) describes the format of the secrets file.
1746 ipsec_atoaddr(3), part of the Openswan distribution, describes the
1748 forms that IP addresses may take. ipsec_atosubnet(3), part of the
1749 Openswan distribution, describes the forms that subnet specifications.
1750 For more information on IPsec, the mailing list, and the relevant
1752 documents, see:
1753 http://www.ietf.cnri.reston.va.us/html.charters/ipsec-charter.html
1755 At the time of writing, the most relevant IETF RFCs are:
1757 RFC2409 The Internet Key Exchange (IKE)
1759 RFC2408 Internet Security Association and Key Management Protocol
1761 (ISAKMP)
1762 RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP
1764 The Openswan web site <htp://www.openswan.org> and the mailing lists
1766 described there.
1767
1769 This code is released under the GPL terms. See the accompanying files
1770 COPYING and CREDITS for more details. The GPL does NOT apply to those
1771 pieces of code written by others which are included in this
1772 distribution, except as noted by the individual authors.
1773 This software was originally written for the FreeS/WAN project
1775 <http://www.freeswan.org>, founded by John Gilmore and managed by Hugh
1776 Daniel. It was written by Angelos D. Keromytis
1777 (angelos@dsl.cis.upenn.edu), in May/June 1997, in Athens, Greece.
1778 Thanks go to John Ioannidis for his help.
1779 It is currently maintained and extended by Xelerance Corporation, in
1781 Canada under the Openswan name. See CHANGES for details.
1782 FreeS/WAN was developed/maintained from 2000-2004 by D. Hugh Redelmeier
1784 (hugh@mimosa.com), in Canada. The regulations of Greece and Canada
1785 allow the code to be freely redistributable.
1786 Kai Martius (admin@imib.med.tu-dresden.de) contributed the initial
1788 version of the code supporting PFS.
1789 Richard Guy Briggs <rgb@conscoop.ottawa.on.ca> and Peter Onion
1791 <ponion@srd.bt.co.uk> added the PFKEY2 support.
1792 We gratefully acknowledge that we use parts of Eric Young´s libdes
1794 package; see ../libdes/COPYRIGHT.
1795
1797 pluto is a work-in-progress. It currently has many limitations. For
1798 example, it ignores notification messages that it receives, and it
1799 generates only Delete Notifications and those only for IPSEC SAs.
1800 pluto does not support the Commit Flag. The Commit Flag is a bad
1802 feature of the IKE protocol. It isn´t protected -- neither encrypted
1803 nor authenticated. A man in the middle could turn it on, leading to
1804 DoS. We just ignore it, with a warning. This should let us interoperate
1805 with implementations that insist on it, with minor damage.
1806 pluto does not check that the SA returned by the Responder is actually
1808 one that was proposed. It only checks that the SA is acceptable. The
1809 difference is not large, but can show up in attributes such as SA
1810 lifetime.
1811 There is no good way for a connection to be automatically terminated.
1813 This is a problem for Road Warrior and Opportunistic connections. The
1814 --dontrekey option does prevent the SAs from being rekeyed on expiry.
1815 Additonally, if a Road Warrior connection has a client subnet with a
1816 fixed IP address, a negotiation with that subnet will cause any other
1817 connection instantiations with that same subnet to be unoriented
1818 (deleted, in effect). See also the --uniqueids option for an extension
1819 of this.
1820 When pluto sends a message to a peer that has disappeared, pluto
1822 receives incomplete information from the kernel, so it logs the
1823 unsatisfactory message “some IKE message we sent has been rejected with
1824 ECONNREFUSED (kernel supplied no details)”. John Denker suggests that
1825 this command is useful for tracking down the source of these problems:
1826 tcpdump -i eth0 icmp[0] != 8 and icmp[0] != 0 Substitute your public
1827 interface for eth0 if it is different.
1828 The word “authenticate” is used for two different features. We must
1830 authenticate each IKE peer to the other. This is an important task of
1831 Phase 1. Each packet must be authenticated, both in IKE and in IPsec,
1832 and the method for IPsec is negotiated as an AH SA or part of an ESP
1833 SA. Unfortunately, the protocol has no mechanism for authenticating the
1834 Phase 2 identities.
1835 Bugs should be reported to the <users@lists.openswan.org> mailing list.
1837[FIXME: source] 26 October 2006 IPSEC_PLUTO(8)