Provided by: openswan_2.4.12+dfsg-1.3_i386 bug


       ipsec manual - take manually-keyed IPsec connections up and down


       ipsec manual [--show] [--showonly] [--other] [--iam address@interface]
             [--config configfile] operation

       ipsec manual [options] --union operation_part...


       Manual manipulates manually-keyed Openswan IPsec  connections,  setting
       them  up  and shutting them down, based on the information in the IPsec
       configuration file. Normally, manually keyed connections should not  be
       used  - automatic keying connections In the normal usage, connection is
       the name of a  connection  specification  in  the  configuration  file;
       operation  is  --up,  --down,  --route,  or --unroute. Manual generates
       setup (--route or --up) or teardown (--down or --unroute) commands  for
       the connection and feeds them to a shell for execution.

       The  --up  operation  brings  the  specified  connection  up, including
       establishing a suitable route for it if necessary.

       The --route operation just establishes  the  route  for  a  connection.
       Unless  and  until  an  --up  operation is done, packets routed by that
       route will simply be discarded.

       The --down operation tears the specified connection down,  except  that
       it  leaves  the route in place. Unless and until an --unroute operation
       is done, packets routed by that route will simply  be  discarded.  This
       permits establishing another connection to the same destination without
       any â

       The --unroute operation (and only the --unroute operation) deletes  any
       route established for a connection.

       In  the  --union  usage,  each part is the name of a partial connection
       specification in the configuration file,  and  the  union  of  all  the
       partial specifications is the connection specification used. The effect
       is as if the contents of the partial specifications  were  concatenated
       together;  restrictions  on duplicate parameters, etc., do apply to the
       result. (The same effect can now be had,  more  gracefully,  using  the
       also  parameter  in  connection  descriptions;  see  ipsec.conf(5)  for

       The --show option turns on the -x option of the shell used  to  execute
       the commands, so each command is shown as it is executed.

       The  --showonly option causes manual to show the commands it would run,
       on standard output, and not run them.

       The --other option causes manual to pretend it is the other end of  the
       connection.  This  is  probably  not  useful except in combination with

       The --iam option causes manual to believe it is  running  on  the  host
       with  the  specified  IP  address, and that it should use the specified
       interface (normally it determines all this automatically, based on what
       IPsec interfaces are up and how they are configured).

       The   --config   option  specifies  a  non-standard  location  for  the
       /etc/ipsec.conf) file.

       See ipsec.conf(5) for details of the configuration file. Apart from the
       basic   parameters  which  specify  the  endpoints  and  routing  of  a
       connection (left and  right,  plus  possibly  leftsubnet,  leftnexthop,
       leftfirewall,   their   right   equivalents,   and   perhaps  type),  a
       non-passthrough  manual connection needs an spi  or  spibase  parameter
       and  some  parameters  specifying  encryption, authentication, or both,
       most simply esp, espenckey, and espauthkey. Moderately-secure keys  can
       be obtained from ipsec_ranbits(8). For production use of manually-keyed
       connections, it is strongly recommended that the  keys  be  kept  in  a
       separate  file  (with permissions rw-------) using the include and also
       facilities of the configuration file (see ipsec.conf(5)).

       If an spi parameter is given, manual uses that value as the SPI  number
       for  all  the  SAs  (which are in separate number spaces anyway). If an
       spibase parameter is  given  instead,  manual  assigns  SPI  values  by
       altering  the  bottom digit of that value; SAs going from left to right
       get even digits starting at 0, SAs going from right  to  left  get  odd
       digits  starting  at 1. Either way, it is suggested that manually-keyed
       connections use three-digit SPIs with the first digit non-zero, i.e. in
       the  range  0x100  through  0xfff;  Openswan  reserves those for manual
       keying and will not attempt to use them for  automatic  keying  (unless
       requested to, presumably by a non-Openswan other end).


       /etc/ipsec.conf       default       IPsec       configuration      file
       /var/run/pluto/ information


       ipsec(8),      ipsec.conf(5),      ipsec_spi(8),       ipsec_eroute(8),
       ipsec_spigrp(8), route(8)


       Written    for   the   FreeS/WAN   project   <> by Henry Spencer.


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

       If  the connection specification for a connection is changed between an
       --up and the ensuing --down, chaos may ensue.

       The --up operation is not smart enough to notice whether the connection
       is already up.

       Manual   is  not  smart  enough  to  reject  insecure  combinations  of
       algorithms, e.g. encryption with no authentication at all.

       Any non-IPsec route to the other end which is replaced by the  --up  or
       --route operation will not be re-established by --unroute. Whether this
       is a feature or a bug depends on your viewpoint.

       The optional parameters which override the automatic spibase-based  SPI
       assignment are a messy area of the code and bugs are likely.

Road warriorâ handling, and other special forms of setup which require negotiation between the two security gateways, inherently cannot be done with manual.

       Manual  generally lags behind auto in support of various features, even
       when implementation would be possible. For example, currently  it  does
       not do IPComp content compression.