ims-volte-vowifi
/
strongswan
9
0
Fork 0
Code Pull Requests Releases Activity

- import of strongswan-2.7.0 

- applied patch for charon
This commit is contained in:
Martin Willi 2006-04-28 07:14:48 +00:00
parent 52923c9acb
commit 997358a6c4
2043 changed files with 346842 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

691
CHANGES Normal file
View File

@ -0,0 +1,691 @@
strongswan-2.7.0
----------------
- the dynamic iptables rules from the _updown_x509 template
for KLIPS and the _updown_policy template for NETKEY have
been merged into the default _updown script. The existing
left|rightfirewall keyword causes the automatic insertion
and deletion of ACCEPT rules for tunneled traffic upon
the successful setup and teardown of an IPsec SA, respectively.
left|rightfirwall can be used with KLIPS under any Linux 2.4
kernel or with NETKEY under a Linux kernel version >= 2.6.16
in conjuction with iptables >= 1.3.5. For NETKEY under a Linux
kernel version < 2.6.16 which does not support IPsec policy
matching yet, please continue to use a copy of the _updown_espmark
template loaded via the left|rightupdown keyword.
- a new left|righthostaccess keyword has been introduced which
can be used in conjunction with left|rightfirewall and the
default _updown script. By default leftfirewall=yes inserts
a bi-directional iptables FORWARD rule for a local client network
with a netmask different from 255.255.255.255 (single host).
This does not allow to access the VPN gateway host via its
internal network interface which is part of the client subnet
because an iptables INPUT and OUTPUT rule would be required.
lefthostaccess=yes will cause this additional ACCEPT rules to
be inserted.
- mixed PSK|RSA roadwarriors are now supported. The ISAKMP proposal
payload is preparsed in order to find out whether the roadwarrior
requests PSK or RSA so that a matching connection candidate can
be found.
strongswan-2.6.4
----------------
- the new _updown_policy template allows ipsec policy based
iptables firewall rules. Required are iptables version
>= 1.3.5 and linux kernel >= 2.6.16. This script obsoletes
the _updown_espmark template, so that no INPUT mangle rules
are required any more.
- added support of DPD restart mode
- ipsec starter now allows the use of wildcards in include
statements as e.g. in "include /etc/my_ipsec/*.conf".
Patch courtesy of Matthias Haas.
- the Netscape OID 'employeeNumber' is now recognized and can be
used as a Relative Distinguished Name in certificates.
strongswan-2.6.3
----------------
- /etc/init.d/ipsec or /etc/rc.d/ipsec is now a copy of the ipsec
command and not of ipsec setup any more.
- ipsec starter now supports AH authentication in conjunction with
ESP encryption. AH authentication is configured in ipsec.conf
via the auth=ah parameter.
- The command ipsec scencrypt|scdecrypt <args> is now an alias for
ipsec whack --scencrypt|scdecrypt <args>.
- get_sa_info() now determines for the native netkey IPsec stack
the exact time of the last use of an active eroute. This information
is used by the Dead Peer Detection algorithm and is also displayed by
the ipsec status command.
strongswan-2.6.2
----------------
- running under the native Linux 2.6 IPsec stack, the function
get_sa_info() is called by ipsec auto --status to display the current
number of transmitted bytes per IPsec SA.
- get_sa_info() is also used by the Dead Peer Detection process to detect
recent ESP activity. If ESP traffic was received from the peer within
the last dpd_delay interval then no R_Y_THERE notification must be sent.
- strongSwan now supports the Relative Distinguished Name "unstructuredName"
in ID_DER_ASN1_DN identities. The following notations are possible:
rightid="unstructuredName=John Doe"
rightid="UN=John Doe"
- fixed a long-standing bug which caused PSK-based roadwarrior connections
to segfault in the function id.c:same_id() called by keys.c:get_secret()
if an FQDN, USER_FQDN, or Key ID was defined, as in the following example.
conn rw
right=%any
rightid=@foo.bar
authby=secret
- the ipsec command now supports most ipsec auto commands (e.g. ipsec listall).
- ipsec starter didn't set host_addr and client.addr ports in whack msg.
- in order to guarantee backwards-compatibility with the script-based
auto function (e.g. auto --replace), the ipsec starter scripts stores
the defaultroute information in the temporary file /var/run/ipsec.info.
- The compile-time option USE_XAUTH_VID enables the sending of the XAUTH
Vendor ID which is expected by Cisco PIX 7 boxes that act as IKE Mode Config
servers.
- the ipsec starter now also recognizes the parameters authby=never and
type=passthrough|pass|drop|reject.
strongswan-2.6.1
----------------
- ipsec starter now supports the also parameter which allows
a modular structure of the connection definitions. Thus
"ipsec start" is now ready to replace "ipsec setup".
strongswan-2.6.0
----------------
- Mathieu Lafon's popular ipsec starter tool has been added to the
strongSwan distribution. Many thanks go to Stephan Scholz from astaro
for his integration work. ipsec starter is a C program which is going
to replace the various shell and awk starter scripts (setup, _plutoload,
_plutostart, _realsetup, _startklips, _confread, and auto). Since
ipsec.conf is now parsed only once, the starting of multiple tunnels is
accelerated tremedously.
- Added support of %defaultroute to the ipsec starter. If the IP address
changes, a HUP signal to the ipsec starter will automatically
reload pluto's connections.
- moved most compile time configurations from pluto/Makefile to
Makefile.inc by defining the options USE_LIBCURL, USE_LDAP,
USE_SMARTCARD, and USE_NAT_TRAVERSAL_TRANSPORT_MODE.
- removed the ipsec verify and ipsec newhostkey commands
- fixed some 64-bit issues in formatted print statements
- The scepclient functionality implementing the Simple Certificate
Enrollment Protocol (SCEP) is nearly complete but hasn't been
documented yet.
strongswan-2.5.7
----------------
- CA certicates are now automatically loaded from a smartcard
or USB crypto token and appear in the ipsec auto --listcacerts
listing.
strongswan-2.5.6
----------------
- when using "ipsec whack --scencrypt <data>" with a PKCS#11
library that does not support the C_Encrypt() Cryptoki
function (e.g. OpenSC), the RSA encryption is done in
software using the public key fetched from the smartcard.
- The scepclient function now allows to define the
validity of a self-signed certificate using the --days,
--startdate, and --enddate options. The default validity
has been changed from one year to five years.
strongswan-2.5.5
----------------
- the config setup parameter pkcs11proxy=yes opens pluto's PKCS#11
interface to other applications for RSA encryption and decryption
via the whack interface. Notation:
ipsec whack --scencrypt <data>
[--inbase 16|hex|64|base64|256|text|ascii]
[--outbase 16|hex|64|base64|256|text|ascii]
[--keyid <keyid>]
ipsec whack --scdecrypt <data>
[--inbase 16|hex|64|base64|256|text|ascii]
[--outbase 16|hex|64|base64|256|text|ascii]
[--keyid <keyid>]
The default setting for inbase and outbase is hex.
The new proxy interface can be used for securing symmetric
encryption keys required by the cryptoloop or dm-crypt
disk encryption schemes, especially in the case when
pkcs11keepstate=yes causes pluto to lock the pkcs11 slot
permanently.
- if the file /etc/ipsec.secrets is lacking during the startup of
pluto then the root-readable file /etc/ipsec.d/private/myKey.der
containing a 2048 bit RSA private key and a matching self-signed
certificate stored in the file /etc/ipsec.d/certs/selfCert.der
is automatically generated by calling the function
ipsec scepclient --out pkcs1 --out cert-self
scepclient was written by Jan Hutter and Martin Willi, students
at the University of Applied Sciences in Rapperswil, Switzerland.
strongswan-2.5.4
----------------
- the current extension of the PKCS#7 framework introduced
a parsing error in PKCS#7 wrapped X.509 certificates that are
e.g. transmitted by Windows XP when multi-level CAs are used.
the parsing syntax has been fixed.
- added a patch by Gerald Richter which tolerates multiple occurrences
of the ipsec0 interface when using KLIPS.
strongswan-2.5.3
----------------
- with gawk-3.1.4 the word "default2 has become a protected
keyword for use in switch statements and cannot be used any
more in the strongSwan scripts. This problem has been
solved by renaming "default" to "defaults" and "setdefault"
in the scripts _confread and auto, respectively.
- introduced the parameter leftsendcert with the values
always|yes (the default, always send a cert)
ifasked (send the cert only upon a cert request)
never|no (never send a cert, used for raw RSA keys and
self-signed certs)
- fixed the initialization of the ESP key length to a default of
128 bits in the case that the peer does not send a key length
attribute for AES encryption.
- applied Herbert Xu's uniqueIDs patch
- applied Herbert Xu's CLOEXEC patches
strongswan-2.5.2
----------------
- CRLs can now be cached also in the case when the issuer's
certificate does not contain a subjectKeyIdentifier field.
In that case the subjectKeyIdentifier is computed by pluto as the
160 bit SHA-1 hash of the issuer's public key in compliance
with section 4.2.1.2 of RFC 3280.
- Fixed a bug introduced by strongswan-2.5.1 which eliminated
not only multiple Quick Modes of a given connection but also
multiple connections between two security gateways.
strongswan-2.5.1
----------------
- Under the native IPsec of the Linux 2.6 kernel, a %trap eroute
installed either by setting auto=route in ipsec.conf or by
a connection put into hold, generates an XFRM_AQUIRE event
for each packet that wants to use the not-yet exisiting
tunnel. Up to now each XFRM_AQUIRE event led to an entry in
the Quick Mode queue, causing multiple IPsec SA to be
established in rapid succession. Starting with strongswan-2.5.1
only a single IPsec SA is established per host-pair connection.
- Right after loading the PKCS#11 module, all smartcard slots are
searched for certificates. The result can be viewed using
the command
ipsec auto --listcards
The certificate objects found in the slots are numbered
starting with #1, #2, etc. This position number can be used to address
certificates (leftcert=%smartcard) and keys (: PIN %smartcard)
in ipsec.conf and ipsec.secrets, respectively:
%smartcard (selects object #1)
%smartcard#1 (selects object #1)
%smartcard#3 (selects object #3)
As an alternative the existing retrieval scheme can be used:
%smartcard:45 (selects object with id=45)
%smartcard0 (selects first object in slot 0)
%smartcard4:45 (selects object in slot 4 with id=45)
- Depending on the settings of CKA_SIGN and CKA_DECRYPT
private key flags either C_Sign() or C_Decrypt() is used
to generate a signature.
- The output buffer length parameter siglen in C_Sign()
is now initialized to the actual size of the output
buffer prior to the function call. This fixes the
CKR_BUFFER_TOO_SMALL error that could occur when using
the OpenSC PKCS#11 module.
- Changed the initialization of the PKCS#11 CK_MECHANISM in
C_SignInit() to mech = { CKM_RSA_PKCS, NULL_PTR, 0 }.
- Refactored the RSA public/private key code and transferred it
from keys.c to the new pkcs1.c file as a preparatory step
towards the release of the SCEP client.
strongswan-2.5.0
----------------
- The loading of a PKCS#11 smartcard library module during
runtime does not require OpenSC library functions any more
because the corresponding code has been integrated into
smartcard.c. Also the RSAREF pkcs11 header files have been
included in a newly created pluto/rsaref directory so that
no external include path has to be defined any longer.
- A long-awaited feature has been implemented at last:
The local caching of CRLs fetched via HTTP or LDAP, activated
by the parameter cachecrls=yes in the config setup section
of ipsec.conf. The dynamically fetched CRLs are stored under
a unique file name containing the issuer's subjectKeyID
in /etc/ipsec.d/crls.
- Applied a one-line patch courtesy of Michael Richardson
from the Openswan project which fixes the kernel-oops
in KLIPS when an snmp daemon is running on the same box.
strongswan-2.4.4
----------------
- Eliminated null length CRL distribution point strings.
- Fixed a trust path evaluation bug introduced with 2.4.3
strongswan-2.4.3
----------------
- Improved the joint OCSP / CRL revocation policy.
OCSP responses have precedence over CRL entries.
- Introduced support of CRLv2 reason codes.
- Fixed a bug with key-pad equipped readers which caused
pluto to prompt for the pin via the console when the first
occasion to enter the pin via the key-pad was missed.
- When pluto is built with LDAP_V3 enabled, the library
liblber required by newer versions of openldap is now
included.
strongswan-2.4.2
----------------
- Added the _updown_espmark template which requires all
incoming ESP traffic to be marked with a default mark
value of 50.
- Introduced the pkcs11keepstate parameter in the config setup
section of ipsec.conf. With pkcs11keepstate=yes the PKCS#11
session and login states are kept as long as possible during
the lifetime of pluto. This means that a PIN entry via a key
pad has to be done only once.
- Introduced the pkcs11module parameter in the config setup
section of ipsec.conf which specifies the PKCS#11 module
to be used with smart cards. Example:
pkcs11module=/usr/lib/pkcs11/opensc-pkcs11.lo
- Added support of smartcard readers equipped with a PIN pad.
- Added patch by Jay Pfeifer which detects when netkey
modules have been statically built into the Linux 2.6 kernel.
- Added two patches by Herbert Xu. The first uses ip xfrm
instead of setkey to flush the IPsec policy database. The
second sets the optional flag in inbound IPComp SAs only.
- Applied Ulrich Weber's patch which fixes an interoperability
problem between native IPsec and KLIPS systems caused by
setting the replay window to 32 instead of 0 for ipcomp.
strongswan-2.4.1
----------------
- Fixed a bug which caused an unwanted Mode Config request
to be initiated in the case where "right" was used to denote
the local side in ipsec.conf and "left" the remote side,
contrary to the recommendation that "right" be remote and
"left" be"local".
strongswan-2.4.0a
-----------------
- updated Vendor ID to strongSwan-2.4.0
- updated copyright statement to include David Buechi and
Michael Meier
strongswan-2.4.0
----------------
- strongSwan now communicates with attached smartcards and
USB crypto tokens via the standardized PKCS #11 interface.
By default the OpenSC library from www.opensc.org is used
but any other PKCS#11 library could be dynamically linked.
strongSwan's PKCS#11 API was implemented by David Buechi
and Michael Meier, both graduates of the Zurich University
of Applied Sciences in Winterthur, Switzerland.
- When a %trap eroute is triggered by an outgoing IP packet
then the native IPsec stack of the Linux 2.6 kernel [often/
always?] returns an XFRM_ACQUIRE message with an undefined
protocol family field and the connection setup fails.
As a workaround IPv4 (AF_INET) is now assumed.
- the results of the UML test scenarios are now enhanced
with block diagrams of the virtual network topology used
in a particular test.
strongswan-2.3.2
----------------
- fixed IV used to decrypt informational messages.
This bug was introduced with Mode Config functionality.
- fixed NCP Vendor ID.
- undid one of Ulrich Weber's maximum udp size patches
because it caused a segmentation fault with NAT-ed
Delete SA messages.
- added UML scenarios wildcards and attr-cert which
demonstrate the implementation of IPsec policies based
on wildcard parameters contained in Distinguished Names and
on X.509 attribute certificates, respectively.
strongswan-2.3.1
----------------
- Added basic Mode Config functionality
- Added Mathieu Lafon's patch which upgrades the status of
the NAT-Traversal implementation to RFC 3947.
- The _startklips script now also loads the xfrm4_tunnel
module.
- Added Ulrich Weber's netlink replay window size and
maximum udp size patches.
- UML testing now uses the Linux 2.6.10 UML kernel by default.
strongswan-2.3.0
----------------
- Eric Marchionni and Patrik Rayo, both recent graduates from
the Zuercher Hochschule Winterthur in Switzerland, created a
User-Mode-Linux test setup for strongSwan. For more details
please read the INSTALL and README documents in the testing
subdirectory.
- Full support of group attributes based on X.509 attribute
certificates. Attribute certificates can be generated
using the openac facility. For more details see
man ipsec_openac.
The group attributes can be used in connection definitions
in order to give IPsec access to specific user groups.
This is done with the new parameter left|rightgroups as in
rightgroups="Research, Sales"
giving access to users possessing the group attributes
Research or Sales, only.
- In Quick Mode clients with subnet mask /32 are now
coded as IP_V4_ADDRESS or IP_V6_ADDRESS. This should
fix rekeying problems with the SafeNet/SoftRemote and NCP
Secure Entry Clients.
- Changed the defaults of the ikelifetime and keylife parameters
to 3h and 1h, respectively. The maximum allowable values are
now both set to 24 h.
- Suppressed notification wars between two IPsec peers that
could e.g. be triggered by incorrect ISAKMP encryption.
- Public RSA keys can now have identical IDs if either the
issuing CA or the serial number is different. The serial
number of a certificate is now shown by the command
ipsec auto --listpubkeys
strongswan-2.2.2
----------------
- Added Tuomo Soini's sourceip feature which allows a strongSwan
roadwarrior to use a fixed Virtual IP (see README section 2.6)
and reduces the well-known four tunnel case on VPN gateways to
a single tunnel definition (see README section 2.4).
- Fixed a bug occuring with NAT-Traversal enabled when the responder
suddenly turns initiator and the initiator cannot find a matching
connection because of the floated IKE port 4500.
- Removed misleading ipsec verify command from barf.
- Running under the native IP stack, ipsec --version now shows
the Linux kernel version (courtesy to the Openswan project).
strongswan-2.2.1
----------------
- Introduced the ipsec auto --listalgs monitoring command which lists
all currently registered IKE and ESP algorithms.
- Fixed a bug in the ESP algorithm selection occuring when the strict flag
is set and the first proposed transform does not match.
- Fixed another deadlock in the use of the lock_certs_and_keys() mutex,
occuring when a smartcard is present.
- Prevented that a superseded Phase1 state can trigger a DPD_TIMEOUT event.
- Fixed the printing of the notification names (null)
- Applied another of Herbert Xu's Netlink patches.
strongswan-2.2.0
----------------
- Support of Dead Peer Detection. The connection parameter
dpdaction=clear|hold
activates DPD for the given connection.
- The default Opportunistic Encryption (OE) policy groups are not
automatically included anymore. Those wishing to activate OE can include
the policy group with the following statement in ipsec.conf:
include /etc/ipsec.d/examples/oe.conf
The default for [right|left]rsasigkey is now set to %cert.
- strongSwan now has a Vendor ID of its own which can be activated
using the compile option VENDORID
- Applied Herbert Xu's patch which sets the compression algorithm correctly.
- Applied Herbert Xu's patch fixing an ESPINUDP problem
- Applied Herbert Xu's patch setting source/destination port numbers.
- Reapplied one of Herbert Xu's NAT-Traversal patches which got
lost during the migration from SuperFreeS/WAN.
- Fixed a deadlock in the use of the lock_certs_and_keys() mutex.
- Fixed the unsharing of alg parameters when instantiating group
connection.
strongswan-2.1.5
----------------
- Thomas Walpuski made me aware of a potential DoS attack via
a PKCS#7-wrapped certificate bundle which could overwrite valid CA
certificates in Pluto's authority certificate store. This vulnerability
was fixed by establishing trust in CA candidate certificates up to a
trusted root CA prior to insertion into Pluto's chained list.
- replaced the --assign option by the -v option in the auto awk script
in order to make it run with mawk under debian/woody.
strongswan-2.1.4
----------------
- Split of the status information between ipsec auto --status (concise)
and ipsec auto --statusall (verbose). Both commands can be used with
an optional connection selector:
ipsec auto --status[all] <connection_name>
- Added the description of X.509 related features to the ipsec_auto(8)
man page.
- Hardened the ASN.1 parser in debug mode, especially the printing
of malformed distinguished names.
- The size of an RSA public key received in a certificate is now restricted to
512 bits <= modulus length <= 8192 bits.
- Fixed the debug mode enumeration.
strongswan-2.1.3
----------------
- Fixed another PKCS#7 vulnerability which could lead to an
endless loop while following the X.509 trust chain.
strongswan-2.1.2
----------------
- Fixed the PKCS#7 vulnerability discovered by Thomas Walpuski
that accepted end certificates having identical issuer and subject
distinguished names in a multi-tier X.509 trust chain.
strongswan-2.1.1
----------------
- Removed all remaining references to ipsec_netlink.h in KLIPS.
strongswan-2.1.0
----------------
- The new "ca" section allows to define the following parameters:
ca kool
cacert=koolCA.pem # cacert of kool CA
ocspuri=http://ocsp.kool.net:8001 # ocsp server
ldapserver=ldap.kool.net # default ldap server
crluri=http://www.kool.net/kool.crl # crl distribution point
crluri2="ldap:///O=Kool, C= .." # crl distribution point #2
auto=add # add, ignore
The ca definitions can be monitored via the command
ipsec auto --listcainfos
- Fixed cosmetic corruption of /proc filesystem by integrating
D. Hugh Redelmeier's freeswan-2.06 kernel fixes.
strongswan-2.0.2
----------------
- Added support for the 818043 NAT-Traversal update of Microsoft's
Windows 2000/XP IPsec client which sends an ID_FQDN during Quick Mode.
- A symbolic link to libcrypto is now added in the kernel sources
during kernel compilation
- Fixed a couple of 64 bit issues (mostly casts to int).
Thanks to Ken Bantoft who checked my sources on a 64 bit platform.
- Replaced s[n]printf() statements in the kernel by ipsec_snprintf().
Credits go to D. Hugh Redelmeier, Michael Richardson, and Sam Sgro
of the FreeS/WAN team who solved this problem with the 2.4.25 kernel.
strongswan-2.0.1
----------------
- an empty ASN.1 SEQUENCE OF or SET OF object (e.g. a subjectAltName
certificate extension which contains no generalName item) can cause
a pluto crash. This bug has been fixed. Additionally the ASN.1 parser has
been hardened to make it more robust against malformed ASN.1 objects.
- applied Herbert Xu's NAT-T patches which fixes NAT-T under the native
Linux 2.6 IPsec stack.
strongswan-2.0.0
----------------
- based on freeswan-2.04, x509-1.5.3, nat-0.6c, alg-0.8.1rc12

340
COPYING Normal file
View File

@ -0,0 +1,340 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and "any
later version", you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation. If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission. For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, the commands you use may
be called something other than `show w' and `show c'; they could even be
mouse-clicks or menu items--whatever suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
Public License instead of this License.

110
CREDITS Normal file
View File

@ -0,0 +1,110 @@
We haven't kept proper track of everybody who has helped us, alas, but
here's a first attempt at acknowledgements...
Most of the FreeS/WAN software has been done by Richard Guy Briggs
(KLIPS), D. Hugh Redelmeier (Pluto), Michael Richardson (technical lead,
KLIPS, testing, etc.), Henry Spencer (past technical lead, scripts,
libraries, packaging, etc.), Sandy Harris (documentation), Claudia
Schmeing (support, documentation), and Sam Sgro (support, releases).
Peter Onion has collaborated extensively with RGB on PFKEY2 stuff. The
original version of our IPComp code came from Svenning Soerensen, who has
also contributed various bug fixes and improvements.
The first versions of KLIPS were done by John Ioannidis <ji@hol.gr>. The
first versions of Pluto (and further work on KLIPS) were done by Angelos
D. Keromytis <angelos@dsl.cis.upenn.edu>.
The MD2 implementation is from RSA Data Security Inc., so this package must
include the following phrase: "RSA Data Security, Inc. MD2 Message Digest
Algorithm" It is not under the GPL; see details in programs/pluto/md2.c.
The MD5 implementation is from RSA Data Security Inc., so this package must
include the following phrase: "derived from the RSA Data Security, Inc.
MD5 Message-Digest Algorithm". It is not under the GPL; see details in
linux/net/ipsec/ipsec_md5c.c.
The PKCS#11 header files in programs/pluto/rsaref/ are from RSA Security Inc.,
so they must include the following phrase: "RSA Security Inc. PKCS#11
Cryptographic Token Interface (Cryptoki)". The headers are not under the GPL;
see details in programs/pluto/rsaref/pkcs11.h.
The LIBDES library by Eric Young is used. It is not under the GPL -- see
details in libdes/COPYRIGHT -- although he has graciously waived the
advertising clause for FreeS/WAN use of LIBDES.
The SHA-1 code is derived from Steve Reid's; it is public domain.
Some bits of Linux code, notably drivers/net/new_tunnel.c and net/ipv4/ipip.c,
are used in heavily modified forms.
The radix-tree code from 4.4BSD is used in a modified form. It is not
under the GPL; see details in klips/net/ipsec/radij.c.
The lib/pfkeyv2.h header file contains public-domain material published in
RFC 2367.
Delete SA code and Notification messages were contributed by Mathieu Lafon.
He also implemented the vital NAT traversal support.
Peter Onion has been immensely helpful in finding portability bugs in
general, and in making FreeS/WAN work on the Alpha in particular. Rob
Hatfield likewise found and fixed some problems making it work on the
Netwinder.
John S. Denker of AT&T Shannon Labs has found a number of bugs the hard
way, has pointed out various problems (some of which we have fixed!) in
using the software in production applications, and has suggested some
substantial improvements to the documentation.
Marc Boucher <marc@mbsi.ca> did a quick-and-dirty port of KLIPS to the
Linux 2.2.x kernels, at a time when we needed it badly, and has helped
chase down 2.2.xx bugs and keep us current with 2.4.x development.
John Gilmore organized the FreeS/WAN project and continues to direct it.
Hugh Daniel handles day-to-day management, customer interface, and both
constructive and destructive testing. See the project's web page
<http://www.freeswan.org> for other contributors to this project and
related ones.
Herbert Xu ported the FreeS/WAN code to the native IPsec stack
of the Linux 2.6 kernel.
Kai Martius added initial support of OpenPGP certificates.
Andreas Steffen introduced the support of X.509 certificates in 2000
and has been both maintaining the X.509 code and adding extensions
to it ever since.
Andreas Hess, Patric Lichtsteiner, and Roger Wegmann implemented the
the initial X.509 certificate support, relying on Kai Martius's work.
Marco Bertossa and Andreas Schleiss implemented the verification of
the X.509 chain from the peer certificate up to the root CA.
Ueli Galizzi and Ariane Seiler did the original work on the support
of attribute certificates.
Martin Berner and Lukas Suter implemented the definition of group
attributes and dynamic fetching of attribute certificates.
Christoph Gysin and Simon Zwahlen implemented PKCS#15-based
smartcard suppport and contributed a fully operational OCSP client.
David Buechi and Michael Meier implemented the PKCS#11 smartcard
interface.
The support of port and protocol selectors was based on Stephen J.
Bevan's original work.
Stephane Laroche donated the original LDAP and HTTP fetching code
based on pthreads.
JuanJo Ciarlante introduced the modular support of alternative
encryption and authentication algorithms (AES, Serpent, twofish, etc).
The ipsec starter is based on Mathieu Lafon's original work.
Jan Hutter and Martin Willi developed the scepclient which fully
supports Cisco's Simple Certificate Enrollment Protocol (SCEP).
This file is RCSID $Id: CREDITS,v 1.6 2006/01/22 21:28:27 as Exp $

249
INSTALL Normal file
View File

@ -0,0 +1,249 @@
---------------------------
strongSwan - Installation
---------------------------
Contents
--------
1. Required packages
2. Optional packages
2.1 libcurl
2.2 OpenLDAP
2.3 PKCS#11 smartcard library modules
3. Building strongSwan with a Linux 2.4 kernel
4. Updating strongSwan with a Linux 2.4 kernel
5. Building strongSwan with a Linux 2.6 kernel
1. Required packages
-----------------
In order to be able to build strongSwan you'll need the GNU Multiprecision
Arithmetic Library (GMP) available from http://www.swox.com/gmp/.
The libgmp library and the corresponding header file gmp.h are usually
included in the form of one or two packages in the major Linux
distributions (SuSE: gmp; Debian unstable: libgmp3, libgmp3-dev).
2. Optional packages
-----------------
2.1 libcurl
-------
If you intend to dynamically fetch Certificate Revocation Lists (CRLs)
from an HTTP server or as an alternative want to use the Online
Certificate Status Protocol (OCSP) then you will need the libcurl library
available from http://curl.haxx.se/.
In order to keep the library as compact as possible for use with strongSwan
you can build libcurl from the sources with the optimized options
./configure --prefix=<dir> --without-ssl \
--disable-ldap --disable-telnet \
--disable-dict --disable-gopher \
--disable-debug \
--enable-nonblocking --enable-thread
As an alternative you can use the ready-made packages included with your
favorite Linux distribution (SuSE: curl, curl-devel).
In order to activate the use of the libcurl library in strongSwan you must
set the USE_LIBCURL option in "Makefile.inc":
# include libcurl support (CRL fetching, OCSP and SCEP)
USE_LIBCURL?=true
Under Gentoo emerge strongSwan with
USE="curl -ssl" emerge strongswan
2.2 OpenLDAP
--------
If you intend to dynamically fetch Certificate Revocation Lists (CRLs)
from an LDAP server then you will need the libldap library available
from http://www.openldap.org/.
OpenLDAP is usually included with your Linux distribution. You will need
both the run-time and development environments (SuSE: openldap2,
openldap2-devel).
In order to activate the use of the libldap library in strongSwan you must
set the USE_LDAP option in "Makefile.inc":
# include LDAP support (CRL fetching)
USE_LDAP?=true
Depending upon whether your LDAP server understands the V3 (preferred) or
V2 LDAP protocol, uncomment one ot the two following lines:
# Uncomment to enable dynamic CRL fetching using LDAP V3
LDAP_VERSION=3
# Uncomment to enable dynamic CRL fetching using LDAP V2
#LDAP_VERSION=2
The latest OpenLDAP releases use the LDAP V3 protocol, whereas older
versions require LDAP V2.
Under Gentoo emerge strongSwan with
USE="ldap -ssl" emerge strongswan
2.3 PKCS#11 smartcard library modules
---------------------------------
If you want to securely store your X.509 certificates and private RSA keys
on a smart card or a USB crypto token then you will need a PKCS #11 library
for the smart card of your choice. The OpenSC PKCS#11 library (use
versions >= 0.9.4) available from http://www.opensc.org/ supports quite a
selection of cards and tokens (e.g. Aladdin eToken Pro32k, Schlumberger
Cryptoflex e-gate, Oberthur AuthentIC, etc.) but requires that a PKCS#15
directory structure be present on the smart card. But in principle
any other PKCS#11 library could be used since the PKCS#11 API hides the
internal data representation on the card.
For USB crypto token support you must add the OpenCT driver library
(version >= 0.6.2) from the OpenSC site, whereas for serial smartcard
readers you'll need the pcsc-lite library and the matching driver from the
M.U.S.C.L.E project http://www.linuxnet.com/ .
In order to activate the PKCS#11-based smartcard support in strongSwan
you must set the USE_SMARTCARD option in "Makefile.inc":
#include PKCS11-based smartcard support
USE_SMARTCARD?=true
During compilation no externel smart card libraries must be present.
strongSwan directly references a copy of the standard RSAREF pkcs11.h
header files stored in the pluto/rsaref sub directory. During compile
time a pathname to a default PKCS#11 dynamical library can be specified
in "Makefile.inc"
# Uncomment this line if using OpenSC <= 0.9.6
PKCS11_DEFAULT_LIB=\"/usr/lib/pkcs11/opensc-pkcs11.so\"
# Uncomment tis line if using OpenSC >= 0.10.0
#PKCS11_DEFAULT_LIB=\"usr/lib/opensc-pkcs11.so\"
This default path to the easily-obtainable OpenSC library module can be
simply overridden during run-time by specifying an alternative path in
ipsec.conf pointing to any dynamic PKCS#11 library of your choice.
config setup
pkcs11module="/usr/lib/xyz-pkcs11.so"
Under Gentoo emerge strongSwan with
USE="smartcard usb -pam -X" emerge strongswan
3. Building strongSwan with a Linux 2.4 kernel
-------------------------------------------
* Building strongSwan with a Linux 2.4 kernel requires the presence of the
matching kernel sources referenced via the symbolic link /usr/src/linux.
The use of the vanilla kernel sources from ftp.kernel.org is strongly
recommended.
Before building strongSwan you must have compiled the kernel sources at
least once:
make menuconfig; make dep; make bzImage; make modules
* Now change into the strongswan-2.x.x source directory.
First uncomment any desired compile options in "programs/pluto/Makefile"
(see section 2. Optional packages).
Then in the top source directory type
make menumod
This command applies an ESP_IN_UDP encapsulation patch which is required
for NAT-Traversal to the kernel sources.
In the "Networking options" menu set
<M> IP Security Protocol (strongSwan IPsec)
in order to build KLIPS as a loadable kernel module "ipsec.o". Do not
forget to save the modified configuration file when leaving "menumod".
The strongSwan userland programs are now automatically built and
installed, whereas the ipsec.o kernel module and the crypto modules
are only built and must be installed with the command
make minstall
* If you intend to use the NAT-Traversal feature then you must compile the
patched kernel sources again by executing
make bzImage
and then install and boot the modified kernel.
* Next add your connections to "/etc/ipsec.conf" and start strongSwan with
ipsec setup start
4. Updating strongSwan with a Linux 2.4 kernel
-------------------------------------------
* If you have already successfully installed strongSwan and want to update
to a newer version then the following shortcut can be taken:
First uncomment any desired compile options in "programs/pluto/Makefile"
(see section 2. Optional packages).
Then in the strongwan-2.x.x top directory type
make programs; make install
followed by
make module; make minstall
* You can then start the updated strongSwan version with
ipsec setup restart
5. Building strongSwan with a Linux 2.6 kernel
-------------------------------------------
* Because the Linux 2.6 kernel comes with a built-in native IPsec stack,
you won't need to build the strongSwan kernel modules. Please make sure
that the the following Linux 2.6 IPsec kernel modules are available:
o af_key
o ah4
o esp4
o ipcomp
o xfrm_user
Also the built-in kernel Cryptoapi modules with selected encryption and
hash algorithms should be available.
* First uncomment any desired compile options in "programs/pluto/Makefile"
(see section 2. Optional packages).
Then in the strongwan-2.x.x top directory type
make programs
followed by
make install
* Next add your connections to "etc/ipsec.conf" and start strongSwan with
ipsec setup start
-----------------------------------------------------------------------------
This file is RCSID $Id: INSTALL,v 1.8 2006/01/22 16:22:23 as Exp $

33
LICENSE Normal file
View File

@ -0,0 +1,33 @@
Except for the DES library, MD2 and MD5 code, the PKCS#11 headers, and
linux/net/ipsec/radij.c this software is under the GNU Public License,
see the file COPYING.
See the file CREDITS for details on origins of more of the code.
The DES library is under a BSD style license, see
linux/crypto/ciphers/des/COPYRIGHT.
Note that this software has a advertising clause in it.
The MD2 implementation is from RSA Data Security Inc., so this package must
include the following phrase: "RSA Data Security, Inc. MD2 Message Digest
Algorithm" It is not under the GPL; see details in programs/pluto/md2.c.
The MD5 implementation is from RSA Data Security Inc., so this package must
include the following phrase: "derived from the RSA Data Security, Inc.
MD5 Message-Digest Algorithm". It is not under the GPL; see details in
linux/net/ipsec/ipsec_md5c.c.
The PKCS#11 header files in programs/pluto/rsaref/ are from RSA Security Inc.,
so they must include the following phrase: "RSA Security Inc. PKCS#11
Cryptographic Token Interface (Cryptoki)". The headers are not under the GPL;
see details in programs/pluto/rsaref/pkcs11.h.
The linux/net/ipsec/radij.c code is derived from BSD 4.4lite code
from sys/net/radix.c.
In addition to the terms set out under the GPL, permission is granted to
link the software against the libdes, md5c.c, and radij.c libraries just
mentioned.

602
Makefile Normal file
View File

@ -0,0 +1,602 @@
# FreeS/WAN master makefile
# Copyright (C) 1998-2002 Henry Spencer.
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
# Free Software Foundation; either version 2 of the License, or (at your
# option) any later version. See <http://www.fsf.org/copyleft/gpl.txt>.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
# for more details.
#
# RCSID $Id: Makefile,v 1.4 2004/11/14 21:50:59 as Exp $
FREESWANSRCDIR=$(shell pwd)
export FREESWANSRCDIR
include Makefile.inc
PATCHES=linux
# where KLIPS goes in the kernel
# note, some of the patches know the last part of this path
KERNELKLIPS=$(KERNELSRC)/net/ipsec
KERNELCRYPTODES=$(KERNELSRC)/crypto/ciphers/des
KERNELLIBFREESWAN=$(KERNELSRC)/lib/libfreeswan
KERNELLIBZLIB=$(KERNELSRC)/lib/zlib
KERNELLIBCRYPTO=$(KERNELSRC)/lib/libcrypto
KERNELINCLUDE=$(KERNELSRC)/include
KERNELALG=$(KERNELKLIPS)/alg
MAKEUTILS=packaging/utils
ERRCHECK=${MAKEUTILS}/errcheck
KVUTIL=${MAKEUTILS}/kernelversion
KVSHORTUTIL=${MAKEUTILS}/kernelversion-short
# kernel details
# what variant of our patches should we use, and where is it
KERNELREL=$(shell ${KVSHORTUTIL} ${KERNELSRC}/Makefile)
# directories visited by all recursion
SUBDIRS=doc lib programs linux
# declaration for make's benefit
.PHONY: def insert kpatch klink klibcryptolink patches _patches _patches2.2 _patches2.4 \
klipsdefaults programs install clean distclean \
ogo oldgo menugo xgo \
omod oldmod menumod xmod \
pcf ocf mcf xcf rcf nopromptgo \
precheck verset confcheck kernel module kinstall minstall \
backup unpatch uinstall install_file_list \
snapready relready ready buildready devready uml check taroldinstall \
umluserland
# dummy default rule
def:
@echo "Please read doc/intro.html or INSTALL before running make"
@false
# everything that's necessary to put Klips into the kernel
insert: patches klink klipsdefaults
kpatch: unapplypatch applypatch klipsdefaults
unapplypatch:
-if [ -f ${KERNELSRC}/freeswan.patch ]; then \
echo Undoing previous patches; \
cat ${KERNELSRC}/freeswan.patch | (cd ${KERNELSRC} && patch -p1 -R --force -E -z .preipsec --reverse --ignore-whitespace ); \
fi
applypatch:
echo Now performing forward patches;
make kernelpatch${KERNELREL} | tee ${KERNELSRC}/freeswan.patch | (cd ${KERNELSRC} && patch -p1 -b -z .preipsec --forward --ignore-whitespace )
kdiff:
echo Comparing ${KERNELSRC} to ${FREESWANSRCDIR}/linux.
packaging/utils/kerneldiff ${KERNELSRC}
# create KERNELKLIPS and populate it with symlinks to the sources
klink:
-[ -L $(KERNELKLIPS)/ipsec_init.c ] && rm -rf ${KERNELKLIPS}
-[ -L $(KERNELCRYPTODES)/cbc_enc.c ] && rm -rf ${KERNELCRYPTODES}
-[ -L $(KERNELLIBFREESWAN)/subnettoa.c ] && rm -rf ${KERNELLIBFREESWAN}
-[ -L ${KERNELLIBZLIB}/deflate.c ] && rm -rf ${KERNELLIBZLIB}
-[ -L ${KERNELINCLUDE}/freeswan.h ] && for i in linux/include/*; do rm -f ${KERNELINCLUDE}/$$i; done
-[ -L $(KERNELALG)/Makefile ] && rm -rf $(KERNELALG)
-[ -L $(KERNELLIBCRYPTO) ] && rm -f $(KERNELLIBCRYPTO)
mkdir -p $(KERNELKLIPS)
mkdir -p $(KERNELCRYPTODES)
mkdir -p $(KERNELLIBFREESWAN)
mkdir -p $(KERNELLIBZLIB)
mkdir -p $(KERNELALG)
$(KLIPSLINK) `pwd`/Makefile.ver $(KERNELKLIPS)
$(KLIPSLINK) `pwd`/linux/include/* $(KERNELINCLUDE)
$(KLIPSLINK) `pwd`/linux/net/ipsec/Makefile* $(KERNELKLIPS)
$(KLIPSLINK) `pwd`/linux/net/ipsec/Config.in $(KERNELKLIPS)
$(KLIPSLINK) `pwd`/linux/net/ipsec/defconfig $(KERNELKLIPS)
$(KLIPSLINK) `pwd`/linux/net/ipsec/*.[ch] $(KERNELKLIPS)
$(KLIPSLINK) `pwd`/linux/net/ipsec/alg/Makefile* $(KERNELALG)
$(KLIPSLINK) `pwd`/linux/net/ipsec/alg/Config.* $(KERNELALG)
$(KLIPSLINK) `pwd`/linux/net/ipsec/alg/ipsec_alg*.[ch] $(KERNELALG)
$(KLIPSLINK) `pwd`/linux/net/ipsec/alg/scripts $(KERNELALG)
# Each ALGo does it own symlinks
$(KLIPSLINK) `pwd`/lib/libcrypto $(KERNELLIBCRYPTO)
$(KLIPSLINK) `pwd`/linux/lib/zlib/*.[ch] $(KERNELLIBZLIB)
$(KLIPSLINK) `pwd`/linux/lib/zlib/Makefile* $(KERNELLIBZLIB)
$(KLIPSLINK) `pwd`/linux/lib/libfreeswan/*.[ch] $(KERNELLIBFREESWAN)
$(KLIPSLINK) `pwd`/linux/lib/libfreeswan/Makefile* $(KERNELLIBFREESWAN)
$(KLIPSLINK) `pwd`/linux/crypto/ciphers/des/*.[chsS] $(KERNELCRYPTODES)
$(KLIPSLINK) `pwd`/linux/crypto/ciphers/des/Makefile* $(KERNELCRYPTODES)
sed '/"/s/xxx/$(IPSECVERSION)/' linux/lib/libfreeswan/version.in.c >$(KERNELKLIPS)/version.c
# create libcrypto symlink
klibcryptolink:
-[ -L $(KERNELLIBCRYPTO) ] && rm -f $(KERNELLIBCRYPTO)
$(KLIPSLINK) `pwd`/lib/libcrypto $(KERNELLIBCRYPTO)
# patch kernel
PATCHER=packaging/utils/patcher
patches:
@echo \"make patches\" is obsolete. See \"make kpatch\".
exit 1
_patches:
echo "===============" >>out.kpatch
echo "`date` `cd $(KERNELSRC) ; pwd`" >>out.kpatch
$(MAKE) __patches$(KERNELREL) >>out.kpatch
# Linux-2.0.x version
__patches __patches2.0:
@$(PATCHER) -v $(KERNELSRC) Documentation/Configure.help \
'CONFIG_IPSEC' $(PATCHES)/Documentation/Configure.help.fs2_0.patch
@$(PATCHER) -v $(KERNELSRC) net/Config.in \
'CONFIG_IPSEC' $(PATCHES)/net/Config.in.fs2_0.patch
@$(PATCHER) -v $(KERNELSRC) net/Makefile \
'CONFIG_IPSEC' $(PATCHES)/net/Makefile.fs2_0.patch
@$(PATCHER) -v $(KERNELSRC) net/ipv4/af_inet.c \
'CONFIG_IPSEC' $(PATCHES)/net/ipv4/af_inet.c.fs2_0.patch
# Removed patches, will unpatch automatically.
@$(PATCHER) -v $(KERNELSRC) include/linux/proc_fs.h
@$(PATCHER) -v $(KERNELSRC) net/core/dev.c
@$(PATCHER) -v $(KERNELSRC) net/ipv4/protocol.c
@$(PATCHER) -v $(KERNELSRC) drivers/net/Space.c
@$(PATCHER) -v $(KERNELSRC) net/netlink.c
@$(PATCHER) -v $(KERNELSRC) drivers/isdn/isdn_net.c
# Linux-2.2.x version
PATCHES24=klips/patches2.3
__patches2.2:
@$(PATCHER) -v -c $(KERNELSRC) Documentation/Configure.help \
'CONFIG_IPSEC' $(PATCHES)/Documentation/Configure.help.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) net/Config.in \
'CONFIG_IPSEC' $(PATCHES)/net/Config.in.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) net/Makefile \
'CONFIG_IPSEC' $(PATCHES)/net/Makefile.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) net/ipv4/af_inet.c \
'CONFIG_IPSEC' $(PATCHES)/net/ipv4/af_inet.c.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) net/ipv4/udp.c \
'CONFIG_IPSEC' $(PATCHES)/net/ipv4/udp.c.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) include/net/sock.h \
'CONFIG_IPSEC' $(PATCHES)/net/include.net.sock.h.fs2_2.patch
# Removed patches, will unpatch automatically.
@$(PATCHER) -v $(KERNELSRC) include/linux/proc_fs.h
@$(PATCHER) -v $(KERNELSRC) net/core/dev.c
@$(PATCHER) -v $(KERNELSRC) net/ipv4/protocol.c
@$(PATCHER) -v $(KERNELSRC) drivers/net/Space.c
@$(PATCHER) -v $(KERNELSRC) include/linux/netlink.h
@$(PATCHER) -v $(KERNELSRC) net/netlink/af_netlink.c
@$(PATCHER) -v $(KERNELSRC) net/netlink/netlink_dev.c
@$(PATCHER) -v $(KERNELSRC) include/linux/socket.h
@$(PATCHER) -v $(KERNELSRC) drivers/isdn/isdn_net.c
# Linux-2.4.0 version
PATCHES22=klips/patches2.2
__patches2.3 __patches2.4:
@$(PATCHER) -v -c $(KERNELSRC) Documentation/Configure.help \
'CONFIG_IPSEC' $(PATCHES)/Documentation/Configure.help.fs2_2.patch
@$(PATCHER) -v $(KERNELSRC) net/Config.in \
'CONFIG_IPSEC' $(PATCHES)/net/Config.in.fs2_4.patch
@$(PATCHER) -v $(KERNELSRC) net/Makefile \
'CONFIG_IPSEC' $(PATCHES)/net/Makefile.fs2_4.patch
@$(PATCHER) -v $(KERNELSRC) net/ipv4/af_inet.c \
'CONFIG_IPSEC' $(PATCHES)/net/ipv4/af_inet.c.fs2_4.patch
@$(PATCHER) -v $(KERNELSRC) net/ipv4/udp.c \
'CONFIG_IPSEC' $(PATCHES)/net/ipv4/udp.c.fs2_4.patch
@$(PATCHER) -v $(KERNELSRC) include/net/sock.h \
'CONFIG_IPSEC' $(PATCHES)/net/include.net.sock.h.fs2_4.patch
# Removed patches, will unpatch automatically.
@$(PATCHER) -v $(KERNELSRC) include/linux/proc_fs.h
@$(PATCHER) -v $(KERNELSRC) net/core/dev.c
@$(PATCHER) -v $(KERNELSRC) net/ipv4/protocol.c
@$(PATCHER) -v $(KERNELSRC) drivers/net/Space.c
@$(PATCHER) -v $(KERNELSRC) include/linux/netlink.h
@$(PATCHER) -v $(KERNELSRC) net/netlink/af_netlink.c
@$(PATCHER) -v $(KERNELSRC) net/netlink/netlink_dev.c
@$(PATCHER) -v $(KERNELSRC) drivers/isdn/isdn_net.c
klipsdefaults:
@KERNELDEFCONFIG=$(KERNELSRC)/arch/$(ARCH)/defconfig ; \
KERNELCONFIG=$(KCFILE) ; \
if ! egrep -q 'CONFIG_IPSEC' $$KERNELDEFCONFIG ; \
then \
set -x ; \
cp -a $$KERNELDEFCONFIG $$KERNELDEFCONFIG.orig ; \
chmod u+w $$KERNELDEFCONFIG ; \
cat $$KERNELDEFCONFIG $(KERNELKLIPS)/defconfig \
>$$KERNELDEFCONFIG.tmp ; \
rm -f $$KERNELDEFCONFIG ; \
cp -a $$KERNELDEFCONFIG.tmp $$KERNELDEFCONFIG ; \
rm -f $$KERNELDEFCONFIG.tmp ; \
fi ; \
if ! egrep -q 'CONFIG_IPSEC' $$KERNELCONFIG ; \
then \
set -x ; \
cp -a $$KERNELCONFIG $$KERNELCONFIG.orig ; \
chmod u+w $$KERNELCONFIG ; \
cat $$KERNELCONFIG $(KERNELKLIPS)/defconfig \
>$$KERNELCONFIG.tmp ; \
rm -f $$KERNELCONFIG ; \
cp -a $$KERNELCONFIG.tmp $$KERNELCONFIG ; \
rm -f $$KERNELCONFIG.tmp ; \
fi
# programs
checkv199install:
if [ -f ${LIBDIR}/pluto ]; \
then \
echo WARNING: FreeS/WAN 1.99 still installed. ;\
echo WARNING: moving ${LIBDIR} to ${LIBDIR}.v1 ;\
mv ${LIBDIR} ${LIBDIR}.v1 ;\
fi
install:: checkv199install
programs install clean checkprograms::
@for d in $(SUBDIRS) ; \
do \
(cd $$d && $(MAKE) FREESWANSRCDIR=.. $@ ) || exit 1; \
done; \
clean::
rm -rf $(RPMTMPDIR) $(RPMDEST)
rm -f out.*build out.*install # but leave out.kpatch
rm -f rpm.spec
distclean: clean
rm -f out.kpatch
if [ -f umlsetup.sh ]; then source umlsetup.sh; if [ -d "$$POOLSPACE" ]; then rm -rf $$POOLSPACE; fi; fi
# proxies for major kernel make operations
# do-everything entries
KINSERT_PRE=precheck verset insert
PRE=precheck verset kpatch klibcryptolink
POST=confcheck programs kernel install
MPOST=confcheck programs module install
ogo: $(PRE) pcf $(POST)
oldgo: $(PRE) ocf $(POST)
nopromptgo: $(PRE) rcf $(POST)
menugo: $(PRE) mcf $(POST)
xgo: $(PRE) xcf $(POST)
omod: $(PRE) pcf $(MPOST)
oldmod: $(PRE) ocf $(MPOST)
menumod: $(PRE) mcf $(MPOST)
xmod: $(PRE) xcf $(MPOST)
# preliminaries
precheck:
@if test ! -d $(KERNELSRC) -a ! -L $(KERNELSRC) ; \
then \
echo '*** cannot find directory "$(KERNELSRC)"!!' ; \
echo '*** may be necessary to add symlink to kernel source' ; \
exit 1 ; \
fi
@if ! cd $(KERNELSRC) ; \
then \
echo '*** cannot "cd $(KERNELSRC)"!!' ; \
echo '*** may be necessary to add symlink to kernel source' ; \
exit 1 ; \
fi
@if test ! -f $(KCFILE) ; \
then \
echo '*** cannot find "$(KCFILE)"!!' ; \
echo '*** perhaps kernel has never been configured?' ; \
echo '*** please do that first; the results are necessary.' ; \
exit 1 ; \
fi
@if test ! -f $(VERFILE) ; \
then \
echo '*** cannot find "$(VERFILE)"!!' ; \
echo '*** perhaps kernel has never been compiled?' ; \
echo '*** please do that first; the results are necessary.' ; \
exit 1 ; \
fi
# set version code if this is a fresh CVS checkout
ifeq ($(wildcard cvs.datemark),cvs.datemark)
verset Makefile.ver: cvs.datemark
echo IPSECVERSION=`date -r cvs.datemark +cvs%Y%b%d_%H:%M:%S` >Makefile.ver
rm -f cvs.datemark;
else
verset Makefile.ver:
@grep IPSECVERSION Makefile.ver
endif
Makefile: Makefile.ver
# configuring (exit statuses disregarded, something fishy here sometimes)
xcf:
-cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) xconfig
mcf:
-cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) menuconfig
pcf:
-cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) config
ocf:
-cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) oldconfig
rcf:
cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) oldconfig_nonint </dev/null
cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) dep >/dev/null
confcheck:
@if test ! -f $(KCFILE) ; \
then echo '*** no kernel configuration file written!!' ; exit 1 ; \
fi
@if ! egrep -q '^CONFIG_IPSEC=[my]' $(KCFILE) ; \
then echo '*** IPsec not in kernel config ($(KCFILE))!!' ; exit 1 ; \
fi
@if ! egrep -q 'CONFIG_IPSEC[ ]+1' $(ACFILE) && \
! egrep -q 'CONFIG_IPSEC_MODULE[ ]+1' $(ACFILE) ; \
then echo '*** IPsec in kernel config ($(KCFILE)),' ; \
echo '*** but not in config header file ($(ACFILE))!!' ; \
exit 1 ; \
fi
@if egrep -q '^CONFIG_IPSEC=m' $(KCFILE) && \
! egrep -q '^CONFIG_MODULES=y' $(KCFILE) ; \
then echo '*** IPsec configured as module in kernel with no module support!!' ; exit 1 ; \
fi
@if ! egrep -q 'CONFIG_IPSEC_AH[ ]+1' $(ACFILE) && \
! egrep -q 'CONFIG_IPSEC_ESP[ ]+1' $(ACFILE) ; \
then echo '*** IPsec configuration must include AH or ESP!!' ; exit 1 ; \
fi
# kernel building, with error checks
kernel:
rm -f out.kbuild out.kinstall
# undocumented kernel folklore: clean BEFORE dep.
# we run make dep seperately, because there is no point in running ERRCHECK
# on the make dep output.
# see LKML thread "clean before or after dep?"
( cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) $(KERNCLEAN) $(KERNDEP) )
( cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) $(KERNEL) ) 2>&1 | tee out.kbuild
@if egrep -q '^CONFIG_MODULES=y' $(KCFILE) ; \
then set -x ; \
( cd $(KERNELSRC) ; \
$(MAKE) $(KERNMAKEOPTS) modules 2>&1 ) | tee -a out.kbuild ; \
fi
${ERRCHECK} out.kbuild
# this target takes a kernel source tree and it builds a link tree,
# and then does make oldconfig for each .config file that was found in configs.
# The location for the disk space required for the link tree is found via
# $RH_KERNELSRC_POOL
preprhkern4module:
if [ -z "${RH_KERNELSRC_POOL}" ]; then echo Please set RH_KERNELSRC_POOL.; exit 1; fi
mkdir -p ${RH_KERNELSRC_POOL}
KV=`${KVUTIL} $(RH_KERNELSRC)/Makefile` ; \
cd ${RH_KERNELSRC_POOL} && \
mkdir -p $$KV && cd $$KV && \
for config in ${RH_KERNELSRC}/configs/*; do \
basecfg=`basename $$config` ;\
mkdir -p ${RH_KERNELSRC_POOL}/$$KV/$$basecfg && \
cd ${RH_KERNELSRC_POOL}/$$KV/$$basecfg && \
lndir ${RH_KERNELSRC} . && \
rm -rf include/asm && \
(cd include/linux && sed -e '/#include "\/boot\/kernel.h"/d' <rhconfig.h >rhconfig.h-new && mv rhconfig.h-new rhconfig.h ) && \
rm -f include/linux/modules/*.stamp && \
make dep && \
make oldconfig; \
done;
# module-only building, with error checks
ifneq ($(strip $(MODBUILDDIR)),)
${MODBUILDDIR}/Makefile : ${FREESWANSRCDIR}/packaging/makefiles/module.make
mkdir -p ${MODBUILDDIR}
cp ${FREESWANSRCDIR}/packaging/makefiles/module.make ${MODBUILDDIR}/Makefile
echo "# " >>${MODBUILDDIR}/Makefile
echo "# Local Variables: " >>${MODBUILDDIR}/Makefile
echo "# compile-command: \"${MAKE} FREESWANSRCDIR=${FREESWANSRCDIR} ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} ipsec.o\"" >>${MODBUILDDIR}/Makefile
echo "# End: " >>${MODBUILDDIR}/Makefile
# clean out the linux/net/ipsec directory so that VPATH will work properly
module: ${MODBUILDDIR}/Makefile
${MAKE} -C linux/net/ipsec ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} clean
${MAKE} -C ${MODBUILDDIR} ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} ipsec.o
${MAKE} -C ${MODBUILDDIR} ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} LIBCRYPTO=${FREESWANSRCDIR}/lib/libcrypto MODULE_FLAGS="$(MODULE_FLAGS)" alg_modules
modclean: ${MODBUILDDIR}/Makefile
${MAKE} -C ${MODBUILDDIR} clean
# module-only install, with error checks
minstall:
( FSMODLIB=`make -C $(KERNELSRC) -p dummy | ( sed -n -e '/^MODLIB/p' -e '/^MODLIB/q' ; cat > /dev/null ) | sed -e 's/^MODLIB[ :=]*\([^;]*\).*/\1/'` ; \
if [ -z "$$FSMODLIB" ] ; then \
FSMODLIB=`make -C $(KERNELSRC) -n -p modules_install | ( sed -n -e '/^MODLIB/p' -e '/^MODLIB/q' ; cat > /dev/null ) | sed -e 's/^MODLIB[ :=]*\([^;]*\).*/\1/'` ; \
fi ; \
if [ -z "$$FSMODLIB" ] ; then \
echo "No known place to install module. Aborting." ; \
exit 93 ; \
fi ; \
set -x ; \
mkdir -p $$FSMODLIB/kernel/net/ipsec ; \
cp $(MODBUILDDIR)/ipsec.o $$FSMODLIB/kernel/net/ipsec ; \
mkdir -p $$FSMODLIB/kernel/net/ipsec/alg ; \
for i in `sed -n '/IPSEC_ALG/s/CONFIG_IPSEC_ALG_\(.*\)=[Mm]/ipsec_\1.o/p' $(KCFILE) | tr '[A-Z]' '[a-z]'`;do \
echo "installing $$i"; \
cp $(MODBUILDDIR)/alg/$$i $$FSMODLIB/kernel/net/ipsec/alg ;\
done )
else
module:
${MAKE} -C linux/net/ipsec ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} ipsec.o
${MAKE} -C linux/net/ipsec ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} LIBCRYPTO=${FREESWANSRCDIR}/lib/libcrypto MODULE_FLAGS="$(MODULE_FLAGS)" alg_modules
modclean:
${MAKE} -C linux/net/ipsec ARCH=${ARCH} ${MODULE_FLAGS} MODULE_DEF_INCLUDE=${MODULE_DEF_INCLUDE} clean
# module-only install, with error checks
minstall:
( FSMODLIB=`make -C $(KERNELSRC) -p dummy | ( sed -n -e '/^MODLIB/p' -e '/^MODLIB/q' ; cat > /dev/null ) | sed -e 's/^MODLIB[ :=]*\([^;]*\).*/\1/'` ; \
if [ -z "$$FSMODLIB" ] ; then \
FSMODLIB=`make -C $(KERNELSRC) -n -p modules_install | ( sed -n -e '/^MODLIB/p' -e '/^MODLIB/q' ; cat > /dev/null ) | sed -e 's/^MODLIB[ :=]*\([^;]*\).*/\1/'` ; \
fi ; \
if [ -z "$$FSMODLIB" ] ; then \
echo "No known place to install module. Aborting." ; \
exit 93 ; \
fi ; \
set -x ; \
mkdir -p $$FSMODLIB/kernel/net/ipsec ; \
cp linux/net/ipsec/ipsec.o $$FSMODLIB/kernel/net/ipsec ; \
mkdir -p $$FSMODLIB/kernel/net/ipsec/alg ; \
for i in `sed -n '/IPSEC_ALG/s/CONFIG_IPSEC_ALG_\(.*\)=[Mm]/ipsec_\1.o/p' $(KCFILE) | tr '[A-Z]' '[a-z]'`;do \
echo "installing $$i"; \
cp linux/net/ipsec/alg/$$i $$FSMODLIB/kernel/net/ipsec/alg ;\
done )
endif
# kernel install, with error checks
kinstall:
rm -f out.kinstall
>out.kinstall
# undocumented kernel folklore: modules_install must precede install (observed on RHL8.0)
@if egrep -q '^CONFIG_MODULES=y' $(KCFILE) ; \
then set -x ; \
( cd $(KERNELSRC) ; \
$(MAKE) $(KERNMAKEOPTS) modules_install 2>&1 ) | tee -a out.kinstall ; \
fi
( cd $(KERNELSRC) ; $(MAKE) $(KERNMAKEOPTS) install ) 2>&1 | tee -a out.kinstall
${ERRCHECK} out.kinstall
kernelpatch2.5:
packaging/utils/kernelpatch 2.5
kernelpatch2.4 kernelpatch:
packaging/utils/kernelpatch 2.4
kernelpatch2.2:
packaging/utils/kernelpatch 2.2
kernelpatch2.0:
packaging/utils/kernelpatch 2.0
install_file_list:
@for d in $(SUBDIRS) ; \
do \
(cd $$d && $(MAKE) --no-print-directory FREESWANSRCDIR=.. install_file_list ) || exit 1; \
done;
# take all the patches out of the kernel
# (Note, a couple of files are modified by non-patch means; they are
# included in "make backup".)
unpatch:
@echo \"make unpatch\" is obsolete. See make unapplypatch.
exit 1
_unpatch:
for f in `find $(KERNELSRC)/. -name '*.preipsec' -print` ; \
do \
echo "restoring $$f:" ; \
dir=`dirname $$f` ; \
core=`basename $$f .preipsec` ; \
cd $$dir ; \
mv -f $$core.preipsec $$core ; \
rm -f $$core.wipsec $$core.ipsecmd5 ; \
done
# uninstall, as much as possible
uninstall:
$(MAKE) --no-print-directory install_file_list | egrep -v '(/ipsec.conf$$|/ipsec.d/)' | xargs rm -f
taroldinstall:
tar --ignore-failed-read -c -z -f oldFreeSWAN.tar.gz `$(MAKE) --no-print-directory install_file_list`
# some oddities meant for the developers, probably of no use to users
# make tags and TAGS files from ctags and etags for vi and emacs, respectively.
tags TAGS: dummy
etags `find lib programs linux -name '*.[ch]'`
ctags `find lib programs linux -name '*.[ch]'`
dummy:
# at the moment there is no difference between snapshot and release build
snapready: buildready
relready: buildready
ready: devready
# set up for build
buildready:
rm -f dtrmakefile cvs.datemark
cd doc ; $(MAKE) -s
uml: programs checkprograms
@echo XXX do some checks to see if all the manual pieces are done.
-chmod +x testing/utils/make-uml.sh
testing/utils/make-uml.sh `pwd`
umluserland:
(touch Makefile.inc && source umlsetup.sh && cd $$POOLSPACE && make $$FREESWANHOSTS $$REGULARHOSTS )
# DESTDIR is normally set in Makefile.inc
# These recipes explicitly pass it to the second-level makes so that
# DESTDIR can be adjusted for building for UML without changing Makefile.inc
# See testing/utils/functions.sh
# testing/utils/make-uml.sh
# testing/utils/uml-functions.sh
check: uml Makefile.ver
ifneq ($(strip(${REGRESSRESULTS})),)
mkdir -p ${REGRESSRESULTS}
endif
@for d in $(SUBDIRS); do (cd $$d && $(MAKE) DESTDIR=${DESTDIR} checkprograms || exit 1); done
@for d in $(SUBDIRS); \
do \
echo ===================================; \
echo Now making check in $$d; \
echo ===================================; \
(cd $$d && $(MAKE) DESTDIR=${DESTDIR} check || exit 1);\
done
ifneq ($(strip(${REGRESSRESULTS})),)
-perl testing/utils/regress-summarize-results.pl ${REGRESSRESULTS}
endif
rpm:
@echo please cd packaging/redhat and
@echo run "make RH_KERNELSRC=/some/path/to/kernel/src rpm"
ipkg_strip:
@echo "Minimizing size for ipkg binaries..."
@cd $(DESTDIR)$(INC_USRLOCAL)/lib/ipsec && \
for f in *; do (if file $$f | grep ARM > /dev/null; then ( $(STRIP) --strip-unneeded $$f); fi); done
@rm -r $(DESTDIR)$(INC_USRLOCAL)/man
@rm -f $(DESTDIR)$(INC_RCDEFAULT)/*.old
@rm -f $(DESTDIR)$(INC_USRLOCAL)/lib/ipsec/*.old
@rm -f $(DESTDIR)$(INC_USRLOCAL)/libexec/ipsec/*.old
@rm -f $(DESTDIR)$(INC_USRLOCAL)/sbin/*.old
ipkg_module:
@echo "Moving ipsec.o into temporary location..."
KV=$(shell ${KVUTIL} ${KERNELSRC}/Makefile) && \
mkdir -p $(FREESWANSRCDIR)/packaging/ipkg/kernel-module/lib/modules/$$KV/net/ipsec
KV=$(shell ${KVUTIL} ${KERNELSRC}/Makefile) && \
cp linux/net/ipsec/ipsec.o $(FREESWANSRCDIR)/packaging/ipkg/kernel-module/lib/modules/$$KV/net/ipsec/
KV=$(shell ${KVUTIL} ${KERNELSRC}/Makefile)
ipkg_clean:
rm -rf $(FREESWANSRCDIR)/packaging/ipkg/kernel-module/
rm -rf $(FREESWANSRCDIR)/packaging/ipkg/ipkg/
rm -f $(FREESWANSRCDIR)/packaging/ipkg/control-freeswan
rm -f $(FREESWANSRCDIR)/packaging/ipkg/control-freeswan-module
ipkg: programs install ipkg_strip ipkg_module
@echo "Generating ipkg...";
DESTDIR=${DESTDIR} FREESWANSRCDIR=${FREESWANSRCDIR} ARCH=${ARCH} IPSECVERSION=${IPSECVERSION} ./packaging/ipkg/generate-ipkg

331
Makefile.inc Normal file
View File

@ -0,0 +1,331 @@
# FreeS/WAN pathnames and other master configuration
# Copyright (C) 2001, 2002 Henry Spencer.
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
# Free Software Foundation; either version 2 of the License, or (at your
# option) any later version. See <http://www.fsf.org/copyleft/gpl.txt>.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
# for more details.
#
# RCSID $Id: Makefile.inc,v 1.12 2006/01/25 17:23:15 as Exp $
# Variables in this file with names starting with INC_ are not for use
# by Makefiles which include it; they are subject to change without warning.
#
# "Final" and "finally" refer to where the files will end up on the
# running IPsec system, as opposed to where they get installed by our
# Makefiles. (The two are different for cross-compiles and the like,
# where our Makefiles are not the end of the installation process.)
# Paths with FINAL in their names are the only ones that the installed
# software itself depends on. (Very few things should know about the
# FINAL paths; think twice and consult Henry before making something new
# depend on them.) All other paths are install targets.
# See also DESTDIR, below.
### boilerplate, do not change
SHELL=/bin/sh
### paths within the source tree
KLIPSINC=${FREESWANSRCDIR}/linux/include
KLIPSSRC=${FREESWANSRCDIR}/linux/net/ipsec
LIBFREESWANDIR=${FREESWANSRCDIR}/linux/lib/libfreeswan
FREESWANLIB=${FREESWANSRCDIR}/lib/libfreeswan/libfreeswan.a
LWRESDIR=${FREESWANSRCDIR}/lib/liblwres
LWRESLIB=${LWRESDIR}/liblwres.a
LIBDESSRCDIR=${FREESWANSRCDIR}/linux/crypto/ciphers/des
LIBDESLITE=${FREESWANSRCDIR}/lib/libdes/libdes.a
LIBPOLICYDIR=${FREESWANSRCDIR}/linux/lib/libipsecpolicy
POLICYLIB=${FREESWANSRCDIR}/lib/libipsecpolicy/libipsecpolicy.a
.PHONY: programs checkprograms clean
### install pathnames
# DESTDIR can be used to supply a prefix to all install targets.
# (Note that "final" pathnames, signifying where files will eventually
# reside rather than where install puts them, are exempt from this.)
# The prefixing is done in this file, so as to have central control over
# it; DESTDIR itself should never appear in any other Makefile.
DESTDIR?=
# "local" part of tree, used in building other pathnames
INC_USRLOCAL=/usr/local
# PUBDIR is where the "ipsec" command goes; beware, many things define PATH
# settings which are assumed to include it (or at least, to include *some*
# copy of the "ipsec" command).
PUBDIR=$(DESTDIR)$(INC_USRLOCAL)/sbin
# BINDIR is where sub-commands get put, FINALBINDIR is where the "ipsec"
# command will look for them when it is run. Also called LIBEXECDIR.
FINALLIBEXECDIR=$(INC_USRLOCAL)/libexec/ipsec
LIBEXECDIR=$(DESTDIR)$(FINALBINDIR)
FINALBINDIR=${FINALLIBEXECDIR}
BINDIR=${LIBEXECDIR}
# SBINDIR is where the user interface command goes.
FINALSBINDIR=$(INC_USRLOCAL)/sbin
SBINDIR=$(DESTDIR)$(FINALSBINDIR)
# libdir is where utility files go
FINALLIBDIR=$(INC_USRLOCAL)/lib/ipsec
LIBDIR=$(DESTDIR)$(FINALLIBDIR)
# where the appropriate manpage tree is located
# location within INC_USRLOCAL
INC_MANDIR=man
# the full pathname
MANTREE=$(DESTDIR)$(INC_USRLOCAL)/$(INC_MANDIR)
# all relevant subdirectories of MANTREE
MANPLACES=man3 man5 man8
# where configuration files go
FINALCONFFILE?=/etc/ipsec.conf
CONFFILE=$(DESTDIR)$(FINALCONFFILE)
FINALCONFDIR?=/etc
CONFDIR=$(DESTDIR)$(FINALCONFDIR)
FINALCONFDDIR?=${FINALCONFDIR}/ipsec.d
CONFDDIR=$(DESTDIR)$(FINALCONFDDIR)
# sample configuration files go into
INC_DOCDIR?=share/doc
FINALEXAMPLECONFDIR=${INC_USRLOCAL}/${INC_DOCDIR}/strongswan
EXAMPLECONFDIR=${DESTDIR}${FINALEXAMPLECONFDIR}
FINALDOCDIR?=${INC_USRLOCAL}/${INC_DOCDIR}/strongswan
DOCDIR=${DESTDIR}${FINALDOCDIR}
# where per-conn pluto logs go
VARDIR?=/var
LOGDIR?=${VARDIR}/log
FINALLOGDIR?=${DESTDIR}${LOGDIR}
# An attempt is made to automatically figure out where boot/shutdown scripts
# will finally go: the first directory in INC_RCDIRS which exists gets them.
# If none of those exists (or INC_RCDIRS is empty), INC_RCDEFAULT gets them.
# With a non-null DESTDIR, INC_RCDEFAULT will be used unless one of the
# INC_RCDIRS directories has been pre-created under DESTDIR.
INC_RCDIRS=/etc/rc.d/init.d /etc/rc.d /etc/init.d /sbin/init.d
INC_RCDEFAULT=/etc/rc.d/init.d
# RCDIR is where boot/shutdown scripts go; FINALRCDIR is where they think
# will finally be (so utils/Makefile can create a symlink in BINDIR to the
# place where the boot/shutdown script will finally be, rather than the
# place where it is installed).
FINALRCDIR=$(shell for d in $(INC_RCDIRS) ; \
do if test -d $(DESTDIR)/$$d ; \
then echo $$d ; exit 0 ; \
fi ; done ; echo $(INC_RCDEFAULT) )
RCDIR=$(DESTDIR)$(FINALRCDIR)
### kernel pathnames
# Kernel location: where patches are inserted, where kernel builds are done.
# this is a hack using the wildcard to look for existence of a file/dir
ifneq ($(wildcard /usr/src/linux-2.4),)
KERNELSRC?=/usr/src/linux-2.4
else
KERNELSRC?=/usr/src/linux
endif
# where kernel configuration outputs are located
KCFILE=$(KERNELSRC)/.config
ACFILE=$(KERNELSRC)/include/linux/autoconf.h
VERFILE=$(KERNELSRC)/include/linux/version.h
### misc installation stuff
# what program to use when installing things
INSTALL=install
# flags to the install program, for programs, manpages, and config files
# -b has install make backups (n.b., unlinks original), --suffix controls
# how backup names are composed.
# Note that the install procedures will never overwrite an existing config
# file, which is why -b is not specified for them.
INSTBINFLAGS=-b --suffix=.old
INSTMANFLAGS=
INSTCONFFLAGS=
### misc configuration, included here in hopes that other files will not
### have to be changed for common customizations.
# extra compile flags, for userland and kernel stuff, e.g. -g for debug info
# (caution, this stuff is still being sorted out, will change in future)
USERCOMPILE?=-g -O3
KLIPSCOMPILE=-O3
# command used to link/copy KLIPS into kernel source tree
# There are good reasons why this is "ln -s"; only people like distribution
# builders should ever change it.
KLIPSLINK=ln -s -f
# extra options for use in kernel build
KERNMAKEOPTS=
# kernel Makefile targets to be done before build
# Can be overridden if you are *sure* your kernel doesn't need them. (2.2.xx
# and later reportedly do not.)
KERNDEP=dep
KERNCLEAN=clean
# kernel make name: zImage for 2.0.xx, bzImage for 2.2.xx and later, and
# boot on non-x86s (what ever happened to standards?)
INC_B=$(shell test -d $(DIRIN22) && echo b)
KERNEL=$(shell if expr " `uname -m`" : ' i.86' >/dev/null ; \
then echo $(INC_B)zImage ; \
else echo boot ; \
fi)
# temporary directory to be used when building RPMs, and where to put the
# resulting RPM tree
RPMKERNDIR := $(shell echo `pwd`/tmp.rpmkernel)
RPMTMPDIR := $(shell echo `pwd`/tmp.rpmbuild)
RPMDEST := $(shell echo `pwd`/rpms)
# Newer versions of RPM do not permit building of packages with the "rpm"
# command. For RedHat systems with older version of RPM, use:
# RPMBUILD=rpm
# instead.
RPMBUILD=rpmbuild
### paths to resources on the host system
#
# Set this to a RedHat kernel-sources RPM. This normally extracts into
# /usr/src/linux-2.4, but you might have extracted it elsewhere with
# rpm2cpio.
#
RH_KERNELSRC?=/usr/src/linux-2.4
## build environment variations
##
# set this to a place where you have installed a bind9.3
# snapshot (20021115 or better). A bind 9.2, particularly a RedHat
# installed one in RH 7.2, won't work - you wind up depending upon
# openssl.
BIND9STATICLIBDIR?=/usr/local/lib
# FreeSWAN 3.x will require bind9.
USE_LWRES?=false
# whether or not to use iproute2 based commands.
#
USE_IPROUTE2?=true
# what kind of firewalling to use:
# 2.0 - ipfwadm
# 2.2 - ipchains
# 2.4 - iptables
IPSEC_FIREWALLTYPE=iptables
# whether or not to include ipsec policy code into pluto.
# false for now, since it is still experimental.
USE_IPSECPOLICY?=false
# include IKEPING in the distribution
USE_IKEPING?=false
# include support for KEY RR
# this will become false in late 2003.
USE_KEYRR?=true
# include support for KERNEL 2.5/2.6 IPsec in pluto
USE_KERNEL26?=true
# whether or not pluto sends its strongSwan Vendor ID
USE_VENDORID?=true
# whether or not pluto sends an XAUTH VID (Cisco Mode Config Interoperability)
USE_XAUTH_VID?=false
# whether to support NAT Traversal (aka NAT-T)
USE_NAT_TRAVERSAL?=true
# whether to support NAT-T in transport mode (needed for Win2K NAT-T Interop)
USE_NAT_TRAVERSAL_TRANSPORT_MODE?=false
# include libcurl support (currently used for fetching CRLs, OCSP and SCEP)
USE_LIBCURL?=false
# include LDAP support (currently used for fetching CRLs)
USE_LDAP?=false
# uncomment this line if using the LDAPv3 protocol
LDAP_VERSION=3
# uncomment this line if using the LDAPv2 protocol
#LDAP_VERSION=2
# include PKCS11-based smartcard support
USE_SMARTCARD?=false
# Default PKCS11 library
# Uncomment this line if using OpenSC <= 0.9.6
PKCS11_DEFAULT_LIB=\"/usr/lib/pkcs11/opensc-pkcs11.so\"
# Uncomment this line if using OpenSC >= 0.10.0
#PKCS11_DEFAULT_LIB=\"/usr/lib/opensc-pkcs11.so\"
# Uncomment and complete this line if using another default library
#PKCS11_DEFAULT_LIB=\"/usr/lib/...\"
# Enable the leak detective to find memory leaks
USE_LEAK_DETECTIVE?=false
# set this to space where a linked/configured tree can be created by
# preprhkern4module. Only needed if you are going to be created RPMs
# outside of a distribution (as the FS team does for RedHat).
#RH_KERNELSRC_POOL=/c2/freeswan/rh_kern
# the following is a list of symbols which will be used to construct
# the module goo to identify which module goes with each kernel.
MODULE_GOO_LIST=irq_stat netif_rx register_sysctl_table send_sig
MODULE_GOO_LIST+=kmalloc __kfree_skb __ip_select_ident alloc_skb
MODULE_GOO_LIST+=icmp_send ip_fragment sock_register
MODULE_DEF_INCLUDE=${FREESWANSRCDIR}/packaging/linus/config-all.h
MODULE_DEFCONFIG?=${KLIPSSRC}/defconfig
MODULE_FLAGS:=KLIPSMODULE=true TOPDIR=${KERNELSRC} -f ${MODULE_DEFCONFIG} -f Makefile
# supply kernel-configuration ARCH defaults
ifeq ($(ARCH),)
ARCH := $(shell uname -m)
endif
# always sanitize $(ARCH)
ARCH := $(shell echo $(ARCH) | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ -e s/arm.*/arm/ -e s/sa110/arm/)
# export everything so that scripts can use them.
export LIBFREESWANDIR FREESWANSRCDIR FREESWANLIB
-include ${FREESWANSRCDIR}/Makefile.ver
# for emacs
#
# Local Variables: ;;;
# mode: makefile ;;;
# End Variables: ;;;
#

1
Makefile.ver Normal file
View File

@ -0,0 +1 @@
IPSECVERSION=2.7.0

3091
README Normal file
View File

File diff suppressed because it is too large Load Diff

66
doc/.cvsignore Normal file
View File

@ -0,0 +1,66 @@
HowTo.html
HowTo.html
adv_config.html
adv_config.html
background.html
background.html
biblio.html
biblio.html
compat.html
compat.html
config.html
config.html
draft-richardson-ipsec-opportunistic.nr
draft-richardson-ipsec-rr.nr
draft-richardson-ipsec-rr.txt
faq.html
faq.html
firewall.html
firewall.html
glossary.html
glossary.html
index.html
index.html
install.html
install.html
interop.html
interop.html
intro.html
intro.html
ipsec.html
ipsec.html
kernel.html
kernel.html
mail.html
mail.html
makecheck.html
manpage.d
manpage.d
manpages.html
manpages.html
multi_netjig.png
nightly.html
performance.html
performance.html
policygroups.html
politics.html
politics.html
quickstart.html
rfc.html
rfc.html
rfc_pg
roadmap.html
roadmap.html
single_netjig.png
testing.html
testing.html
toc.html
toc.html
trouble.html
trouble.html
umltesting.html
upgrading.html
user_examples.html
user_examples.html
web.html
web.html

112
doc/2.6.known-issues Normal file
View File

@ -0,0 +1,112 @@
Known issues with FreeS/WAN on a 2.6 kernel Claudia Schmeing
-------------------------------------------
This is an overview of known issues with FreeS/WAN on the 2.6 kernel codebase
(also 2.5.x), which includes native Linux IPsec code.
More information on the native IPsec code is available here:
http://lartc.org/howto/lartc.ipsec.html
Tools for use with that code are here:
http://ipsec-tools.sourceforge.net/
* As of FreeS/WAN 2.03, FreeS/WAN ships with some support for the 2.6 kernel
IPsec code. In 2.03, this support is preliminary, but we expect to develop
it fully. Many thanks to Herbert Xu for the initial code patches.
* Use the most recent Linux FreeS/WAN 2.x release from ftp.xs4all.nl
to try our 2.6 kernel support.
* The installation procedure for use with 2.6 kernel IPsec is a little
different from a traditional FreeS/WAN installation. Please see
the latest doc/install.html.
* Please see the design and users' mailing lists
(http://www.freeswan.org/mail.html) for more detail and the latest reports.
DESIGN-RELATED ISSUES
* In 2.6, IPsec policies are detached from routing decisions. Because of this
design, Opportunistic Encryption on the local LAN will be possible with 2.6.
One side effect: When contacting a node on the local LAN which is protected
by gateway OE, you will get asymmetrical routing (one way through the gateway,
one way direct), and IPsec will drop the return packets.
CURRENT ISSUES
* For the moment, users wishing to test FreeS/WAN with 2.6 will require
ipsec-tools' "setkey" program. Though FreeS/WAN's keying daemon, Pluto,
directly sets IPsec policy, setkey is currently required to reset kernel SPD
(Security Policy Database) states when Pluto restarts. We will likely add
this basic functionality to an upcoming FreeS/WAN release.
* State information is not available to the user, eg. ipsec
eroute/ipsec spi/ipsec look do not work. The exception: ipsec auto --status
This will be fixed in a future release.
* If you're running Opportunistic Encryption, connectivity to new hosts will
immediately fail. You may receive a message similar to this:
connect: Resource temporarily unavailable
The reason for this lies in the kernel code. Fairly complex discussion:
http://lists.freeswan.org/archives/design/2003-September/msg00073.html
As of 2.6.0-test6, this has not been fixed.
* This initial connectivity failure has an unintended side effect on DNS queries.
This will result in a rekey failure for OE connections; a %pass will be
installed for your destination IP before a %pass is re-instituted to your
DNS server. As a workaround, please add your DNS servers to
/etc/ipsec.d/policies/clear.
* Packets on all interfaces are considered for OE, including loopback. If you're
running a local nameserver, you'll still need to exempt localhost DNS traffic
as per the previous point. Since this traffic has a source of 127.0.0.1/32,
the "clear" policy group will not suffice; you'll need to add the following
%passthrough conn to ipsec.conf:
conn exclude-lo
authby=never
left=127.0.0.1
leftsubnet=127.0.0.0/8
right=127.0.0.2
rightsubnet=127.0.0.0/8
type=passthrough
auto=route
OLD ISSUES
None, yet.
RELATED DOCUMENTS
FreeS/WAN Install web page doc/install.html
FreeS/WAN Install guide INSTALL
FreeS/WAN mailing list posts, including:
http://lists.freeswan.org/archives/design/2003-September/msg00057.html
To sign up for our mailing lists, see http://www.freeswan.org/mail.html

18733
doc/HowTo.html Normal file
View File

File diff suppressed because it is too large Load Diff

167
doc/Makefile Normal file
View File

@ -0,0 +1,167 @@
# Makefile to generate various formats from HTML source
#
# Assumes the htmldoc utility is available.
# This can be downloaded from www.easysw.com
#
# Also needs lynx(1) for HTML-to-text conversion
.SUFFIXES: .png .fig
FREESWANSRCDIR=..
include ${FREESWANSRCDIR}/Makefile.inc
# Format arguments for htmldoc
F="--toclevels 4 --header 1cd"
# source files in subdirectory
# basic stuff
a=src/intro.html src/upgrading.html src/quickstart.html \
src/policygroups.html src/faq.html
# related
b=src/manpages.html src/firewall.html src/trouble.html
# more advanced
c=src/compat.html src/interop.html src/performance.html \
src/testing.html src/kernel.html src/adv_config.html \
src/install.html src/config.html \
src/background.html src/user_examples.html \
src/makecheck.html src/umltesting.html \
# background and reference material
d=src/politics.html src/ipsec.html \
src/mail.html src/web.html src/glossary.html src/biblio.html \
src/rfc.html src/roadmap.html
# build and release related
e=src/umltesting.html src/makecheck.html src/nightly.html
sections=$a $b $c $d $e
# separate HTML files built in current directory
separate=intro.html install.html config.html manpages.html \
firewall.html trouble.html kernel.html roadmap.html \
compat.html interop.html politics.html ipsec.html \
mail.html performance.html testing.html web.html \
glossary.html biblio.html rfc.html faq.html \
adv_config.html user_examples.html background.html \
quickstart.html umltesting.html makecheck.html nightly.html \
upgrading.html policygroups.html
# various one-big-file formats
howto=HowTo.html HowTo.ps HowTo.pdf HowTo.txt
alldocs=${seperate} ${howto} index.html toc.html
srcdir=..
# where are scripts
SCRIPTDIR=utils
# where
TESTINGDIR=${srcdir}/testing
# where do we put HTML manpages?
HMANDIR=manpage.d
# default, build HTML only
# dependencies build most of it
# then we add index
index.html: toc.html HowTo.html manpages src/index.html
cp src/index.html index.html
# separate files plus table of contents
# and then remove HTML formatting added by htmldoc
toc.html : $(sections)
@htmldoc -t html --path ".;${TESTINGDIR}/doc" -d . $(sections)
@$(SCRIPTDIR)/cleanhtml.sh $(SCRIPTDIR)/cleanhtml.sed $(separate)
# one big HTML file
HowTo.html : $(sections)
@htmldoc -t html --toclevels 4 --header ' cf' -f $@ $(sections)
# other HowTo formats
HowTo.txt: HowTo.html
lynx -dump $< > $@
HowTo.ps : $(sections)
htmldoc -f $@ $(sections)
HowTo.pdf : $(sections)
@htmldoc -f $@ $(sections)
manpages: manp
manp: $(SCRIPTDIR)/mkhtmlman
@$(SCRIPTDIR)/mkhtmlman $(HMANDIR) `find ../programs ../lib ../linux -type f -name '*.[1-8]' -print | grep -v lwres | grep -v CVS`
programs:
all: #$(howto) $(manpages) index.html
clean:
@rm -f $(howto) $(separate) toc.html index.html
@rm -rf $(HMANDIR)
install:
#install: ${alldocs} manpages
# @mkdir -p ${DOCDIR}
# @$(foreach f, $(alldocs), \
# $(INSTALL) $f ${DOCDIR} || exit 1;\
# )
# @find ${HMANDIR} -type f -name "*.html" -print | while read file; \
# do \
# $(INSTALL) $$file ${DOCDIR} || exit 1;\
# done;
install_file_list:
@$(foreach f, $(alldocs), \
echo ${DOCDIR}/$f; \
)
@if [ -d ${HMANDIR} ]; then find ${HMANDIR} -type f -name "*.html" -print | while read file; \
do \
echo ${DOCDIR}/$$file; \
done; fi;
checkprograms: ;
check: ;
# not enabled by default, because xml2rfc must be installed first.
drafts: draft-richardson-ipsec-opportunistic.txt src/draft-richardson-ipsec-opportunistic.html \
draft-richardson-ipsec-rr.txt src/draft-richardson-ipsec-rr.html
draft-richardson-ipsec-opportunistic.txt: src/draft-richardson-ipsec-opportunistic.xml
XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc xml2rfc $? $@
draft-richardson-ipsec-rr.txt: src/draft-richardson-ipsec-rr.xml
XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc xml2rfc $? $@
draft-%.nr: src/draft-%.xml
XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc xml2nroff $? $@
draft-%.html: draft-%.xml
XML_LIBRARY=$(XML_LIBRARY):./src xml2rfc xml2html $? $@
.fig.eps:
fig2dev -L ps $< $@
.fig.png:
fig2dev -L png $< $@
single_netjig.png: testing/single_netjig.fig
multi_netjig.png: testing/multi_netjig.fig
makecheck.html: single_netjig.png multi_netjig.png
#
# DocBook based documentation
#
xmldocs: mast.html klips/mast.4
mast.html: klips/mast.xml
xmlto html klips/mast.xml
klips/mast.4: klips/mast.xml
xmlto -o klips man klips/mast.xml

39
doc/README Normal file
View File

@ -0,0 +1,39 @@
This directory has the HTML FreeS/WAN documentation.
Start from either of:
toc.html table of contents for HTML docs
index.html pointers to everything, including
text files not in HTML docs
The Makefile in this directory can generate various
things from the HTML source:
./*.html individual HTML files
with previous/contents/next links
toc.html table of contents
HowTo.html one big HTML file
HowTo.ps Postscript
HowTo.pdf PDF
HowTo.txt ASCII text
Not all of the above are in the shipped version. All but
text are on our website, www.freeswan.org. To get PDF or
Postscript, either grab them from the web or install
htmldoc from www.easysw.com, then use the Makefile.
Subdirectories are:
src/*.html HTML source files
manpage.d/*.html HTML versions of man pages
You should not need to look at these, except for following
links to HTML man pages.
The Internet Drafts are natively in XML format. They have been
converted with Marshall Rose's xml2rfc.
xml2rfc is available at xml.resource.org.
You may have to install the TclXML package by symlinking it into
/usr/lib/tcl8.3 or some such.

1232
doc/adv_config.html Normal file
View File

File diff suppressed because it is too large Load Diff

323
doc/background.html Normal file
View File

@ -0,0 +1,323 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="config.html">Previous</A>
<A HREF="user_examples.html">Next</A>
<HR>
<H1><A name="background">Linux FreeS/WAN background</A></H1>
<P>This section discusses a number of issues which have three things in
common:</P>
<UL>
<LI>They are not specifically FreeS/WAN problems</LI>
<LI>You may have to understand them to get FreeS/WAN working right</LI>
<LI>They are not simple questions</LI>
</UL>
<P>Grouping them here lets us provide the explanations some users will
need without unduly complicating the main text.</P>
<P>The explanations here are intended to be adequate for FreeS/WAN
purposes (please comment to the<A href="mail.html"> users mailing list</A>
if you don't find them so), but they are not trying to be complete or
definitive. If you need more information, see the references provided
in each section.</P>
<H2><A name="dns.background">Some DNS background</A></H2>
<P><A href="glossary.html#carpediem">Opportunistic encryption</A>
requires that the gateway systems be able to fetch public keys, and
other IPsec-related information, from each other's DNS (Domain Name
Service) records.</P>
<P><A href="glossary.html#DNS">DNS</A> is a distributed database that
maps names to IP addresses and vice versa.</P>
<P>Much good reference material is available for DNS, including:</P>
<UL>
<LI>the<A href="http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html"> DNS HowTo</A>
</LI>
<LI>the standard<A href="biblio.html#DNS.book"> DNS reference</A> book</LI>
<LI><A href="http://www.linuxdoc.org/LDP/nag2/index.html">Linux Network
Administrator's Guide</A></LI>
<LI><A href="http://www.nominum.com/resources/whitepapers/bind-white-paper.html">
BIND overview</A></LI>
<LI><A href="http://www.nominum.com/resources/documentation/Bv9ARM.pdf">
BIND 9 Administrator's Reference</A></LI>
</UL>
<P>We give only a brief overview here, intended to help you use DNS for
FreeS/WAN purposes.</P>
<H3><A name="forward.reverse">Forward and reverse maps</A></H3>
<P>Although the implementation is distributed, it is often useful to
speak of DNS as if it were just two enormous tables:</P>
<UL>
<LI>the forward map: look up a name, get an IP address</LI>
<LI>the reverse map: look up an IP address, get a name</LI>
</UL>
<P>Both maps can optionally contain additional data. For opportunistic
encryption, we insert the data need for IPsec authentication.</P>
<P>A system named gateway.example.com with IP address 10.20.30.40 should
have at least two DNS records, one in each map:</P>
<DL>
<DT>gateway.example.com. IN A 10.20.30.40</DT>
<DD>used to look up the name and get an IP address</DD>
<DT>40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</DT>
<DD>used for reverse lookups, looking up an address to get the
associated name. Notice that the digits here are in reverse order; the
actual address is 10.20.30.40 but we use 40.30.20.10 here.</DD>
</DL>
<H3><A NAME="17_1_2">Hierarchy and delegation</A></H3>
<P>For both maps there is a hierarchy of DNS servers and a system of
delegating authority so that, for example:</P>
<UL>
<LI>the DNS administrator for example.com can create entries of the form<VAR>
name</VAR>.example.com</LI>
<LI>the example.com admin cannot create an entry for counterexample.com;
only someone with authority for .com can do that</LI>
<LI>an admin might have authority for 20.10.in-addr.arpa.</LI>
<LI>in either map, authority can be delegated
<UL>
<LI>the example.com admin could give you authority for
westcoast.example.com</LI>
<LI>the 20.10.in-addr.arpa admin could give you authority for
30.20.10.in-addr.arpa</LI>
</UL>
</LI>
</UL>
<P>DNS zones are the units of delegation. There is a hierarchy of zones.</P>
<H3><A NAME="17_1_3">Syntax of DNS records</A></H3>
<P>Returning to the example records:</P>
<PRE> gateway.example.com. IN A 10.20.30.40
40.30.20.10.in-addr.arpa. IN PTR gateway.example.com.</PRE>
<P>some syntactic details are:</P>
<UL>
<LI>the IN indicates that these records are for<STRONG> In</STRONG>
ternet addresses</LI>
<LI>The final periods in '.com.' and '.arpa.' are required. They
indicate the root of the domain name system.</LI>
</UL>
<P>The capitalised strings after IN indicate the type of record.
Possible types include:</P>
<UL>
<LI><STRONG>A</STRONG>ddress, for forward lookups</LI>
<LI><STRONG>P</STRONG>oin<STRONG>T</STRONG>e<STRONG>R</STRONG>, for
reverse lookups</LI>
<LI><STRONG>C</STRONG>anonical<STRONG> NAME</STRONG>, records to support
aliasing, multiple names for one address</LI>
<LI><STRONG>M</STRONG>ail e<STRONG>X</STRONG>change, used in mail
routing</LI>
<LI><STRONG>SIG</STRONG>nature, used in<A href="glossary.html#SDNS">
secure DNS</A></LI>
<LI><STRONG>KEY</STRONG>, used in<A href="glossary.html#SDNS"> secure
DNS</A></LI>
<LI><STRONG>T</STRONG>e<STRONG>XT</STRONG>, a multi-purpose record type</LI>
</UL>
<P>To set up for opportunistic encryption, you add some TXT records to
your DNS data. Details are in our<A href="quickstart.html"> quickstart</A>
document.</P>
<H3><A NAME="17_1_4">Cacheing, TTL and propagation delay</A></H3>
<P>DNS information is extensively cached. With no caching, a lookup by
your system of &quot;www.freeswan.org&quot; might involve:</P>
<UL>
<LI>your system asks your nameserver for &quot;www.freeswan.org&quot;</LI>
<LI>local nameserver asks root server about &quot;.org&quot;, gets reply</LI>
<LI>local nameserver asks .org nameserver about &quot;freeswan.org&quot;, gets
reply</LI>
<LI>local nameserver asks freeswan.org nameserver about
&quot;www.freeswan.org&quot;, gets reply</LI>
</UL>
<P>However, this can be a bit inefficient. For example, if you are in
the Phillipines, the closest a root server is in Japan. That might send
you to a .org server in the US, and then to freeswan.org in Holland. If
everyone did all those lookups every time they clicked on a web link,
the net would grind to a halt.</P>
<P>Nameservers therefore cache information they look up. When you click
on another link at www.freeswan.org, your local nameserver has the IP
address for that server in its cache, and no further lookups are
required.</P>
<P>Intermediate results are also cached. If you next go to
lists.freeswan.org, your nameserver can just ask the freeswan.org
nameserver for that address; it does not need to query the root or .org
nameservers because it has a cached address for the freeswan.org zone
server.</P>
<P>Of course, like any cacheing mechanism, this can create problems of
consistency. What if the administrator for freeswan.org changes the IP
address, or the authentication key, for www.freeswan.org? If you use
old information from the cache, you may get it wrong. On the other
hand, you cannot afford to look up fresh information every time. Nor
can you expect the freeswan.org server to notify you; that isn't in the
protocols.</P>
<P>The solution that is in the protocols is fairly simple. Cacheable
records are marked with Time To Live (TTL) information. When the time
expires, the caching server discards the record. The next time someone
asks for it, the server fetches a fresh copy. Of course, a server may
also discard records before their TTL expires if it is running out of
cache space.</P>
<P>This implies that there will be some delay before the new version of
a changed record propagates around the net. Until the TTLs on all
copies of the old record expire, some users will see it because that is
what is in their cache. Other users may see the new record immediately
because they don't have an old one cached.</P>
<H2><A name="MTU.trouble">Problems with packet fragmentation</A></H2>
<P>It seems, from mailing list reports, to be moderately common for
problems to crop up in which small packets pass through the IPsec
tunnels just fine but larger packets fail.</P>
<P>These problems are caused by various devices along the way
mis-handling either packet fragments or<A href="glossary.html#pathMTU">
path MTU discovery</A>.</P>
<P>IPsec makes packets larger by adding an ESP or AH header. This can
tickle assorted bugs in fragment handling in routers and firewalls, or
in path MTU discovery mechanisms, and cause a variety of symptoms which
are both annoying and, often, quite hard to diagnose.</P>
<P>An explanation from project technical lead Henry Spencer:</P>
<PRE>The problem is IP fragmentation; more precisely, the problem is that the
second, third, etc. fragments of an IP packet are often difficult for
filtering mechanisms to classify.
Routers cannot rely on reassembling the packet, or remembering what was in
earlier fragments, because the fragments may be out of order or may even
follow different routes. So any general, worst-case filtering decision
pretty much has to be made on each fragment independently. (If the router
knows that it is the only route to the destination, so all fragments
*must* pass through it, reassembly would be possible... but most routers
don't want to bother with the complications of that.)
All fragments carry roughly the original IP header, but any higher-level
header is (for IP purposes) just the first part of the packet data... so
only the first fragment carries that. So, for example, on examining the
second fragment of a TCP packet, you could tell that it's TCP, but not
what port number it is destined for -- that information is in the TCP
header, which appears in the first fragment only.
The result of this classification difficulty is that stupid routers and
over-paranoid firewalls may just throw fragments away. To get through
them, you must reduce your MTU enough that fragmentation will not occur.
(In some cases, they might be willing to attempt reassembly, but have very
limited resources to devote to it, meaning that packets must be small and
fragments few in number, leading to the same conclusion: smaller MTU.)</PRE>
<P>In addition to the problem Henry describes, you may also have trouble
with<A href="glossary.html#pathMTU"> path MTU discovery</A>.</P>
<P>By default, FreeS/WAN uses a large<A href="glossary.html#MTU"> MTU</A>
for the ipsec device. This avoids some problems, but may complicate
others. Here's an explanation from Claudia:</P>
<PRE>Here are a couple of pieces of background information. Apologies if you
have seen these already. An excerpt from one of my old posts:
An MTU of 16260 on ipsec0 is usual. The IPSec device defaults to this
high MTU so that it does not fragment incoming packets before encryption
and encapsulation. If after IPSec processing packets are larger than 1500,
[ie. the mtu of eth0] then eth0 will fragment them.
Adding IPSec headers adds a certain number of bytes to each packet.
The MTU of the IPSec interface refers to the maximum size of the packet
before the IPSec headers are added. In some cases, people find it helpful
to set ipsec0's MTU to 1500-(IPSec header size), which IIRC is about 1430.
That way, the resulting encapsulated packets don't exceed 1500. On most
networks, packets less than 1500 will not need to be fragmented.
and... (from Henry Spencer)
The way it *ought* to work is that the MTU advertised by the ipsecN
interface should be that of the underlying hardware interface, less a
pinch for the extra headers needed.
Unfortunately, in certain situations this breaks many applications.
There is a widespread implicit assumption that the smallest MTUs are
at the ends of paths, not in the middle, and another that MTUs are
never less than 1500. A lot of code is unprepared to handle paths
where there is an &quot;interior minimum&quot; in the MTU, especially when it's
less than 1500. So we advertise a big MTU and just let the resulting
big packets fragment.
This usually works, but we do get bitten in cases where some intermediate
point can't handle all that fragmentation. We can't win on this one.</PRE>
<P>The MTU can be changed with an<VAR> overridemtu=</VAR> statement in
the<VAR> config setup</VAR> section of<A href="manpage.d/ipsec.conf.5.html">
ipsec.conf.5</A>.</P>
<P>For a discussion of MTU issues and some possible solutions using
Linux advanced routing facilities, see the<A href="http://www.linuxguruz.org/iptables/howto/2.4routing-15.html#ss15.6">
Linux 2.4 Advanced Routing HOWTO</A>. For a discussion of MTU and NAT
(Network Address Translation), see<A HREF="http://harlech.math.ucla.edu/services/ipsec.html">
James Carter's MTU notes</A>.</P>
<H2><A name="nat.background">Network address translation (NAT)</A></H2>
<P><STRONG>N</STRONG>etwork<STRONG> A</STRONG>ddress<STRONG> T</STRONG>
ranslation is a service provided by some gateway machines. Calling it
NAPT (adding the word<STRONG> P</STRONG>ort) would be more precise, but
we will follow the widespread usage.</P>
<P>A gateway doing NAT rewrites the headers of packets it is forwarding,
changing one or more of:</P>
<UL>
<LI>source address</LI>
<LI>source port</LI>
<LI>destination address</LI>
<LI>destination port</LI>
</UL>
<P>On Linux 2.4, NAT services are provided by the<A href="http://netfilter.samba.org">
netfilter(8)</A> firewall code. There are several<A href="http://netfilter.samba.org/documentation/index.html#HOWTO">
Netfilter HowTos</A> including one on NAT.</P>
<P>For older versions of Linux, this was referred to as &quot;IP masquerade&quot;
and different tools were used. See this<A href="http://www.e-infomax.com/ipmasq/">
resource page</A>.</P>
<P>Putting an IPsec gateway behind a NAT gateway is not recommended. See
our<A href="firewall.html#NAT"> firewalls document</A>.</P>
<H3><A NAME="17_3_1">NAT to non-routable addresses</A></H3>
<P>The most common application of NAT uses private<A href="glossary.html#non-routable">
non-routable</A> addresses.</P>
<P>Often a home or small office network will have:</P>
<UL>
<LI>one connection to the Internet</LI>
<LI>one assigned publicly visible IP address</LI>
<LI>several machines that all need access to the net</LI>
</UL>
<P>Of course this poses a problem since several machines cannot use one
address. The best solution might be to obtain more addresses, but often
this is impractical or uneconomical.</P>
<P>A common solution is to have:</P>
<UL>
<LI><A href="glossary.html#non-routable">non-routable</A> addresses on
the local network</LI>
<LI>the gateway machine doing NAT</LI>
<LI>all packets going outside the LAN rewritten to have the gateway as
their source address</LI>
</UL>
<P>The client machines are set up with reserved<A href="glossary.html#non-routable">
non-routable</A> IP addresses defined in RFC 1918. The masquerading
gateway, the machine with the actual link to the Internet, rewrites
packet headers so that all packets going onto the Internet appear to
come from one IP address, that of its Internet interface. It then gets
all the replies, does some table lookups and more header rewriting, and
delivers the replies to the appropriate client machines.</P>
<P>As far as anyone else on the Internet is concerned, the systems
behind the gateway are completely hidden. Only one machine with one IP
address is visible.</P>
<P>For IPsec on such a gateway, you can entirely ignore the NAT in:</P>
<UL>
<LI><A href="manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A></LI>
<LI>firewall rules affecting your Internet-side interface</LI>
</UL>
<P>Those can be set up exactly as they would be if your gateway had no
other systems behind it.</P>
<P>You do, however, have to take account of the NAT in firewall rules
which affect packet forwarding.</P>
<H3><A NAME="17_3_2">NAT to routable addresses</A></H3>
<P>NAT to routable addresses is also possible, but is less common and
may make for rather tricky routing problems. We will not discuss it
here. See the<A href="http://netfilter.samba.org/documentation/index.html#HOWTO">
Netfilter HowTos</A>.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="config.html">Previous</A>
<A HREF="user_examples.html">Next</A>
</BODY>
</HTML>

274
doc/biblio.html Normal file
View File

@ -0,0 +1,274 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="glossary.html">Previous</A>
<A HREF="rfc.html">Next</A>
<HR>
<H1><A name="biblio">Bibliography for the Linux FreeS/WAN project</A></H1>
<P>For extensive bibliographic links, see the<A href="http://liinwww.ira.uka.de/bibliography/index.html">
Collection of Computer Science Bibliographies</A></P>
<P>See our<A href="web.html"> web links</A> for material available
online.</P>
<HR><A name="adams"> Carlisle Adams and Steve Lloyd<CITE> Understanding
Public Key Infrastructure</CITE>
<BR></A> Macmillan 1999 ISBN 1-57870-166-x
<P>An overview, mainly concentrating on policy and strategic issues
rather than the technical details. Both authors work for<A href="glossary.html#PKI">
PKI</A> vendor<A href="http://www.entrust.com/"> Entrust</A>.</P>
<HR><A name="DNS.book"> Albitz, Liu &amp; Loukides<CITE> DNS &amp; BIND</CITE>
3rd edition
<BR></A> O'Reilly 1998 ISBN 1-56592-512-2
<P>The standard reference on the<A href="glossary.html#DNS"> Domain Name
Service</A> and<A href="glossary.html#BIND"> Berkeley Internet Name
Daemon</A>.</P>
<HR><A name="anderson"> Ross Anderson</A>,<CITE> Security Engineering -
a Guide to Building Dependable Distributed Systems</CITE>
<BR> Wiley, 2001, ISBN 0471389226
<P>Easily the best book for the security professional I have seen.<STRONG>
Highly recommended</STRONG>. See the<A href="http://www.cl.cam.ac.uk/~rja14/book.html">
book web page</A>.</P>
<P>This is quite readable, but Schneier's<A href="#secrets"> Secrets and
Lies</A> might be an easier introduction.</P>
<HR><A name="puzzle"> Bamford<CITE> The Puzzle Palace, A report on NSA,
Americas's most Secret Agency</CITE>
<BR> Houghton Mifflin 1982 ISBN 0-395-31286-8</A>
<HR> Bamford<CITE> Body of Secrets</CITE>
<P>The sequel.</P>
<HR><A name="bander"> David Bander</A>,<CITE> Linux Security Toolkit</CITE>
<BR> IDG Books, 2000, ISBN: 0764546902
<P>This book has a short section on FreeS/WAN and includes Caldera Linux
on CD.</P>
<HR><A name="CZR"> Chapman, Zwicky &amp; Russell</A>,<CITE> Building
Internet Firewalls</CITE>
<BR> O'Reilly 1995 ISBN 1-56592-124-0
<HR><A name="firewall.book"> Cheswick and Bellovin</A><CITE> Firewalls
and Internet Security: Repelling the Wily Hacker</CITE>
<BR> Addison-Wesley 1994 ISBN 0201633574
<P>A fine book on firewalls in particular and security in general from
two of AT&amp;T's system adminstrators.</P>
<P>Bellovin has also done a number of<A href="web.html#papers"> papers</A>
on IPsec and co-authored a<A href="intro.html#applied"> paper</A> on a
large FreeS/WAN application.</P>
<HR><A name="comer"> Comer<CITE> Internetworking with TCP/IP</CITE>
<BR> Prentice Hall</A>
<UL>
<LI>Vol. I: Principles, Protocols, &amp; Architecture, 3rd Ed. 1995
ISBN:0-13-216987-8</LI>
<LI>Vol. II: Design, Implementation, &amp; Internals, 2nd Ed. 1994
ISBN:0-13-125527-4</LI>
<LI>Vol. III: Client/Server Programming &amp; Applications
<UL>
<LI>AT&amp;T TLI Version 1994 ISBN:0-13-474230-3</LI>
<LI>BSD Socket Version 1996 ISBN:0-13-260969-X</LI>
<LI>Windows Sockets Version 1997 ISBN:0-13-848714-6</LI>
</UL>
</LI>
</UL>
<P>If you need to deal with the details of the network protocols, read
either this series or the<A href="#stevens"> Stevens and Wright</A>
series before you start reading the RFCs.</P>
<HR><A name="diffie"> Diffie and Landau</A><CITE> Privacy on the Line:
The Politics of Wiretapping and Encryption</CITE>
<BR> MIT press 1998 ISBN 0-262-04167-7 (hardcover) or 0-262-54100-9
<BR>
<HR><A name="d_and_hark"> Doraswamy and Harkins<CITE> IP Sec: The New
Security Standard for the Internet, Intranets and Virtual Private
Networks</CITE>
<BR> Prentice Hall 1999 ISBN: 0130118982</A>
<HR><A name="EFF"> Electronic Frontier Foundation<CITE> Cracking DES:
Secrets of Encryption Research, Wiretap Politics and Chip Design</CITE>
<BR></A> O'Reilly 1998 ISBN 1-56592-520-3
<P>To conclusively demonstrate that DES is inadequate for continued use,
the<A href="glossary.html#EFF"> EFF</A> built a machine for just over
$200,000 that breaks DES encryption in under five days on average,
under nine in the worst case.</P>
<P>The book provides details of their design and, perhaps even more
important, discusses why they felt the project was necessary.
Recommended for anyone interested in any of the three topics mentioned
in the subtitle.</P>
<P>See also the<A href="http://www.eff.org/descracker.html"> EFF page on
this project</A> and our discussion of<A href="politics.html#desnotsecure">
DES insecurity</A>.</P>
<HR> Martin Freiss<CITE> Protecting Networks with SATAN</CITE>
<BR> O'Reilly 1998 ISBN 1-56592-425-8
<BR> translated from a 1996 work in German
<P>SATAN is a Security Administrator's Tool for Analysing Networks. This
book is a tutorial in its use.</P>
<HR> Gaidosch and Kunzinger<CITE> A Guide to Virtual Private Networks</CITE>
<BR> Prentice Hall 1999 ISBN: 0130839647
<HR><A name="Garfinkel"> Simson Garfinkel</A><CITE> Database Nation: the
death of privacy in the 21st century</CITE>
<BR> O'Reilly 2000 ISBN 1-56592-653-6
<P>A thoughtful and rather scary book.</P>
<HR><A name="PGP"> Simson Garfinkel</A><CITE> PGP: Pretty Good Privacy</CITE>
<BR> O'Reilly 1995 ISBN 1-56592-098-8
<P>An excellent introduction and user manual for the<A href="glossary.html#PGP">
PGP</A> email-encryption package. PGP is a good package with a complex
and poorly-designed user interface. This book or one like it is a must
for anyone who has to use it at length.</P>
<P>The book covers using PGP in Unix, PC and Macintosh environments,
plus considerable background material on both the technical and
political issues around cryptography.</P>
<P>The book is now seriously out of date. It does not cover recent
developments such as commercial versions since PGP 5, the Open PGP
standard or GNU PG..</P>
<HR><A name="practical"> Garfinkel and Spafford</A><CITE> Practical Unix
Security</CITE>
<BR> O'Reilly 1996 ISBN 1-56592-148-8
<P>A standard reference.</P>
<P>Spafford's web page has an excellent collection of<A href="http://www.cs.purdue.edu/coast/hotlist">
crypto and security links</A>.</P>
<HR><A name="Kahn"> David Kahn</A><CITE> The Codebreakers: the
Comprehensive History of Secret Communications from Ancient Times to
the Internet</CITE>
<BR> second edition Scribner 1996 ISBN 0684831309
<P>A history of codes and code-breaking from ancient Egypt to the 20th
century. Well-written and exhaustively researched.<STRONG> Highly
recommended</STRONG>, even though it does not have much on computer
cryptography.</P>
<HR> David Kahn<CITE> Seizing the Enigma, The Race to Break the German
U-Boat codes, 1939-1943</CITE>
<BR> Houghton Mifflin 1991 ISBN 0-395-42739-8
<HR><A name="kirch"> Olaf Kirch</A><CITE> Linux Network Administrator's
Guide</CITE>
<BR> O'Reilly 1995 ISBN 1-56592-087-2
<P>Now becoming somewhat dated in places, but still a good introductory
book and general reference.</P>
<HR><A name="LinVPN"> Kolesnikov and Hatch</A>,<CITE> Building Linux
Virtual Private Networks (VPNs)</CITE>
<BR> New Riders 2002
<P>This has had a number of favorable reviews, including<A href="http://www.slashdot.org/article.pl?sid=02/02/27/0115214&amp;mode=thread&amp;tid=172">
this one</A> on Slashdot. The book has a<A href="http://www.buildinglinuxvpns.net/">
web site</A>.</P>
<HR><A name="RFCs"> Pete Loshin<CITE> Big Book of IPsec RFCs</CITE>
<BR> Morgan Kaufmann 2000 ISBN: 0-12-455839-9</A>
<HR><A name="crypto"> Steven Levy<CITE> Crypto: How the Code Rebels Beat
the Government -- Saving Privacy in the Digital Age</CITE></A>
<BR> Penguin 2001, ISBN 0-670--85950-8
<P><STRONG>Highly recommended</STRONG>. A fine history of recent (about
1970-2000) developments in the field, and the related political
controversies. FreeS/WAN project founder and leader John Gilmore
appears several times.</P>
<P>The book does not cover IPsec or FreeS/WAN, but this project is very
much another battle in the same war. See our discussion of the<A href="politics.html">
politics</A>.</P>
<HR><A name="GTR"> Matyas, Anderson et al.</A><CITE> The Global Trust
Register</CITE>
<BR> Northgate Consultants Ltd 1998 ISBN: 0953239705
<BR> hard cover edition MIT Press 1999 ISBN 0262511053
<P>From<A href="http://www.cl.cam.ac.uk/Research/Security/Trust-Register">
their web page:</A></P>
<BLOCKQUOTE> This book is a register of the fingerprints of the world's
most important public keys; it implements a top-level certification
authority (CA) using paper and ink rather than in an electronic system.</BLOCKQUOTE>
<HR><A name="handbook"> Menezies, van Oorschot and Vanstone<CITE>
Handbook of Applied Cryptography</CITE></A>
<BR> CRC Press 1997
<BR> ISBN 0-8493-8523-7
<P>An excellent reference. Read<A href="#schneier"> Schneier</A> before
tackling this.</P>
<HR> Michael Padlipsky<CITE> Elements of Networking Style</CITE>
<BR> Prentice-Hall 1985 ISBN 0-13-268111-0 or 0-13-268129-3
<P>Probably<STRONG> the funniest technical book ever written</STRONG>,
this is a vicious but well-reasoned attack on the OSI &quot;seven layer
model&quot; and all that went with it. Several chapters of it are also
available as RFCs 871 to 875.</P>
<HR><A name="matrix"> John S. Quarterman</A><CITE> The Matrix: Computer
Networks and Conferencing Systems Worldwide</CITE>
<BR> Digital Press 1990 ISBN 155558-033-5
<BR> Prentice-Hall ISBN 0-13-565607-9
<P>The best general treatment of computer-mediated communication we have
seen. It naturally has much to say about the Internet, but also covers
UUCP, Fidonet and so on.</P>
<HR><A name="ranch"> David Ranch</A><CITE> Securing Linux Step by Step</CITE>
<BR> SANS Institute, 1999
<P><A href="http://www.sans.org/">SANS</A> is a respected organisation,
this guide is part of a well-known series, and Ranch has previously
written the useful<A href=" http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos">
Trinity OS</A> guide to securing Linux, so my guess would be this is a
pretty good book. I haven't read it yet, so I'm not certain. It can be
ordered online from<A href="http://www.sans.org/"> SANS</A>.</P>
<P>Note (Mar 1, 2002): a new edition with different editors in the
works. Expect it this year.</P>
<HR><A name="schneier"> Bruce Schneier</A><CITE> Applied Cryptography,
Second Edition</CITE>
<BR> John Wiley &amp; Sons, 1996
<BR> ISBN 0-471-12845-7 hardcover
<BR> ISBN 0-471-11709-9 paperback
<P>A standard reference on computer cryptography. For more recent
essays, see the<A href="http://www.counterpane.com/"> author's
company's web site</A>.</P>
<HR><A name="secrets"> Bruce Schneier</A><CITE> Secrets and Lies</CITE>
<BR> Wiley 2000, ISBN 0-471-25311-1
<P>An interesting discussion of security and privacy issues, written
with more of an &quot;executive overview&quot; approach rather than a narrow
focus on the technical issues.<STRONG> Highly recommended</STRONG>.</P>
<P>This is worth reading even if you already understand security issues,
or think you do. To go deeper, follow it with Anderson's<A href="#anderson">
Security Engineering</A>.</P>
<HR><A name="VPNbook"> Scott, Wolfe and Irwin<CITE> Virtual Private
Networks</CITE></A>
<BR> 2nd edition, O'Reilly 1999 ISBN: 1-56592-529-7
<P>This is the only O'Reilly book, out of a dozen I own, that I'm
disappointed with. It deals mainly with building VPNs with various
proprietary tools --<A href="glossary.html#PPTP"> PPTP</A>,<A href="glossary.html#SSH">
SSH</A>, Cisco PIX, ... -- and touches only lightly on IPsec-based
approaches.</P>
<P>That said, it appears to deal competently with what it does cover and
it has readable explanations of many basic VPN and security concepts.
It may be exactly what some readers require, even if I find the
emphasis unfortunate.</P>
<HR><A name="LASG"> Kurt Seifried<CITE> Linux Administrator's Security
Guide</CITE></A>
<P>Available online from<A href="http://www.securityportal.com/lasg/">
Security Portal</A>. It has fairly extensive coverage of IPsec.</P>
<HR><A name="Smith"> Richard E Smith<CITE> Internet Cryptography</CITE>
<BR></A> ISBN 0-201-92480-3, Addison Wesley, 1997
<P>See the book's<A href="http://www.visi.com/crypto/inet-crypto/index.html">
home page</A></P>
<HR><A name="neal"> Neal Stephenson<CITE> Cryptonomicon</CITE></A>
<BR> Hardcover ISBN -380-97346-4, Avon, 1999.
<P>A novel in which cryptography and the net figure prominently.<STRONG>
Highly recommended</STRONG>: I liked it enough I immediately went out
and bought all the author's other books.</P>
<P>There is also a paperback edition. Sequels are expected.</P>
<HR><A name="stevens"> Stevens and Wright</A><CITE> TCP/IP Illustrated</CITE>
<BR> Addison-Wesley
<UL>
<LI>Vol. I: The Protocols 1994 ISBN:0-201-63346-9</LI>
<LI>Vol. II: The Implementation 1995 ISBN:0-201-63354-X</LI>
<LI>Vol. III: TCP for Transactions, HTTP, NNTP, and the UNIX Domain
Protocols 1996 ISBN: 0-201-63495-3</LI>
</UL>
<P>If you need to deal with the details of the network protocols, read
either this series or the<A href="#comer"> Comer</A> series before you
start reading the RFCs.</P>
<HR><A name="Rubini"> Rubini</A><CITE> Linux Device Drivers</CITE>
<BR> O'Reilly &amp; Associates, Inc. 1998 ISBN 1-56592-292-1
<HR><A name="Zeigler"> Robert Zeigler</A><CITE> Linux Firewalls</CITE>
<BR> Newriders Publishing, 2000 ISBN 0-7537-0900-9
<P>A good book, with detailed coverage of ipchains(8) firewalls and of
many related issues.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="glossary.html">Previous</A>
<A HREF="rfc.html">Next</A>
</BODY>
</HTML>

707
doc/compat.html Normal file
View File

@ -0,0 +1,707 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="trouble.html">Previous</A>
<A HREF="interop.html">Next</A>
<HR>
<H1><A name="compat">Linux FreeS/WAN Compatibility Guide</A></H1>
<P>Much of this document is quoted directly from the Linux FreeS/WAN<A href="mail.html">
mailing list</A>. Thanks very much to the community of testers,
patchers and commenters there, especially the ones quoted below but
also various contributors we haven't quoted.</P>
<H2><A name="spec">Implemented parts of the IPsec Specification</A></H2>
<P>In general, do not expect Linux FreeS/WAN to do everything yet. This
is a work-in-progress and some parts of the IPsec specification are not
yet implemented.</P>
<H3><A name="in">In Linux FreeS/WAN</A></H3>
<P>Things we do, as of version 1.96:</P>
<UL>
<LI>key management methods
<DL>
<DT>manually keyed</DT>
<DD>using keys stored in /etc/ipsec.conf</DD>
<DT>automatically keyed</DT>
<DD>Automatically negotiating session keys as required. All connections
are automatically re-keyed periodically. The<A href="glossary.html#Pluto">
Pluto</A> daemon implements this using the<A href="glossary.html#IKE">
IKE</A> protocol.</DD>
</DL>
</LI>
<LI>Methods of authenticating gateways for IKE
<DL>
<DT>shared secrets</DT>
<DD>stored in<A href="manpage.d/ipsec.secrets.5.html"> ipsec.secrets(5)</A>
</DD>
<DT><A href="glossary.html#RSA">RSA</A> signatures</DT>
<DD>For details, see<A href="manpage.d/ipsec_pluto.8.html"> pluto(8)</A>
.</DD>
<DT>looking up RSA authentication keys from<A href="glossary.html#DNS">
DNS</A>.</DT>
<DD>Note that this technique cannot be fully secure until<A href="glossary.html#SDNS">
secure DNS</A> is widely deployed.</DD>
</DL>
</LI>
<LI>groups for<A href="glossary.html#DH"> Diffie-Hellman</A> key
negotiation
<DL>
<DT>group 2, modp 1024-bit</DT>
<DT>group 5, modp 1536-bit</DT>
<DD>We implement these two groups.
<P>In negotiating a keying connection (ISAKMP SA, Phase 1) we propose
both groups when we are the initiator, and accept either when a peer
proposes them. Once the keying connection is made, we propose only the
alternative agreed there for data connections (IPsec SA's, Phase 2)
negotiated over that keying connection.</P>
</DD>
</DL>
</LI>
<LI>encryption transforms
<DL>
<DT><A href="glossary.html#DES">DES</A></DT>
<DD>DES is in the source code since it is needed to implement 3DES, but
single DES is not made available to users because<A href="politics.html#desnotsecure">
DES is insecure</A>.</DD>
<DT><A href="glossary.html#3DES">Triple DES</A></DT>
<DD>implemented, and used as the default encryption in Linux FreeS/WAN.</DD>
</DL>
</LI>
<LI>authentication transforms
<DL>
<DT><A href="glossary.html#HMAC">HMAC</A> using<A href="glossary.html#MD5">
MD5</A></DT>
<DD>implemented, may be used in IKE or by by AH or ESP transforms.</DD>
<DT><A href="glossary.html#HMAC">HMAC</A> using<A href="glossary.html#SHA">
SHA</A></DT>
<DD>implemented, may be used in IKE or by AH or ESP transforms.</DD>
</DL>
<P>In negotiations, we propose both of these and accept either.</P>
</LI>
<LI>compression transforms
<DL>
<DT>IPComp</DT>
<DD>IPComp as described in RFC 2393 was added for FreeS/WAN 1.6. Note
that Pluto becomes confused if you ask it to do IPComp when the kernel
cannot.</DD>
</DL>
</LI>
</UL>
<P>All combinations of implemented transforms are supported. Note that
some form of packet-level<STRONG> authentication is required whenever
encryption is used</STRONG>. Without it, the encryption will not be
secure.</P>
<H3><A name="dropped">Deliberately omitted</A></H3>
We do not implement everything in the RFCs because some of those things
are insecure. See our discussions of avoiding<A href="politics.html#weak">
bogus security</A>.
<P>Things we deliberately omit which are required in the RFCs are:</P>
<UL>
<LI>null encryption (to use ESP as an authentication-only service)</LI>
<LI>single DES</LI>
<LI>DH group 1, a 768-bit modp group</LI>
</UL>
<P>Since these are the only encryption algorithms and DH group the RFCs
require, it is possible in theory to have a standards-conforming
implementation which will not interpoperate with FreeS/WAN. Such an
implementation would be inherently insecure, so we do not consider this
a problem.</P>
<P>Anyway, most implementations sensibly include more secure options as
well, so dropping null encryption, single DES and Group 1 does not
greatly hinder interoperation in practice.</P>
<P>We also do not implement some optional features allowed by the RFCs:</P>
<UL>
<LI>aggressive mode for negotiation of the keying channel or ISAKMP SA.
This mode is a little faster than main mode, but exposes more
information to an eavesdropper.</LI>
</UL>
<P>In theory, this should cause no interoperation problems since all
implementations are required to support the more secure main mode,
whether or not they also allow aggressive mode.</P>
<P>In practice, it does sometimes produce problems with implementations
such as Windows 2000 where aggressive mode is the default. Typically,
these are easily solved with a configuration change that overrides that
default.</P>
<H3><A name="not">Not (yet) in Linux FreeS/WAN</A></H3>
<P>Things we don't yet do, as of version 1.96:</P>
<UL>
<LI>key management methods
<UL>
<LI>authenticate key negotiations via local<A href="glossary.html#PKI">
PKI</A> server, but see links to user<A href="web.html#patch"> patches</A>
</LI>
<LI>authenticate key negotiations via<A href="glossary.html#SDNS">
secure DNS</A></LI>
<LI>unauthenticated key management, using<A href="glossary.html#DH">
Diffie-Hellman</A> key agreement protocol without authentication.
Arguably, this would be worth doing since it is secure against all
passive attacks. On the other hand, it is vulnerable to an active<A href="glossary.html#middle">
man-in-the-middle attack</A>.</LI>
</UL>
</LI>
<LI>encryption transforms
<P>Currently<A href="glossary.html#3DES"> Triple DES</A> is the only
encryption method Pluto will negotiate.</P>
<P>No additional encryption transforms are implemented, though the RFCs
allow them and some other IPsec implementations support various of
them. We are not eager to add more. See this<A href="faq.html#other.cipher">
FAQ question</A>.</P>
<P><A href="glossary.html#AES">AES</A>, the successor to the DES
standard, is an excellent candidate for inclusion in FreeS/WAN, see
links to user<A href="web.html#patch"> patches</A>.</P>
</LI>
<LI>authentication transforms
<P>No optional additional authentication transforms are currently
implemented. Likely<A href="glossary.html#SHA-256"> SHA-256, SHA-384
and SHA-512</A> will be added when AES is.</P>
</LI>
<LI>Policy checking on decrypted packets
<P>To fully comply with the RFCs, it is not enough just to accept only
packets which survive any firewall rules in place to limit what IPsec
packets get in, and then pass KLIPS authentication. That is what
FreeS/WAN currently does.</P>
<P>We should also apply additional tests, for example ensuring that all
packets emerging from a particular tunnel have source and destination
addresses that fall within the subnets defined for that tunnel, and
that packets with those addresses that did not emerge from the
appropriate tunnel are disallowed.</P>
<P>This will be done as part of a KLIPS rewrite. See these<A href="intro.html#applied">
links</A> and the<A href="mail.html"> design mailing list</A> for
discussion.</P>
</LI>
</UL>
<H2><A name="pfkey">Our PF-Key implementation</A></H2>
<P>We use PF-key Version Two for communication between the KLIPS kernel
code and the Pluto Daemon. PF-Key v2 is defined by<A href="http://www.normos.org/ietf/rfc/rfc2367.txt">
RFC 2367</A>.</P>
<P>The &quot;PF&quot; stands for Protocol Family. PF-Inet defines a
kernel/userspace interface for the TCP/IP Internet protocols (TCP/IP),
and other members of the PF series handle Netware, Appletalk, etc.
PF-Key is just a PF for key-related matters.</P>
<H3><A name="pfk.port">PF-Key portability</A></H3>
<P>PF-Key came out of Berkeley Unix work and is used in the various BSD
IPsec implementations, and in Solaris. This means there is some hope of
porting our Pluto(8) to one of the BSD distributions, or of running
their photurisd(8) on Linux if you prefer<A href="glossary.html#photuris">
Photuris</A> key management over IKE.</P>
<P>It is, however, more complex than that. The PK-Key RFC deliberately
deals only with keying, not policy management. The three PF-Key
implementations we have looked at -- ours, OpenBSD and KAME -- all have
extensions to deal with security policy, and the extensions are
different. There have been discussions aimed at sorting out the
differences, perhaps for a version three PF-Key spec. All players are
in favour of this, but everyone involved is busy and it is not clear
whether or when these discussions might bear fruit.</P>
<H2><A name="otherk">Kernels other than the latest 2.2.x and 2.4.y</A></H2>
<P>We develop and test on Redhat Linux using the most recent kernel in
the 2.2 and 2.4 series. In general, we recommend you use the latest
kernel in one of those series. Complications and caveats are discussed
below.</P>
<H3><A name="kernel.2.0">2.0.x kernels</A></H3>
<P>Consider upgrading to the 2.2 kernel series. If you want to stay with
the 2.0 series, then we strongly recommend 2.0.39. Some useful security
patches were added in 2.0.38.</P>
<P>Various versions of the code have run at various times on most 2.0.xx
kernels, but the current version is only lightly tested on 2.0.39, and
not at all on older kernels.</P>
<P>Some of our patches for older kernels are shipped in 2.0.37 and
later, so they are no longer provided in FreeS/WAN. This means recent
versions of FreeS/WAN will probably not compile on anything earlier
than 2.0.37.</P>
<H3><A name="kernel.production">2.2 and 2.4 kernels</A></H3>
<DL>
<DT>FreeS/WAN 1.0</DT>
<DD>ran only on 2.0 kernels</DD>
<DT>FreeS/WAN 1.1 to 1.8</DT>
<DD>ran on 2.0 or 2.2 kernels
<BR> ran on some development kernels, 2.3 or 2.4-test</DD>
<DT>FreeS/WAN 1.9 to 1.96</DT>
<DD>runs on 2.0, 2.2 or 2.4 kernels</DD>
</DL>
<P>In general,<STRONG> we suggest the latest 2.2 kernel or 2.4 for
production use</STRONG>.</P>
<P>Of course no release can be guaranteed to run on kernels more recent
than it is, so quite often there will be no stable FreeS/WAN for the
absolute latest kernel. See the<A href="faq.html#k.versions"> FAQ</A>
for discussion.</P>
<H2><A name="otherdist">Intel Linux distributions other than Redhat</A></H2>
<P>We develop and test on Redhat 6.1 for 2.2 kernels, and on Redhat 7.1
or 7.2 for 2.4, so minor changes may be required for other
distributions.</P>
<H3><A name="rh7">Redhat 7.0</A></H3>
<P>There are some problems with FreeS/WAN on Redhat 7.0. They are
soluble, but we recommend you upgrade to a later Redhat instead..</P>
<P>Redhat 7 ships with two compilers.</P>
<UL>
<LI>Their<VAR> gcc</VAR> is version 2.96. Various people, including the
GNU compiler developers and Linus, have said fairly emphatically that
using this was a mistake. 2.96 is a development version, not intended
for production use. In particular, it will not compile a Linux kernel.</LI>
<LI>Redhat therefore also ship a separate compiler, which they call<VAR>
kgcc</VAR>, for compiling kernels.</LI>
</UL>
<P>Kernel Makefiles have<VAR> gcc</VAR> as a default, and must be
adjusted to use<VAR> kgcc</VAR> before a kernel will compile on 7.0.
This mailing list message gives details:</P>
<PRE>Subject: Re: AW: Installing IPsec on Redhat 7.0
Date: Thu, 1 Feb 2001 14:32:52 -0200 (BRST)
From: Mads Rasmussen &lt;mads@cit.com.br&gt;
&gt; From www.redhat.com/support/docs/gotchas/7.0/gotchas-7-6.html#ss6.1
cd to /usr/src/linux and open the Makefile in your favorite editor. You
will need to look for a line similar to this:
CC = $(CROSS_COMPILE)gcc -D__KERNEL__ -I$(HPATH)
This line specifies which C compiler to use to build the kernel. It should
be changed to:
CC = $(CROSS_COMPILE)kgcc -D__KERNEL__ -I$(HPATH)
for Red Hat Linux 7. The kgcc compiler is egcs 2.91.66. From here you can
proceed with the typical compiling steps.</PRE>
<P>Check the<A href="mail.html"> mailing list</A> archive for more
recent news.</P>
<H3><A name="suse">SuSE Linux</A></H3>
<P>SuSE 6.3 and later versions, at least in Europe, ship with FreeS/WAN
included.</P>
<P>FreeS/WAN packages distributed for SuSE 7.0-7.2 were somehow
miscompiled. You can find fixed packages on<A HREF="http://www.suse.de/~garloff/linux/FreeSWAN">
Kurt Garloff's page</A>.</P>
<P>Here are some notes for an earlier SuSE version.</P>
<H4>SuSE Linux 5.3</H4>
<PRE>Date: Mon, 30 Nov 1998
From: Peter Onion &lt;ponion@srd.bt.co.uk&gt;
... I got Saturdays snapshot working between my two SUSE5.3 machines at home.
The mods to the install process are quite simple. From memory and looking at
the files on the SUSE53 machine here at work....
And extra link in each of the /etc/init.d/rc?.d directories called K35ipsec
which SUSE use to shut a service down.
A few mods in /etc/init.d/ipsec to cope with the different places that SUSE
put config info, and remove the inculsion of /etc/rc.d/init.d/functions and .
/etc/sysconfig/network as they don't exists and 1st one isn't needed anyway.
insert &quot;. /etc/rc.config&quot; to pick up the SUSE config info and use
if test -n &quot;$NETCONFIG&quot; -a &quot;$NETCONFIG&quot; != &quot;YAST_ASK&quot; ; then
to replace
[ ${NETWORKING} = &quot;no&quot; ] &amp;&amp; exit 0
Create /etc/sysconfig as SUSE doesn't have one.
I think that was all (but I prob forgot something)....</PRE>
<P>You may also need to fiddle initialisation scripts to ensure that<VAR>
/var/run/pluto.pid</VAR> is removed when rebooting. If this file is
present, Pluto does not come up correctly.</P>
<H3><A name="slack">Slackware</A></H3>
<PRE>Subject: Re: linux-IPsec: Slackware distribution
Date: Thu, 15 Apr 1999 12:07:01 -0700
From: Evan Brewer &lt;dmessiah@silcon.com&gt;
&gt; Very shortly, I will be needing to install IPsec on at least gateways that
&gt; are running Slackware. . . .
The only trick to getting it up is that on the slackware dist there is no
init.d directory in /etc/rc.d .. so create one. Then, what I do is take the
IPsec startup script which normally gets put into the init.d directory, and
put it in /etc/rc.d and name ir rc.ipsec .. then I symlink it to the file
in init.d. The only file in the dist you need to really edit is the
utils/Makefile, setup4:
Everything else should be just fine.</PRE>
<P>A year or so later:</P>
<PRE>Subject: Re: HTML Docs- Need some cleanup?
Date: Mon, 8 Jan 2001
From: Jody McIntyre &lt;jodym@oeone.com&gt;
I have successfully installed FreeS/WAN on several Slackware 7.1 machines.
FreeS/WAN installed its rc.ipsec file in /etc/rc.d. I had to manually call
this script from rc.inet2. This seems to be an easier method than Evan
Brewer's.</PRE>
<H3><A name="deb">Debian</A></H3>
<P>A recent (Nov 2001) mailing list points to a<A href="http://www.thing.dyndns.org/debian/vpn.htm">
web page</A> on setting up several types of tunnel, including IPsec, on
Debian.</P>
<P>Some older information:</P>
<PRE>Subject: FreeS/WAN 1.0 on Debian 2.1
Date: Tue, 20 Apr 1999
From: Tim Miller &lt;cerebus+counterpane@haybaler.sackheads.org&gt;
Compiled and installed without error on a Debian 2.1 system
with kernel-source-2.0.36 after pointing RCDIR in utils/Makefile to
/etc/init.d.
/var/lock/subsys/ doesn't exist on Debian boxen, needs to be
created; not a fatal error.
Finally, IPsec scripts appear to be dependant on GNU awk
(gawk); the default Debian awk (mawk-1.3.3-2) had fatal difficulties.
With gawk installed and /etc/alternatives/awk linked to /usr/bin/gawk
operation appears flawless.</PRE>
<P>The scripts in question have been modified since this was posted. Awk
versions should no longer be a problem.</P>
<H3><A name="caldera">Caldera</A></H3>
<PRE>Subject: Re: HTML Docs- Need some cleanup?
Date: Mon, 08 Jan 2001
From: Andy Bradford &lt;andyb@calderasystems.com&gt;
On Sun, 07 Jan 2001 22:59:05 EST, Sandy Harris wrote:
&gt; Intel Linux distributions other than Redhat 5.x and 6.x
&gt; Redhat 7.0
&gt; SuSE Linux
&gt; SuSE Linux 5.3
&gt; Slackware
&gt; Debian
Can you please include Caldera in this list? I have tested it since
FreeS/Wan 1.1 and it works great with our systems---provided one
follows the FreeS/Wan documentation. :-)
Thank you,
Andy</PRE>
<H2><A name="CPUs">CPUs other than Intel</A></H2>
<P>FreeS/WAN has been run sucessfully on a number of different CPU
architectures. If you have tried it on one not listed here, please post
to the<A href="mail.html"> mailing list</A>.</P>
<H3><A name=" strongarm">Corel Netwinder (StrongARM CPU)</A></H3>
<PRE>Subject: linux-ipsec: Netwinder diffs
Date: Wed, 06 Jan 1999
From: rhatfield@plaintree.com
I had a mistake in my IPsec-auto, so I got things working this morning.
Following are the diffs for my changes. Probably not the best and cleanest way
of doing it, but it works. . . . </PRE>
<P>These diffs are in the 0.92 and later distributions, so these should
work out-of-the-box on Netwinder.</P>
<H3><A name="yellowdog">Yellow Dog Linux on Power PC</A></H3>
<PRE>Subject: Compiling FreeS/WAN 1.1 on YellowDog Linux (PPC)
Date: 11 Dec 1999
From: Darron Froese &lt;darron@fudgehead.com&gt;
I'm summarizing here for the record - because it's taken me many hours to do
this (multiple times) and because I want to see IPsec on more linuxes than
just x86.
Also, I can't remember if I actually did summarize it before... ;-) I'm
working too many late hours.
That said - here goes.
1. Get your linux kernel and unpack into /usr/src/linux/ - I used 2.2.13.
&lt;http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.13.tar.bz2&gt;
2. Get FreeS/WAN and unpack into /usr/src/freeswan-1.1
&lt;ftp://ftp.xs4all.nl/pub/crypto/freeswan/freeswan-1.1.tar.gz&gt;
3. Get the gmp src rpm from here:
&lt;ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm&gt;
4. Su to root and do this: rpm --rebuild gmp-2.0.2-9a.src.rpm
You will see a lot of text fly by and when you start to see the rpm
recompiling like this:
Executing: %build
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd gmp-2.0.2
+ libtoolize --copy --force
Remember to add `AM_PROG_LIBTOOL' to `configure.in'.
You should add the contents of `/usr/share/aclocal/libtool.m4' to
`aclocal.m4'.
+ CFLAGS=-O2 -fsigned-char
+ ./configure --prefix=/usr
Hit Control-C to stop the rebuild. NOTE: We're doing this because for some
reason the gmp source provided with FreeS/WAN 1.1 won't build properly on
ydl.
cd /usr/src/redhat/BUILD/
cp -ar gmp-2.0.2 /usr/src/freeswan-1.1/
cd /usr/src/freeswan-1.1/
rm -rf gmp
mv gmp-2.0.2 gmp
5. Open the freeswan Makefile and change the line that says:
KERNEL=$(b)zimage (or something like that) to
KERNEL=vmlinux
6. cd ../linux/
7. make menuconfig
Select an option or two and then exit - saving your changes.
8. cd ../freeswan-1.1/ ; make menugo
That will start the whole process going - once that's finished compiling,
you have to install your new kernel and reboot.
That should build FreeS/WAN on ydl (I tried it on 1.1).</PRE>
And a later message on the same topic:
<PRE>Subject: Re: FreeS/WAN, PGPnet and E-mail
Date: Sat, 22 Jan 2000
From: Darron Froese &lt;darron@fudgehead.com&gt;
on 1/22/00 6:47 PM, Philip Trauring at philip@trauring.com wrote:
&gt; I have a PowerMac G3 ...
The PowerMac G3 can run YDL 1.1 just fine. It should also be able to run
FreeS/WAN 1.2patch1 with a couple minor modifications:
1. In the Makefile it specifies a bzimage for the kernel compile - you have
to change that to vmlinux for the PPC.
2. The gmp source that comes with FreeS/WAN (for whatever reason) fails to
compile. I have gotten around this by getting the gmp src rpm from here:
ftp://ftp.yellowdoglinux.com//pub/yellowdog/champion-1.1/SRPMS/SRPMS/gmp-2.0.2-9a.src.rpm
If you rip the source out of there - and place it where the gmp source
resides it will compile just fine.</PRE>
<P>FreeS/WAN no longer includes GMP source.</P>
<H3><A name="mklinux">Mklinux</A></H3>
<P>One user reports success on the Mach-based<STRONG> m</STRONG>icro<STRONG>
k</STRONG>ernel Linux.</P>
<PRE>Subject: Smiles on sparc and ppc
Date: Fri, 10 Mar 2000
From: Jake Hill &lt;jah@alien.bt.co.uk&gt;
You may or may not be interested to know that I have successfully built
FreeS/WAN on a number of non intel alpha architectures; namely on ppc
and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
works, mostly, with few changes.</PRE>
<H3><A name="alpha">Alpha 64-bit processors</A></H3>
<PRE>Subject: IT WORKS (again) between intel &amp; alpha :-)))))
Date: Fri, 29 Jan 1999
From: Peter Onion &lt;ponion@srd.bt.co.uk&gt;
Well I'm happy to report that I've got an IPsec connection between by intel &amp; alpha machines again :-))
If you look back on this list to 7th of December I wrote...
-On 07-Dec-98 Peter Onion wrote:
-&gt;
-&gt; I've about had enuf of wandering around inside the kernel trying to find out
-&gt; just what is corrupting outgoing packets...
-
-Its 7:30 in the evening .....
-
-I FIXED IT :-))))))))))))))))))))))))))))))))
-
-It was my own fault :-((((((((((((((((((
-
-If you ask me very nicly I'll tell you where I was a little too over keen to
-change unsigned long int __u32 :-) OPSE ...
-
-So tomorrow it will full steam ahead to produce a set of diffs/patches against
-0.91
-
-Peter Onion.</PRE>
<P>In general (there have been some glitches), FreeS/WAN has been
running on Alphas since then.</P>
<H3><A name="SPARC">Sun SPARC processors</A></H3>
<P>Several users have reported success with FreeS/WAN on SPARC Linux.
Here is one mailing list message:</P>
<PRE>Subject: Smiles on sparc and ppc
Date: Fri, 10 Mar 2000
From: Jake Hill &lt;jah@alien.bt.co.uk&gt;
You may or may not be interested to know that I have successfully built
FreeS/WAN on a number of non intel alpha architectures; namely on ppc
and sparc and also on osfmach3/ppc (MkLinux). I can report that it just
works, mostly, with few changes.
I have a question, before I make up some patches. I need to hack
gmp/mpn/powerpc32/*.s to build them. Is this ok? The changes are
trivial, but could I also use a different version of gmp? Is it vanilla
here?
I guess my only real headache is from ipchains, which appears to stop
running when IPsec has been started for a while. This is with 2.2.14 on
sparc.</PRE>
<P>This message, from a different mailing list, may be relevant for
anyone working with FreeS/WAN on Suns:</P>
<PRE>Subject: UltraSPARC DES assembler
Date: Thu, 13 Apr 2000
From: svolaf@inet.uni2.dk (Svend Olaf Mikkelsen)
To: coderpunks@toad.com
An UltraSPARC assembler version of the LibDES/SSLeay/OpenSSL des_enc.c
file is available at http://inet.uni2.dk/~svolaf/des.htm.
This brings DES on UltraSPARC from slower than Pentium at the same
clock speed to significantly faster.</PRE>
<H3><A name="mips">MIPS processors</A></H3>
<P>We know FreeS/WAN runs on at least some MIPS processors because<A href="http://www.lasat.com">
Lasat</A> manufacture an IPsec box based on an embedded MIPS running
Linux with FreeS/WAN. We have no details.</P>
<H3><A name="crusoe">Transmeta Crusoe</A></H3>
<P>The Merilus<A href="http://www.merilus.com/products/fc/index.shtml">
Firecard</A>, a Linux firewall on a PCI card, is based on a Crusoe
processor and supports FreeS/WAN.</P>
<H3><A name="coldfire">Motorola Coldfire</A></H3>
<PRE>Subject: Re: Crypto hardware support
Date: Mon, 03 Jul 2000
From: Dan DeVault &lt;devault@tampabay.rr.com&gt;
.... I have been running
uClinux with FreeS/WAN 1.4 on a system built by Moreton Bay (
http://www.moretonbay.com ) and it was using a Coldfire processor
and was able to do the Triple DES encryption at just about
1 mbit / sec rate....... they put a Hi/Fn 7901 hardware encryption
chip on their board and now their system does over 25 mbit of 3DES
encryption........ pretty significant increase if you ask me.</PRE>
<H2><A name="multiprocessor">Multiprocessor machines</A></H2>
<P>FreeS/WAN is designed to work on SMP (symmetric multi-processing)
Linux machines and is regularly tested on dual processor x86 machines.</P>
<P>We do not know of any testing on multi-processor machines with other
CPU architectures or with more than two CPUs. Anyone who does test
this, please report results to the<A href="mail.html"> mailing list</A>
.</P>
<P>The current design does not make particularly efficient use of
multiprocessor machines; some of the kernel work is single-threaded.</P>
<H2><A name="hardware">Support for crypto hardware</A></H2>
<P>Supporting hardware cryptography accelerators has not been a high
priority for the development team because it raises a number of fairly
complex issues:</P>
<UL>
<LI>Can you trust the hardware? If it is not Open Source, how do you
audit its security? Even if it is, how do you check that the design has
no concealed traps?</LI>
<LI>If an interface is added for such hardware, can that interface be
subverted or misused?</LI>
<LI>Is hardware acceleration actually a performance win? It clearly is
in many cases, but on a fast machine it might be better to use the CPU
for the encryption than to pay the overheads of moving data to and from
a crypto board.</LI>
<LI>the current KLIPS code does not provide a clean interface for
hardware accelerators</LI>
</UL>
<P>That said, we have a<A href="#coldfire"> report</A> of FreeS/WAN
working with one crypto accelerator and some work is going on to modify
KLIPS to create a clean generic interface to such products. See this<A href="http://www.jukie.net/~bart/linux-ipsec/">
web page</A> for some of the design discussion.</P>
<P>More recently, a patch to support some hardware accelerators has been
posted:</P>
<PRE>Subject: [Design] [PATCH] H/W acceleration patch
Date: Tue, 18 Sep 2001
From: &quot;Martin Gadbois&quot; &lt;martin.gadbois@colubris.com&gt;
Finally!!
Here's a web site with H/W acceleration patch for FreeS/WAN 1.91, including
S/W and Hifn 7901 crypto support.
http://sources.colubris.com/
Martin Gadbois</PRE>
<P>Hardware accelerators could take performance well beyond what
FreeS/WAN can do in software (discussed<A href="performance.html"> here</A>
). Here is some discussion off the IETF IPsec list, October 2001:</P>
<PRE> ... Currently shipping chips deliver, 600 mbps throughput on a single
stream of 3DES IPsec traffic. There are also chips that use multiple
cores to do 2.4 gbps. We (Cavium) and others have announced even faster
chips. ... Mid 2002 versions will handle at line rate (OC48 and OC192)
IPsec and SSL/TLS traffic not only 3DES CBC but also AES and arc4.</PRE>
<P>The patches to date support chips that have been in production for
some time, not the state-of-the-art latest-and-greatest devices
described in that post. However, they may still outperform software and
they almost certainly reduce CPU overhead.</P>
<H2><A name="ipv6">IP version 6 (IPng)</A></H2>
<P>The Internet currently runs on version four of the IP protocols. IPv4
is what is in the standard Linux IP stack, and what FreeS/WAN was built
for. In IPv4, IPsec is an optional feature.</P>
<P>The next version of the IP protocol suite is version six, usually
abbreviated either as &quot;IPv6&quot; or as &quot;IPng&quot; for &quot;IP: the next
generation&quot;. For IPv6, IPsec is a required feature. Any machine doing
IPv6 is required to support IPsec, much as any machine doing (any
version of) IP is required to support ICMP.</P>
<P>There is a Linux implementation of IPv6 in Linux kernels 2.2 and
above. For details, see the<A href="http://www.cs-ipv6.lancs.ac.uk/ipv6/systems/linux/faq/">
FAQ</A>. It does not yet support IPsec. The<A href="http://www.linux-ipv6.org/">
USAGI</A> project are also working on IPv6 for Linux.</P>
<P>FreeS/WAN was originally built for the current standard, IPv4, but we
are interested in seeing it work with IPv6. Some progress has been
made, and a patched version with IPv6 support is<A href="http://www.ipv6.iabg.de/downloadframe/index.html">
available</A>. For more recent information, check the<A href="mail.html">
mailing list</A>.</P>
<H3><A name="v6.back">IPv6 background</A></H3>
<P>IPv6 has been specified by an IETF<A href="http://www.ietf.org/html.charters/ipngwg-charter.html">
working group</A>. The group's page lists over 30 RFCs to date, and
many Internet Drafts as well. The overview is<A href="http://www.ietf.org/rfc/rfc2460.txt">
RFC 2460</A>. Major features include:</P>
<UL>
<LI>expansion of the address space from 32 to 128 bits,</LI>
<LI>changes to improve support for
<UL>
<LI>mobile IP</LI>
<LI>automatic network configuration</LI>
<LI>quality of service routing</LI>
<LI>...</LI>
</UL>
</LI>
<LI>improved security via IPsec</LI>
</UL>
<P>A number of projects are working on IPv6 implementation. A prominent
Open Source effort is<A href="http://www.kame.net/"> KAME</A>, a
collaboration among several large Japanese companies to implement IPv6
for Berkeley Unix. Other major players are also working on IPv6. For
example, see pages at:</P>
<UL>
<LI><A href="http://playground.sun.com/pub/ipng/html/ipng-main.html">Sun</A>
</LI>
<LI><A href="http://www.cisco.com/warp/public/732/ipv6/index.html">Cisco</A>
</LI>
<LI><A href="http://www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/IPv6.asp">
Microsoft</A></LI>
</UL>
<P>The<A href="http://www.6bone.net/"> 6bone</A> (IPv6 backbone) testbed
network has been up for some time. There is an active<A href="http://www.ipv6.org/">
IPv6 user group</A>.</P>
<P>One of the design goals for IPv6 was that it must be possible to
convert from v4 to v6 via a gradual transition process. Imagine the
mess if there were a &quot;flag day&quot; after which the entire Internet used
v6, and all software designed for v4 stopped working. Almost every
computer on the planet would need major software changes! There would
be huge costs to replace older equipment. Implementers would be worked
to death before &quot;the day&quot;, systems administrators and technical support
would be completely swamped after it. The bugs in every implementation
would all bite simultaneously. Large chunks of the net would almost
certainly be down for substantial time periods. ...</P>
<P>Fortunately, the design avoids any &quot;flag day&quot;. It is therefore a
little tricky to tell how quickly IPv6 will take over. The transition
has certainly begun. For examples, see announcements from<A href="http://www.mailbase.ac.uk/lists/internet2/2000-03/0016.html">
NTT</A> and<A href="http://www.vnunet.com/News/1102383"> Nokia</A>.
However, it is not yet clear how quickly the process will gain
momentum, or when it will be completed. Likely large parts of the
Internet will remain with IPv4 for years to come.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="trouble.html">Previous</A>
<A HREF="interop.html">Next</A>
</BODY>
</HTML>

308
doc/config.html Normal file
View File

@ -0,0 +1,308 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="install.html">Previous</A>
<A HREF="background.html">Next</A>
<HR>
<H1><A NAME="config">How to configure FreeS/WAN</A></H1>
<P>This page will teach you how to configure a simple network-to-network
link or a Road Warrior connection between two Linux FreeS/WAN boxes.</P>
<P>See also these related documents:</P>
<UL>
<LI>our<A HREF="quickstart.html#quickstart"> quickstart</A> guide to<A HREF="glossary.html#carpediem">
opportunistic encryption</A></LI>
<LI>our guide to configuration with<A HREF="policygroups.html#policygroups">
policy groups</A></LI>
<LI>our<A HREF="adv_config.html#adv_config"> advanced configuration</A>
document</LI>
</UL>
<P> The network-to-network setup allows you to connect two office
networks into one Virtual Private Network, while the Road Warrior
connection secures a laptop's telecommute to work. Our examples also
show the basic procedure on the Linux FreeS/WAN side where another
IPsec peer is in play.</P>
<P> Shortcut to<A HREF="#config.netnet"> net-to-net</A>.
<BR> Shortcut to<A HREF="#config.rw"> Road Warrior</A>.</P>
<H2><A NAME="16_1">Requirements</A></H2>
<P>To configure the network-to-network connection you must have:</P>
<UL>
<LI>two Linux gateways with static IPs</LI>
<LI>a network behind each gate. Networks must have non-overlapping IP
ranges.</LI>
<LI>Linux FreeS/WAN<A HREF="install.html#install"> installed</A> on both
gateways</LI>
<LI><A HREF="http://www.tcpdump.org"><VAR>tcpdump</VAR></A> on the local
gate, to test the connection</LI>
</UL>
<P>For the Road Warrior you need:</P>
<UL>
<LI>one Linux box with a static IP</LI>
<LI>a Linux laptop with a dynamic IP</LI>
<LI>Linux FreeS/WAN installed on both</LI>
<LI>for testing,<VAR> tcpdump</VAR> on your gateway or laptop</LI>
</UL>
<P>If both IPs are dynamic, your situation is a bit trickier. Your best
bet is a variation on the<A HREF="#config.rw"> Road Warrior</A>, as
described in<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00282.html">
this mailing list message</A>.</P>
<H2><A name="config.netnet"></A>Net-to-Net connection</H2>
<H3><A name="netnet.info.ex">Gather information</A></H3>
<P>For each gateway, compile the following information:</P>
<UL>
<LI>gateway IP</LI>
<LI>IP range of the subnet you will be protecting. This doesn't have to
be your whole physical subnet.</LI>
<LI>a name by which that gateway can identify itself for IPsec
negotiations. Its form is a Fully Qualified Domain Name preceded by an
@ sign, ie. @xy.example.com.
<BR> It does not need to be within a domain that you own. It can be a
made-up name.</LI>
</UL>
<H4>Get your leftrsasigkey</H4>
<P>On your local Linux FreeS/WAN gateway, print your IPsec public key:</P>
<PRE> ipsec showhostkey --left</PRE>
<P>The output should look like this (with the key shortened for easy
reading):</P>
<PRE> # RSA 2048 bits xy.example.com Fri Apr 26 15:01:41 2002
leftrsasigkey=0sAQOnwiBPt...</PRE>
<P>Don't have a key? Use<A HREF="manpage.d/ipsec_newhostkey.8.html"><VAR>
ipsec newhostkey</VAR></A> to create one.</P>
<H4>...and your rightrsasigkey</H4>
<P>Get a console on the remote side:</P>
<PRE> ssh2 ab.example.com</PRE>
<P>In that window, type:</P>
<PRE> ipsec showhostkey --right</PRE>
<P>You'll see something like:</P>
<PRE> # RSA 2192 bits ab.example.com Thu May 16 15:26:20 2002
rightrsasigkey=0sAQOqH55O...</PRE>
<H3><A NAME="16_2_2">Edit<VAR> /etc/ipsec.conf</VAR></A></H3>
<P>Back on the local gate, copy our template to<VAR> /etc/ipsec.conf</VAR>
. (on Mandrake,<VAR> /etc/freeswan/ipsec.conf</VAR>). Substitute the
information you've gathered for our example data.</P>
<PRE>conn net-to-net
left=192.0.2.2 # Local vitals
leftsubnet=192.0.2.128/29 #
leftid=@xy.example.com #
leftrsasigkey=0s1LgR7/oUM... #
leftnexthop=%defaultroute # correct in many situations
right=192.0.2.9 # Remote vitals
rightsubnet=10.0.0.0/24 #
rightid=@ab.example.com #
rightrsasigkey=0sAQOqH55O... #
rightnexthop=%defaultroute # correct in many situations
auto=add # authorizes but doesn't start this
# connection at startup</PRE>
<P> &quot;Left&quot; and &quot;right&quot; should represent the machines that have FreeS/WAN
installed on them, and &quot;leftsubnet&quot; and &quot;rightsubnet&quot; machines that are
being protected. /32 is assumed for left/right and left/rightsubnet
parameters.</P>
<P>Copy<VAR> conn net-to-net</VAR> to the remote-side /etc/ipsec.conf.
If you've made no other modifications to either<VAR> ipsec.conf</VAR>,
simply:</P>
<PRE> scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf</PRE>
<H3><A NAME="16_2_3">Start your connection</A></H3>
<P>Locally, type:</P>
<PRE> ipsec auto --up net-to-net</PRE>
<P>You should see:</P>
<PRE> 104 &quot;net-net&quot; #223: STATE_MAIN_I1: initiate
106 &quot;net-net&quot; #223: STATE_MAIN_I2: sent MI2, expecting MR2
108 &quot;net-net&quot; #223: STATE_MAIN_I3: sent MI3, expecting MR3
004 &quot;net-net&quot; #223: STATE_MAIN_I4: ISAKMP SA established
112 &quot;net-net&quot; #224: STATE_QUICK_I1: initiate
004 &quot;net-net&quot; #224: STATE_QUICK_I2: sent QI2, IPsec SA established</PRE>
<P>The important thing is<VAR> IPsec SA established</VAR>. If you're
unsuccessful, see our<A HREF="trouble.html#trouble"> troubleshooting
tips</A>.</P>
<H3><A NAME="16_2_4">Do not MASQ or NAT packets to be tunneled</A></H3>
<P>If you are using<A HREF="glossary.html#masq"> IP masquerade</A> or<A HREF="glossary.html#NAT.gloss">
Network Address Translation (NAT)</A> on either gateway, you must now
exempt the packets you wish to tunnel from this treatment. For example,
if you have a rule like:</P>
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
</PRE>
<P>change it to something like:</P>
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE</PRE>
<P>This may be necessary on both gateways.</P>
<H3><A NAME="16_2_5">Test your connection</A></H3>
<P>Sit at one of your local subnet nodes (not the gateway), and ping a
subnet node on the other (again, not the gateway).</P>
<PRE> ping fileserver.toledo.example.com</PRE>
<P>While still pinging, go to the local gateway and snoop your outgoing
interface, for example:</P>
<PRE> tcpdump -i ppp0</PRE>
<P>You want to see ESP (Encapsulating Security Payload) packets moving<B>
back and forth</B> between the two gateways at the same frequency as
your pings:</P>
<PRE> 19:16:32.046220 192.0.2.2 &gt; 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
19:16:32.085630 192.0.2.9 &gt; 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)</PRE>
<P>If you see this, congratulations are in order! You have a tunnel
which will protect any IP data from one subnet to the other, as it
passes between the two gates. If not, go and<A HREF="trouble.html#trouble">
troubleshoot</A>.</P>
<P>Note: your new tunnel protects only net-net traffic, not
gateway-gateway, or gateway-subnet. If you need this (for example, if
machines on one net need to securely contact a fileserver on the IPsec
gateway), you'll need to create<A HREF="adv_config.html#adv_config">
extra connections</A>.</P>
<H3><A NAME="16_2_6">Finishing touches</A></H3>
<P>Now that your connection works, name it something sensible, like:</P>
<PRE>conn winstonnet-toledonet</PRE>
<P>To have the tunnel come up on-boot, replace</P>
<PRE> auto=add</PRE>
<P>with:</P>
<PRE> auto=start</PRE>
<P>Copy these changes to the other side, for example:</P>
<PRE> scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf</PRE>
<P>Enjoy!</P>
<H2><A name="config.rw"></A>Road Warrior Configuration</H2>
<H3><A name="rw.info.ex">Gather information</A></H3>
<P>You'll need to know:</P>
<UL>
<LI>the gateway's static IP</LI>
<LI>the IP range of the subnet behind that gateway</LI>
<LI>a name by which each side can identify itself for IPsec
negotiations. Its form is a Fully Qualified Domain Name preceded by an
@ sign, ie. @road.example.com.
<BR> It does not need to be within a domain that you own. It can be a
made-up name.</LI>
</UL>
<H4>Get your leftrsasigkey...</H4>
<P>On your laptop, print your IPsec public key:</P>
<PRE> ipsec showhostkey --left</PRE>
<P>The output should look like this (with the key shortened for easy
reading):</P>
<PRE> # RSA 2192 bits road.example.com Sun Jun 9 02:45:02 2002
leftrsasigkey=0sAQPIPN9uI...</PRE>
<P>Don't have a key? See<A HREF="old_config.html#genrsakey"> these
instructions</A>.</P>
<H4>...and your rightrsasigkey</H4>
<P>Get a console on the gateway:</P>
<PRE> ssh2 xy.example.com</PRE>
<P>View the gateway's public key with:</P>
<PRE> ipsec showhostkey --right</PRE>
<P>This will yield something like</P>
<PRE> # RSA 2048 bits xy.example.com Fri Apr 26 15:01:41 2002
rightrsasigkey=0sAQOnwiBPt...</PRE>
<H3><A NAME="16_3_2">Customize<VAR> /etc/ipsec.conf</VAR></A></H3>
<P>On your laptop, copy this template to<VAR> /etc/ipsec.conf</VAR>. (on
Mandrake,<VAR> /etc/freeswan/ipsec.conf</VAR>). Substitute the
information you've gathered for our example data.</P>
<PRE>conn road
left=%defaultroute # Picks up our dynamic IP
leftnexthop=%defaultroute #
leftid=@road.example.com # Local information
leftrsasigkey=0sAQPIPN9uI... #
right=192.0.2.10 # Remote information
rightsubnet=10.0.0.0/24 #
rightid=@xy.example.com #
rightrsasigkey=0sAQOnwiBPt... #
auto=add # authorizes but doesn't start this
# connection at startup</PRE>
<P>The template for the gateway is different. Notice how it reverses<VAR>
left</VAR> and<VAR> right</VAR>, in keeping with our convention that<STRONG>
L</STRONG>eft is<STRONG> L</STRONG>ocal,<STRONG> R</STRONG>ight<STRONG>
R</STRONG>emote. Be sure to switch your rsasigkeys in keeping with
this.</P>
<PRE> ssh2 xy.example.com
vi /etc/ipsec.conf</PRE>
<P>and add:</P>
<PRE>conn road
left=192.0.2.2 # Gateway's information
leftid=@xy.example.com #
leftsubnet=192.0.2.128/29 #
leftrsasigkey=0sAQOnwiBPt... #
rightnexthop=%defaultroute # correct in many situations
right=%any # Wildcard: we don't know the laptop's IP
rightid=@road.example.com #
rightrsasigkey=0sAQPIPN9uI... #
auto=add # authorizes but doesn't start this
# connection at startup</PRE>
<H3><A NAME="16_3_3">Start your connection</A></H3>
<P>You must start the connection from the Road Warrior side. On your
laptop, type:</P>
<PRE> ipsec auto --start net-to-net</PRE>
<P>You should see:</P>
<PRE>104 &quot;net-net&quot; #223: STATE_MAIN_I1: initiate
106 &quot;road&quot; #301: STATE_MAIN_I2: sent MI2, expecting MR2
108 &quot;road&quot; #301: STATE_MAIN_I3: sent MI3, expecting MR3
004 &quot;road&quot; #301: STATE_MAIN_I4: ISAKMP SA established
112 &quot;road&quot; #302: STATE_QUICK_I1: initiate
004 &quot;road&quot; #302: STATE_QUICK_I2: sent QI2, IPsec SA established</PRE>
<P>Look for<VAR> IPsec SA established</VAR>. If you're unsuccessful, see
our<A HREF="trouble.html#trouble"> troubleshooting tips</A>.</P>
<H3><A NAME="16_3_4">Do not MASQ or NAT packets to be tunneled</A></H3>
<P>If you are using<A HREF="glossary.html#masq"> IP masquerade</A> or<A HREF="glossary.html#NAT.gloss">
Network Address Translation (NAT)</A> on either gateway, you must now
exempt the packets you wish to tunnel from this treatment. For example,
if you have a rule like:</P>
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE
</PRE>
<P>change it to something like:</P>
<PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE</PRE>
<H3><A NAME="16_3_5">Test your connection</A></H3>
<P>From your laptop, ping a subnet node behind the remote gateway. Do
not choose the gateway itself for this test.</P>
<PRE> ping ns.winston.example.com</PRE>
<P>Snoop the packets exiting the laptop, with a command like:</P>
<PRE> tcpdump -i wlan0</PRE>
<P>You have success if you see (Encapsulating Security Payload) packets
travelling<B> in both directions</B>:</P>
<PRE> 19:16:32.046220 192.0.2.2 &gt; 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3)
19:16:32.085630 192.0.2.9 &gt; 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)</PRE>
<P>If you do, great! Traffic between your Road Warrior and the net
behind your gateway is protected. If not, see our<A HREF="trouble.html#trouble">
troubleshooting hints</A>.</P>
<P>Your new tunnel protects only traffic addressed to the net, not to
the IPsec gateway itself. If you need the latter, you'll want to make
an<A HREF="adv_config.html#adv_config"> extra tunnel.</A>.</P>
<H3><A NAME="16_3_6">Finishing touches</A></H3>
<P>On both ends, name your connection wisely, like:</P>
<PRE>conn mike-to-office</PRE>
<P><B>On the laptop only,</B> replace</P>
<PRE> auto=add</PRE>
<P>with:</P>
<PRE> auto=start</PRE>
<P>so that you'll be connected on-boot.</P>
<P>Happy telecommuting!</P>
<H3><A NAME="16_3_7">Multiple Road Warriors</A></H3>
<P>If you're using RSA keys, as we did in this example, you can add as
many Road Warriors as you like. The left/rightid parameter lets Linux
FreeS/WAN distinguish between multiple Road Warrior peers, each with
its own public key.</P>
<P>The situation is different for shared secrets (PSK). During a PSK
negotiation, ID information is not available at the time Pluto is
trying to determine which secret to use, so, effectively, you can only
define one Roadwarrior connection. All your PSK road warriors must
therefore share one secret.</P>
<H2><A NAME="16_4">What next?</A></H2>
<P>Using the principles illustrated here, you can try variations such
as:</P>
<UL>
<LI>a telecommuter with a static IP</LI>
<LI>a road warrior with a subnet behind it</LI>
</UL>
<P>Or, look at some of our<A HREF="adv_config.html#adv_config"> more
complex configuration examples.</A>.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="install.html">Previous</A>
<A HREF="background.html">Next</A>
</BODY>
</HTML>

2688
doc/draft-richardson-ipsec-opportunistic.txt Normal file
View File

File diff suppressed because it is too large Load Diff

840
doc/draft-richardson-ipsec-rr.txt Normal file
View File

@ -0,0 +1,840 @@
IPSECKEY WG M. Richardson
Internet-Draft SSW
Expires: March 4, 2004 September 4, 2003
A method for storing IPsec keying material in DNS.
draft-ietf-ipseckey-rr-07.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a new resource record for DNS. This record
may be used to store public keys for use in IPsec systems.
This record replaces the functionality of the sub-type #1 of the KEY
Resource Record, which has been obsoleted by RFC3445.
Richardson Expires March 4, 2004 [Page 1]
Internet-Draft ipsecrr September 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 4
2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 4
2.3 RDATA format - algorithm type . . . . . . . . . . . . . . . . 4
2.4 RDATA format - gateway type . . . . . . . . . . . . . . . . . 4
2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 5
2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 5
3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7
3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 7
3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1 Active attacks against unsecured IPSECKEY resource records . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
Normative references . . . . . . . . . . . . . . . . . . . . . 13
Non-normative references . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
Richardson Expires March 4, 2004 [Page 2]
Internet-Draft ipsecrr September 2003
1. Introduction
The type number for the IPSECKEY RR is TBD.
1.1 Overview
The IPSECKEY resource record (RR) is used to publish a public key
that is to be associated with a Domain Name System (DNS) name for use
with the IPsec protocol suite. This can be the public key of a
host, network, or application (in the case of per-port keying).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [8].
1.2 Usage Criteria
An IPSECKEY resource record SHOULD be used in combination with DNSSEC
unless some other means of authenticating the IPSECKEY resource
record is available.
It is expected that there will often be multiple IPSECKEY resource
records at the same name. This will be due to the presence of
multiple gateways and the need to rollover keys.
This resource record is class independent.
Richardson Expires March 4, 2004 [Page 3]
Internet-Draft ipsecrr September 2003
2. Storage formats
2.1 IPSECKEY RDATA format
The RDATA for an IPSECKEY RR consists of a precedence value, a public
key, algorithm type, and an optional gateway address.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence | gateway type | algorithm | gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ +
~ gateway ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
2.2 RDATA format - precedence
This is an 8-bit precedence for this record. This is interpreted in
the same way as the PREFERENCE field described in section 3.3.9 of
RFC1035 [2].
Gateways listed in IPSECKEY records with lower precedence are to be
attempted first. Where there is a tie in precedence, the order
should be non-deterministic.
2.3 RDATA format - algorithm type
The algorithm type field identifies the public key's cryptographic
algorithm and determines the format of the public key field.
A value of 0 indicates that no key is present.
The following values are defined:
1 A DSA key is present, in the format defined in RFC2536 [11]
2 A RSA key is present, in the format defined in RFC3110 [12]
2.4 RDATA format - gateway type
The gateway type field indicates the format of the information that
is stored in the gateway field.
Richardson Expires March 4, 2004 [Page 4]
Internet-Draft ipsecrr September 2003
The following values are defined:
0 No gateway is present
1 A 4-byte IPv4 address is present
2 A 16-byte IPv6 address is present
3 A wire-encoded domain name is present. The wire-encoded format is
self-describing, so the length is implicit. The domain name MUST
NOT be compressed.
2.5 RDATA format - gateway
The gateway field indicates a gateway to which an IPsec tunnel may be
created in order to reach the entity named by this resource record.
There are three formats:
A 32-bit IPv4 address is present in the gateway field. The data
portion is an IPv4 address as described in section 3.4.1 of RFC1035
[2]. This is a 32-bit number in network byte order.
A 128-bit IPv6 address is present in the gateway field. The data
portion is an IPv6 address as described in section 2.2 of RFC1886
[7]. This is a 128-bit number in network byte order.
The gateway field is a normal wire-encoded domain name, as described
in section 3.3 of RFC1035 [2]. Compression MUST NOT be used.
2.6 RDATA format - public keys
Both of the public key types defined in this document (RSA and DSA)
inherit their public key formats from the corresponding KEY RR
formats. Specifically, the public key field contains the algorithm-
specific portion of the KEY RR RDATA, which is all of the KEY RR DATA
after the first four octets. This is the same portion of the KEY RR
that must be specified by documents that define a DNSSEC algorithm.
Those documents also specify a message digest to be used for
generation of SIG RRs; that specification is not relevant for
IPSECKEY RR.
Future algorithms, if they are to be used by both DNSSEC (in the KEY
RR) and IPSECKEY, are likely to use the same public key encodings in
both records. Unless otherwise specified, the IPSECKEY public key
field will contain the algorithm-specific portion of the KEY RR RDATA
for the corresponding algorithm. The algorithm must still be
Richardson Expires March 4, 2004 [Page 5]
Internet-Draft ipsecrr September 2003
designated for use by IPSECKEY, and an IPSECKEY algorithm type number
(which might be different than the DNSSEC algorithm number) must be
assigned to it.
The DSA key format is defined in RFC2536 [11]
The RSA key format is defined in RFC3110 [12], with the following
changes:
The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
modulus to 2552 bits in length. RFC3110 extended that limit to 4096
bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on
RSA public keys, other than the 65535 octet limit imposed by the two-
octet length encoding. This length extension is applicable only to
IPSECKEY and not to KEY RRs.
Richardson Expires March 4, 2004 [Page 6]
Internet-Draft ipsecrr September 2003
3. Presentation formats
3.1 Representation of IPSECKEY RRs
IPSECKEY RRs may appear in a zone data master file. The precedence,
gateway type and algorithm and gateway fields are REQUIRED. The
base64 encoded public key block is OPTIONAL; if not present, then the
public key field of the resource record MUST be construed as being
zero octets in length.
The algorithm field is an unsigned integer. No mnemonics are
defined.
If no gateway is to be indicated, then the gateway type field MUST be
zero, and the gateway field MUST be "."
The Public Key field is represented as a Base64 encoding of the
Public Key. Whitespace is allowed within the Base64 text. For a
definition of Base64 encoding, see RFC1521 [3] Section 5.2.
The general presentation for the record as as follows:
IN IPSECKEY ( precedence gateway-type algorithm
gateway base64-encoded-public-key )
3.2 Examples
An example of a node 192.0.2.38 that will accept IPsec tunnels on its
own behalf.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
192.0.2.38
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 192.0.2.38 that has published its key only.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2
.
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 192.0.2.38 that has delegated authority to the
node 192.0.2.3.
38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2
192.0.2.3
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
Richardson Expires March 4, 2004 [Page 7]
Internet-Draft ipsecrr September 2003
An example of a node, 192.0.1.38 that has delegated authority to the
node with the identity "mygateway.example.com".
38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2
mygateway.example.com.
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has
delegated authority to the node 2001:0DB8:c000:0200:2::1
$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int.
0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2
2001:0DB8:0:8002::2000:1
AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
Richardson Expires March 4, 2004 [Page 8]
Internet-Draft ipsecrr September 2003
4. Security Considerations
This entire memo pertains to the provision of public keying material
for use by key management protocols such as ISAKMP/IKE (RFC2407) [9].
The IPSECKEY resource record contains information that SHOULD be
communicated to the end client in an integral fashion - i.e. free
from modification. The form of this channel is up to the consumer of
the data - there must be a trust relationship between the end
consumer of this resource record and the server. This relationship
may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
another secure source, a secure local channel on the host, or some
combination of the above.
The keying material provided by the IPSECKEY resource record is not
sensitive to passive attacks. The keying material may be freely
disclosed to any party without any impact on the security properties
of the resulting IPsec session: IPsec and IKE provide for defense
against both active and passive attacks.
Any user of this resource record MUST carefully document their trust
model, and why the trust model of DNSSEC is appropriate, if that is
the secure channel used.
4.1 Active attacks against unsecured IPSECKEY resource records
This section deals with active attacks against the DNS. These
attacks require that DNS requests and responses be intercepted and
changed. DNSSEC is designed to defend against attacks of this kind.
The first kind of active attack is when the attacker replaces the
keying material with either a key under its control or with garbage.
If the attacker is not able to mount a subsequent man-in-the-middle
attack on the IKE negotiation after replacing the public key, then
this will result in a denial of service, as the authenticator used by
IKE would fail.
If the attacker is able to both to mount active attacks against DNS
and is also in a position to perform a man-in-the-middle attack on
IKE and IPsec negotiations, then the attacker will be in a position
to compromise the resulting IPsec channel. Note that an attacker
must be able to perform active DNS attacks on both sides of the IKE
negotiation in order for this to succeed.
The second kind of active attack is one in which the attacker
replaces the the gateway address to point to a node under the
attacker's control. The attacker can then either replace the public
Richardson Expires March 4, 2004 [Page 9]
Internet-Draft ipsecrr September 2003
key or remove it, thus providing an IPSECKEY record of its own to
match the gateway address.
This later form creates a simple man-in-the-middle since the attacker
can then create a second tunnel to the real destination. Note that,
as before, this requires that the attacker also mount an active
attack against the responder.
Note that the man-in-the-middle can not just forward cleartext
packets to the original destination. While the destination may be
willing to speak in the clear, replying to the original sender, the
sender will have already created a policy expecting ciphertext.
Thus, the attacker will need to intercept traffic from both sides.
In some cases, the attacker may be able to accomplish the full
intercept by use of Network Addresss/Port Translation (NAT/NAPT)
technology.
Note that the danger here only applies to cases where the gateway
field of the IPSECKEY RR indicates a different entity than the owner
name of the IPSECKEY RR. In cases where the end-to-end integrity of
the IPSECKEY RR is suspect, the end client MUST restrict its use of
the IPSECKEY RR to cases where the RR owner name matches the content
of the gateway field.
Richardson Expires March 4, 2004 [Page 10]
Internet-Draft ipsecrr September 2003
5. IANA Considerations
This document updates the IANA Registry for DNS Resource Record Types
by assigning type X to the IPSECKEY record.
This document creates an IANA registry for the algorithm type field.
Values 0, 1 and 2 are defined in Section 2.3. Algorithm numbers 3
through 255 can be assigned by IETF Consensus (see RFC2434 [6]).
This document creates an IANA registry for the gateway type field.
Values 0, 1, 2 and 3 are defined in Section 2.4. Algorithm numbers 4
through 255 can be assigned by Standards Action (see RFC2434 [6]).
Richardson Expires March 4, 2004 [Page 11]
Internet-Draft ipsecrr September 2003
6. Acknowledgments
My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
Austein, and Olafur Gurmundsson who reviewed this document carefully.
Additional thanks to Olafur Gurmundsson for a reference
implementation.
Richardson Expires March 4, 2004 [Page 12]
Internet-Draft ipsecrr September 2003
Normative references
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, September
1993.
[4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[5] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Richardson Expires March 4, 2004 [Page 13]
Internet-Draft ipsecrr September 2003
Non-normative references
[7] Thomson, S. and C. Huitema, "DNS Extensions to support IP
version 6", RFC 1886, December 1995.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
[10] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[11] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
System (DNS)", RFC 3110, May 2001.
[13] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
Record (RR)", RFC 3445, December 2002.
Author's Address
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa, ON K1Z 5V7
CA
EMail: mcr@sandelman.ottawa.on.ca
URI: http://www.sandelman.ottawa.on.ca/
Richardson Expires March 4, 2004 [Page 14]
Internet-Draft ipsecrr September 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Richardson Expires March 4, 2004 [Page 15]

1203
doc/draft-spencer-ipsec-ike-implementation.nr Normal file
View File

File diff suppressed because it is too large Load Diff

1232
doc/draft-spencer-ipsec-ike-implementation.txt Normal file
View File

File diff suppressed because it is too large Load Diff

182
doc/examples Normal file
View File

@ -0,0 +1,182 @@
# sample connections
# This file is RCSID $Id: examples,v 1.1 2004/03/15 20:35:21 as Exp $
# basic configuration
config setup
# THIS SETTING MUST BE CORRECT or almost nothing will work.
interfaces="ipsec0=eth1 ipsec1=ppp0"
# Debug-logging controls: "none" for (almost) none, "all" for lots.
klipsdebug=none
plutodebug=none
# Manual connections to be started at startup.
manualstart="test1 test2"
# Auto connections to be loaded into Pluto at startup.
plutoload="samplehth samplefire"
# Auto connections to be started at startup.
plutostart=samplefire
# defaults for subsequent connection descriptions
conn %default
# How persistent to be in (re)keying negotiations (0 means very).
keyingtries=0
# Parameters for manual-keying testing (DON'T USE OPERATIONALLY).
spi=0x200
esp=3des-md5-96
espenckey=0x01234567_89abcdef_02468ace_13579bdf_12345678_9abcdef0
espauthkey=0x12345678_9abcdef0_2468ace0_13579bdf
# key lifetime (before automatic rekeying)
keylife=8h
# sample connection
conn sample
# Left security gateway and subnet behind it.
left=10.0.0.1
leftsubnet=172.16.0.0/24
# Right security gateway and subnet behind it.
right=10.12.12.1
rightsubnet=192.168.0.0/24
# Authorize this connection, but don't actually start it, at startup.
auto=add
# sample tunnel (manually or automatically keyed)
# Here we just use ESP for both encryption and authentication, which is
# the simplest and often the best method.
conn sample
# left security gateway (public-network address)
left=10.0.0.1
# next hop to reach right
leftnexthop=10.44.55.66
# subnet behind left (omit if left end of the tunnel is just the s.g.)
leftsubnet=172.16.0.0/24
# right s.g., subnet behind it, and next hop to reach left
right=10.12.12.1
rightnexthop=10.88.77.66
rightsubnet=192.168.0.0/24
# (manual) SPI number
spi=0x200
# (manual) encryption/authentication algorithm and parameters to it
esp=3des-md5-96
espenckey=[192 bits]
espauthkey=[128 bits]
# In the remaining examples, deviations from the sample-tunnel configuration
# are marked with ###.
# sample host-to-host tunnel (no subnets)
# Here we assume (for purposes of illustration) that the hosts talk directly
# to each other, so we don't need next-hop settings.
conn samplehth
### left host (public-network address)
left=10.0.0.1
### next hop to reach right
leftnexthop=
### right host
right=10.12.12.1
### next hop to reach left
rightnexthop=
### (manual) SPI number
spi=0x300
# (manual) encryption/authentication algorithm and parameters to it
esp=3des-md5-96
espenckey=[192 bits]
espauthkey=[128 bits]
# sample hybrid tunnel, with a host on one end and a subnet (behind a
# security gateway) on the other
# This case is also sometimes called "road warrior".
conn samplehyb
### left host (public-network address)
left=10.0.0.1
# next hop to reach right
leftnexthop=10.44.55.66
# subnet behind left
leftsubnet=172.16.0.0/24
### right host, and next hop to reach left
right=10.12.12.1
rightnexthop=10.88.77.66
### (manual) SPI number
spi=0x400
# (manual) encryption/authentication algorithm and parameters to it
esp=3des-md5-96
espenckey=[192 bits]
espauthkey=[128 bits]
# sample firewall-penetrating tunnel
# Here we assume that firewalling is being done on the left side.
conn samplefire
# left security gateway (public-network address)
left=10.0.0.1
# next hop to reach right
leftnexthop=10.44.55.66
# subnet behind left (omit if left end of the tunnel is just the s.g.)
leftsubnet=172.16.0.0/24
### left is firewalling for its subnet
leftfirewall=yes
# right s.g., subnet behind it, and next hop to reach left
right=10.12.12.1
rightnexthop=10.88.77.66
rightsubnet=192.168.0.0/24
### (manual) SPI number
spi=0x500
# (manual) encryption/authentication algorithm and parameters to it
esp=3des-md5-96
espenckey=[192 bits]
espauthkey=[128 bits]
# sample transport-mode connection (which can only be host-to-host)
# Here we use the whole nine yards, with encryption done by ESP and
# authentication by AH; this perhaps is slightly preferable for transport
# mode, where the IP headers are exposed.
conn sampletm
### transport mode rather than tunnel
type=transport
### left host (public-network address)
left=10.0.0.1
# next hop to reach right
leftnexthop=10.44.55.66
### right host, and next hop to reach left
right=10.12.12.1
rightnexthop=10.88.77.66
### (manual) SPI number
spi=0x600
### (manual) encryption algorithm and parameters to it
esp=3des
espenckey=[192 bits]
### (manual) authentication algorithm and parameters to it
ah=hmac-md5
ahkey=[128 bits]
### (auto) authentication control
auth=ah
# sample description with keys split out into a separate section
# Normally the key section would go in a separate file, with tighter
# permissions set on it.
conn samplesep
# left security gateway (public-network address)
left=10.0.0.1
# next hop to reach right
leftnexthop=10.44.55.66
# subnet behind left (omit if left end of the tunnel is just the s.g.)
leftsubnet=172.16.0.0/24
# right s.g., subnet behind it, and next hop to reach left
right=10.12.12.1
rightnexthop=10.88.77.66
rightsubnet=192.168.0.0/24
### (manual) SPI number
spi=0x700
# (manual) encryption/authentication algorithm and parameters to it
esp=3des-md5-96
also=samplesep-keys
# keys for the previous section
# Normally this would go in a separate file, picked up using an include line,
# to allow keeping the keys confidential.
conn samplesep-keys
espenckey=[192 bits]
espauthkey=[128 bits]

2339
doc/faq.html Normal file
View File

File diff suppressed because it is too large Load Diff

767
doc/firewall.html Normal file
View File

@ -0,0 +1,767 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="manpages.html">Previous</A>
<A HREF="trouble.html">Next</A>
<HR>
<H1><A name="firewall">FreeS/WAN and firewalls</A></H1>
<P>FreeS/WAN, or other IPsec implementations, frequently run on gateway
machines, the same machines running firewall or packet filtering code.
This document discusses the relation between the two.</P>
<P>The firewall code in 2.4 and later kernels is called Netfilter. The
user-space utility to manage a firewall is iptables(8). See the<A href="http://netfilter.samba.org">
netfilter/iptables web site</A> for details.</P>
<H2><A name="filters">Filtering rules for IPsec packets</A></H2>
<P>The basic constraint is that<STRONG> an IPsec gateway must have
packet filters that allow IPsec packets</STRONG>, at least when talking
to other IPsec gateways:</P>
<UL>
<LI>UDP port 500 for<A href="glossary.html#IKE"> IKE</A> negotiations</LI>
<LI>protocol 50 if you use<A href="glossary.html#ESP"> ESP</A>
encryption and/or authentication (the typical case)</LI>
<LI>protocol 51 if you use<A href="glossary.html#AH"> AH</A>
packet-level authentication</LI>
</UL>
<P>Your gateway and the other IPsec gateways it communicates with must
be able to exchange these packets for IPsec to work. Firewall rules
must allow UDP 500 and at least one of<A href="glossary.html#AH"> AH</A>
or<A href="glossary.html#ESP"> ESP</A> on the interface that
communicates with the other gateway.</P>
<P>For nearly all FreeS/WAN applications, you must allow UDP port 500
and the ESP protocol.</P>
<P>There are two ways to set this up:</P>
<DL>
<DT>easier but less flexible</DT>
<DD>Just set up your firewall scripts at boot time to allow IPsec
packets to and from your gateway. Let FreeS/WAN reject any bogus
packets.</DD>
<DT>more work, giving you more precise control</DT>
<DD>Have the<A href="manpage.d/ipsec_pluto.8.html"> ipsec_pluto(8)</A>
daemon call scripts to adjust firewall rules dynamically as required.
This is done by naming the scripts in the<A href="manpage.d/ipsec.conf.5.html">
ipsec.conf(5)</A> variables<VAR> prepluto=</VAR>,<VAR> postpluto=</VAR>
,<VAR> leftupdown=</VAR> and<VAR> rightupdown=</VAR>.</DD>
</DL>
<P>Both methods are described in more detail below.</P>
<H2><A name="examplefw">Firewall configuration at boot</A></H2>
<P>It is possible to set up both firewalling and IPsec with appropriate
scripts at boot and then not use<VAR> leftupdown=</VAR> and<VAR>
rightupdown=</VAR>, or use them only for simple up and down operations.</P>
<P>Basically, the technique is</P>
<UL>
<LI>allow IPsec packets (typically, IKE on UDP port 500 plus ESP,
protocol 50)
<UL>
<LI>incoming, if the destination address is your gateway (and
optionally, only from known senders)</LI>
<LI>outgoing, with the from address of your gateway (and optionally,
only to known receivers)</LI>
</UL>
</LI>
<LI>let<A href="glossary.html#Pluto"> Pluto</A> deal with IKE</LI>
<LI>let<A href="glossary.html#KLIPS"> KLIPS</A> deal with ESP</LI>
</UL>
<P>Since Pluto authenticates its partners during the negotiation, and
KLIPS drops packets for which no tunnel has been negotiated, this may
be all you need.</P>
<H3><A name="simple.rules">A simple set of rules</A></H3>
<P>In simple cases, you need only a few rules, as in this example:</P>
<PRE># allow IPsec
#
# IKE negotiations
iptables -I INPUT -p udp --sport 500 --dport 500 -j ACCEPT
iptables -I OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
# ESP encryption and authentication
iptables -I INPUT -p 50 -j ACCEPT
iptables -I OUTPUT -p 50 -j ACCEPT
</PRE>
<P>This should be all you need to allow IPsec through<VAR> lokkit</VAR>,
which ships with Red Hat 9, on its medium security setting. Once you've
tweaked to your satisfaction, save your active rule set with:</P>
<PRE>service iptables save</PRE>
<H3><A name="complex.rules">Other rules</A></H3>
You can add additional rules, or modify existing ones, to work with
IPsec and with your network and policies. We give a some examples in
this section.
<P>However, while it is certainly possible to create an elaborate set of
rules yourself (please let us know via the<A href="mail.html"> mailing
list</A> if you do), it may be both easier and more secure to use a set
which has already been published and tested.</P>
<P>The published rule sets we know of are described in the<A href="#rules.pub">
next section</A>.</P>
<H4>Adding additional rules</H4>
If necessary, you can add additional rules to:
<DL>
<DT>reject IPsec packets that are not to or from known gateways</DT>
<DD>This possibility is discussed in more detail<A href="#unknowngate">
later</A></DD>
<DT>allow systems behind your gateway to build IPsec tunnels that pass
through the gateway</DT>
<DD>This possibility is discussed in more detail<A href="#through">
later</A></DD>
<DT>filter incoming packets emerging from KLIPS.</DT>
<DD>Firewall rules can recognise packets emerging from IPsec. They are
marked as arriving on an interface such as<VAR> ipsec0</VAR>, rather
than<VAR> eth0</VAR>,<VAR> ppp0</VAR> or whatever.</DD>
</DL>
<P>It is therefore reasonably straightforward to filter these packets in
whatever way suits your situation.</P>
<H4>Modifying existing rules</H4>
<P>In some cases rules that work fine before you add IPsec may require
modification to work with IPsec.</P>
<P>This is especially likely for rules that deal with interfaces on the
Internet side of your system. IPsec adds a new interface; often the
rules must change to take account of that.</P>
<P>For example, consider the rules given in<A href="http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-5.html">
this section</A> of the Netfilter documentation:</P>
<PRE>Most people just have a single PPP connection to the Internet, and don't
want anyone coming back into their network, or the firewall:
## Insert connection-tracking modules (not needed if built into kernel).
# insmod ip_conntrack
# insmod ip_conntrack_ftp
## Create chain which blocks new connections, except if coming from inside.
# iptables -N block
# iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
# iptables -A block -j DROP
## Jump to that chain from INPUT and FORWARD chains.
# iptables -A INPUT -j block
# iptables -A FORWARD -j block</PRE>
<P>On an IPsec gateway, those rules may need to be modified. The above
allows new connections from<EM> anywhere except ppp0</EM>. That means
new connections from ipsec0 are allowed.</P>
<P>Do you want to allow anyone who can establish an IPsec connection to
your gateway to initiate TCP connections to any service on your
network? Almost certainly not if you are using opportunistic
encryption. Quite possibly not even if you have only explicitly
configured connections.</P>
<P>To disallow incoming connections from ipsec0, change the middle
section above to:</P>
<PRE> ## Create chain which blocks new connections, except if coming from inside.
# iptables -N block
# iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A block -m state --state NEW -i ppp+ -j DROP
# iptables -A block -m state --state NEW -i ipsec+ -j DROP
# iptables -A block -m state --state NEW -i -j ACCEPT
# iptables -A block -j DROP</PRE>
<P>The original rules accepted NEW connections from anywhere except
ppp0. This version drops NEW connections from any PPP interface (ppp+)
and from any ipsec interface (ipsec+), then accepts the survivors.</P>
<P>Of course, these are only examples. You will need to adapt them to
your own situation.</P>
<H3><A name="rules.pub">Published rule sets</A></H3>
<P>Several sets of firewall rules that work with FreeS/WAN are
available.</P>
<H4><A name="Ranch.trinity">Scripts based on Ranch's work</A></H4>
<P>One user, Rob Hutton, posted his boot time scripts to the mailing
list, and we included them in previous versions of this documentation.
They are still available from our<A href="http://www.freeswan.org/freeswan_trees/freeswan-1.5/doc/firewall.html#examplefw">
web site</A>. However, they were for an earlier FreeS/WAN version so we
no longer recommend them. Also, they had some bugs. See this<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/04/msg00316.html">
message</A>.</P>
<P>Those scripts were based on David Ranch's scripts for his &quot;Trinity
OS&quot; for setting up a secure Linux. Check his<A href="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html">
home page</A> for the latest version and for information on his<A href="biblio.html#ranch">
book</A> on securing Linux. If you are going to base your firewalling
on Ranch's scripts, we recommend using his latest version, and sending
him any IPsec modifications you make for incorporation into later
versions.</P>
<H4><A name="seawall">The Seattle firewall</A></H4>
<P>We have had several mailing lists reports of good results using
FreeS/WAN with Seawall (the Seattle Firewall). See that project's<A href="http://seawall.sourceforge.net/">
home page</A> on Sourceforge.</P>
<H4><A name="rcf">The RCF scripts</A></H4>
<P>Another set of firewall scripts with IPsec support are the RCF or
rc.firewall scripts. See their<A href="http://jsmoriss.mvlan.net/linux/rcf.html">
home page</A>.</P>
<H4><A name="asgard">Asgard scripts</A></H4>
<P><A href="http://heimdall.asgardsrealm.net/linux/firewall/">Asgard's
Realm</A> has set of firewall scripts with FreeS/WAN support, for 2.4
kernels and iptables.</P>
<H4><A name="user.scripts">User scripts from the mailing list</A></H4>
<P>One user gave considerable detail on his scripts, including
supporting<A href="glossary.html#IPX"> IPX</A> through the tunnel. His
message was too long to conveniently be quoted here, so I've put it in
a<A href="user_examples.html"> separate file</A>.</P>
<H2><A name="updown">Calling firewall scripts, named in ipsec.conf(5)</A>
</H2>
<P>The<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A>
configuration file has three pairs of parameters used to specify an
interface between FreeS/WAN and firewalling code.</P>
<P>Note that using these is not required if you have a static firewall
setup. In that case, you just set your firewall up at boot time (in a
way that permits the IPsec connections you want) and do not change it
thereafter. Omit all the FreeS/WAN firewall parameters and FreeS/WAN
will not attempt to adjust firewall rules at all. See<A href="#examplefw">
above</A> for some information on appropriate scripts.</P>
<P>However, if you want your firewall rules to change when IPsec
connections change, then you need to use these parameters.</P>
<H3><A name="pre_post">Scripts called at IPsec start and stop</A></H3>
<P>One pair of parmeters are set in the<VAR> config setup</VAR> section
of the<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A> file and
affect all connections:</P>
<DL>
<DT>prepluto=</DT>
<DD>script to be called before<A href="manpage.d/ipsec_pluto.8.html">
pluto(8)</A> IKE daemon is started.</DD>
<DT>postpluto=</DT>
<DD>script to be called after<A href="manpage.d/ipsec_pluto.8.html">
pluto(8)</A> IKE daemon is stopped.</DD>
</DL>
These parameters allow you to change firewall parameters whenever IPsec
is started or stopped.
<P>They can also be used in other ways. For example, you might have<VAR>
prepluto</VAR> add a module to your kernel for the secure network
interface or make a dialup connection, and then have<VAR> postpluto</VAR>
remove the module or take the connection down.</P>
<H3><A name="up_down">Scripts called at connection up and down</A></H3>
<P>The other parameters are set in connection descriptions. They can be
set in individual connection descriptions, and could even call
different scripts for each connection for maximum flexibility. In most
applications, however, it makes sense to use only one script and to
call it from<VAR> conn %default</VAR> section so that it applies to all
connections.</P>
<P>You can:</P>
<DL>
<DT><STRONG>either</STRONG></DT>
<DD>set<VAR> leftfirewall=yes</VAR> or<VAR> rightfirewall=yes</VAR> to
use our supplied default script</DD>
<DT><STRONG>or</STRONG></DT>
<DD>assign a name in a<VAR> leftupdown=</VAR> or<VAR> rightupdown=</VAR>
line to use your own script</DD>
</DL>
<P>Note that<STRONG> only one of these should be used</STRONG>. You
cannot sensibly use both. Since<STRONG> our default script is obsolete</STRONG>
(designed for firewalls using<VAR> ipfwadm(8)</VAR> on 2.0 kernels),
most users who need this service will<STRONG> need to write a custom
script</STRONG>.</P>
<H4><A name="fw.default">The default script</A></H4>
<P>We supply a default script named<VAR> _updown</VAR>.</P>
<DL>
<DT>leftfirewall=</DT>
<DD></DD>
<DT>rightfirewall=</DT>
<DD>indicates that the gateway is doing firewalling and that<A href="manpage.d/ipsec_pluto.8.html">
pluto(8)</A> should poke holes in the firewall as required.</DD>
</DL>
<P>Set these to<VAR> yes</VAR> and Pluto will call our default script<VAR>
_updown</VAR> with appropriate arguments whenever it:</P>
<UL>
<LI>starts or stops IPsec services</LI>
<LI>brings a connection up or down</LI>
</UL>
<P>The supplied default<VAR> _updown</VAR> script is appropriate for
simple cases using the<VAR> ipfwadm(8)</VAR> firewalling package.</P>
<H4><A name="userscript">User-written scripts</A></H4>
<P>You can also write your own script and have Pluto call it. Just put
the script's name in one of these<A href="manpage.d/ipsec.conf.5.html">
ipsec.conf(5)</A> lines:</P>
<DL>
<DT>leftupdown=</DT>
<DD></DD>
<DT>rightupdown=</DT>
<DD>specifies a script to call instead of our default script<VAR>
_updown</VAR>.</DD>
</DL>
<P>Your script should take the same arguments and use the same
environment variables as<VAR> _updown</VAR>. See the &quot;updown command&quot;
section of the<A href="manpage.d/ipsec_pluto.8.html"> ipsec_pluto(8)</A>
man page for details.</P>
<P>Note that<STRONG> you should not modify our _updown script in place</STRONG>
. If you did that, then upgraded FreeS/WAN, the upgrade would install a
new default script, overwriting your changes.</P>
<H3><A name="ipchains.script">Scripts for ipchains or iptables</A></H3>
<P>Our<VAR> _updown</VAR> is for firewalls using<VAR> ipfwadm(8)</VAR>,
the firewall code for the 2.0 series of Linux kernels. If you are using
the more recent packages<VAR> ipchains(8)</VAR> (for 2.2 kernels) or<VAR>
iptables(8)</VAR> (2.4 kernels), then you must do one of:</P>
<UL>
<LI>use static firewall rules which are set up at boot time as described<A
href="#examplefw"> above</A> and do not need to be changed by Pluto</LI>
<LI>limit yourself to ipchains(8)'s ipfwadm(8) emulation mode in order
to use our script</LI>
<LI>write your own script and call it with<VAR> leftupdown</VAR> and<VAR>
rightupdown</VAR>.</LI>
</UL>
<P>You can write a script to do whatever you need with firewalling.
Specify its name in a<VAR> [left|right]updown=</VAR> parameter in<A href="manpage.d/ipsec.conf.5.html">
ipsec.conf(5)</A> and Pluto will automatically call it for you.</P>
<P>The arguments Pluto passes such a script are the same ones it passes
to our default _updown script, so the best way to build yours is to
copy ours and modify the copy.</P>
<P>Note, however, that<STRONG> you should not modify our _updown script
in place</STRONG>. If you did that, then upgraded FreeS/WAN, the
upgrade would install a new default script, overwriting your changes.</P>
<H2><A name="NAT">A complication: IPsec vs. NAT</A></H2>
<P><A href="glossary.html#NAT.gloss">Network Address Translation</A>,
also known as IP masquerading, is a method of allocating IP addresses
dynamically, typically in circumstances where the total number of
machines which need to access the Internet exceeds the supply of IP
addresses.</P>
<P>Any attempt to perform NAT operations on IPsec packets<EM> between
the IPsec gateways</EM> creates a basic conflict:</P>
<UL>
<LI>IPsec wants to authenticate packets and ensure they are unaltered on
a gateway-to-gateway basis</LI>
<LI>NAT rewrites packet headers as they go by</LI>
<LI>IPsec authentication fails if packets are rewritten anywhere between
the IPsec gateways</LI>
</UL>
<P>For<A href="glossary.html#AH"> AH</A>, which authenticates parts of
the packet header including source and destination IP addresses, this
is fatal. If NAT changes those fields, AH authentication fails.</P>
<P>For<A href="glossary.html#IKE"> IKE</A> and<A href="glossary.html#ESP">
ESP</A> it is not necessarily fatal, but is certainly an unwelcome
complication.</P>
<H3><A name="nat_ok">NAT on or behind the IPsec gateway works</A></H3>
<P>This problem can be avoided by having the masquerading take place<EM>
on or behind</EM> the IPsec gateway.</P>
<P>This can be done physically with two machines, one physically behind
the other. A picture, using SG to indicate IPsec<STRONG> S</STRONG>
ecurity<STRONG> G</STRONG>ateways, is:</P>
<PRE> clients --- NAT ----- SG ---------- SG
two machines</PRE>
<P>In this configuration, the actual client addresses need not be given
in the<VAR> leftsubnet=</VAR> parameter of the FreeS/WAN connection
description. The security gateway just delivers packets to the NAT box;
it needs only that machine's address. What that machine does with them
does not affect FreeS/WAN.</P>
<P>A more common setup has one machine performing both functions:</P>
<PRE> clients ----- NAT/SG ---------------SG
one machine</PRE>
<P>Here you have a choice of techniques depending on whether you want to
make your client subnet visible to clients on the other end:</P>
<UL>
<LI>If you want the single gateway to behave like the two shown above,
with your clients hidden behind the NAT, then omit the<VAR> leftsubnet=</VAR>
parameter. It then defaults to the gateway address. Clients on the
other end then talk via the tunnel only to your gateway. The gateway
takes packets emerging from the tunnel, applies normal masquerading,
and forwards them to clients.</LI>
<LI>If you want to make your client machines visible, then give the
client subnet addresses as the<VAR> leftsubnet=</VAR> parameter in the
connection description and
<DL>
<DT>either</DT>
<DD>set<VAR> leftfirewall=yes</VAR> to use the default<VAR> updown</VAR>
script</DD>
<DT>or</DT>
<DD>use your own script by giving its name in a<VAR> leftupdown=</VAR>
parameter</DD>
</DL>
These scripts are described in their own<A href="#updown"> section</A>.
<P>In this case, no masquerading is done. Packets to or from the client
subnet are encrypted or decrypted without any change to their client
subnet addresses, although of course the encapsulating packets use
gateway addresses in their headers. Clients behind the right security
gateway see a route via that gateway to the left subnet.</P>
</LI>
</UL>
<H3><A name="nat_bad">NAT between gateways is problematic</A></H3>
<P>We recommend not trying to build IPsec connections which pass through
a NAT machine. This setup poses problems:</P>
<PRE> clients --- SG --- NAT ---------- SG</PRE>
<P>If you must try it, some references are:</P>
<UL>
<LI>Jean_Francois Nadeau's document on doing<A href="http://jixen.tripod.com/#NATed gateways">
IPsec behind NAT</A></LI>
<LI><A href="web.html#VPN.masq">VPN masquerade patches</A> to make a
Linux NAT box handle IPsec packets correctly</LI>
</UL>
<H3><A name="NAT.ref">Other references on NAT and IPsec</A></H3>
<P>Other documents which may be relevant include:</P>
<UL>
<LI>an Internet Draft on<A href="http://search.ietf.org/internet-drafts/draft-aboba-nat-ipsec-04.txt">
IPsec and NAT</A> which may eventually evolve into a standard solution
for this problem.</LI>
<LI>an informational<A href="http://www.cis.ohio-state.edu/rfc/rfc2709.txt">
RFC</A>,<CITE> Security Model with Tunnel-mode IPsec for NAT Domains</CITE>
.</LI>
<LI>an<A href="http://www.cisco.com/warp/public/759/ipj_3-4/ipj_3-4_nat.html">
article</A> in Cisco's<CITE> Internet Protocol Journal</CITE></LI>
</UL>
<H2><A name="complications">Other complications</A></H2>
<P>Of course simply allowing UDP 500 and ESP packets is not the whole
story. Various other issues arise in making IPsec and packet filters
co-exist and even co-operate. Some of them are summarised below.</P>
<H3><A name="through">IPsec<EM> through</EM></A> the gateway</H3>
<P>Basic IPsec packet filtering rules deal only with packets addressed
to or sent from your IPsec gateway.</P>
<P>It is a separate policy decision whether to permit such packets to
pass through the gateway so that client machines can build end-to-end
IPsec tunnels of their own. This may not be practical if you are using<A
href="#NAT"> NAT (IP masquerade)</A> on your gateway, and may conflict
with some corporate security policies.</P>
<P>Where possible, allowing this is almost certainly a good idea. Using
IPsec on an end-to-end basis is more secure than gateway-to-gateway.</P>
<P>Doing it is quite simple. You just need firewall rules that allow UDP
port 500 and protocols 50 and 51 to pass through your gateway. If you
wish, you can of course restrict this to certain hosts.</P>
<H3><A name="ipsec_only">Preventing non-IPsec traffic</A></H3>
You can also filter<EM> everything but</EM> UDP port 500 and ESP or AH
to restrict traffic to IPsec only, either for anyone communicating with
your host or just for specific partners.
<P>One application of this is for the telecommuter who might have:</P>
<PRE> Sunset==========West------------------East ================= firewall --- the Internet
home network untrusted net corporate network</PRE>
<P>The subnet on the right is 0.0.0.0/0, the whole Internet. The West
gateway is set up so that it allows only IPsec packets to East in or
out.</P>
<P>This configuration is used in AT&amp;T Research's network. For details,
see the<A href="intro.html#applied"> papers</A> links in our
introduction.</P>
<P>Another application would be to set up firewall rules so that an
internal machine, such as an employees-only web server, could not talk
to the outside world except via specific IPsec tunnels.</P>
<H3><A name="unknowngate">Filtering packets from unknown gateways</A></H3>
<P>It is possible to use firewall rules to restrict UDP 500, ESP and AH
packets so that these packets are accepted only from known gateways.
This is not strictly necessary since FreeS/WAN will discard packets
from unknown gateways. You might, however, want to do it for any of a
number of reasons. For example:</P>
<UL>
<LI>Arguably, &quot;belt and suspenders&quot; is the sensible approach to
security. If you can block a potential attack in two ways, use both.
The only question is whether to look for a third way after implementing
the first two.</LI>
<LI>Some admins may prefer to use the firewall code this way because
they prefer firewall logging to FreeS/WAN's logging.</LI>
<LI>You may need it to implement your security policy. Consider an
employee working at home, and a policy that says traffic from the home
system to the Internet at large must go first via IPsec to the
corporate LAN and then out to the Internet via the corporate firewall.
One way to do that is to make<VAR> ipsec0</VAR> the default route on
the home gateway and provide exceptions only for UDP 500 and ESP to the
corporate gateway. Everything else is then routed via the tunnel to the
corporate gateway.</LI>
</UL>
<P>It is not possible to use only static firewall rules for this
filtering if you do not know the other gateways' IP addresses in
advance, for example if you have &quot;road warriors&quot; who may connect from a
different address each time or if want to do<A href="glossary.html#carpediem">
opportunistic encryption</A> to arbitrary gateways. In these cases, you
can accept UDP 500 IKE packets from anywhere, then use the<A href="#updown">
updown</A> script feature of<A href="manpage.d/ipsec_pluto.8.html">
pluto(8)</A> to dynamically adjust firewalling for each negotiated
tunnel.</P>
<P>Firewall packet filtering does not much reduce the risk of a<A href="glossary.html#DOS">
denial of service attack</A> on FreeS/WAN. The firewall can drop
packets from unknown gateways, but KLIPS does that quite efficiently
anyway, so you gain little. The firewall cannot drop otherwise
legitmate packets that fail KLIPS authentication, so it cannot protect
against an attack designed to exhaust resources by making FreeS/WAN
perform many expensive authentication operations.</P>
<P>In summary, firewall filtering of IPsec packets from unknown gateways
is possible but not strictly necessary.</P>
<H2><A name="otherfilter">Other packet filters</A></H2>
<P>When the IPsec gateway is also acting as your firewall, other packet
filtering rules will be in play. In general, those are outside the
scope of this document. See our<A href="web.html#firewall.linux"> Linux
firewall links</A> for information. There are a few types of packet,
however, which can affect the operation of FreeS/WAN or of diagnostic
tools commonly used with it. These are discussed below.</P>
<H3><A name="ICMP">ICMP filtering</A></H3>
<P><A href="glossary.html#ICMP.gloss">ICMP</A> is the<STRONG> I</STRONG>
nternet<STRONG> C</STRONG>ontrol<STRONG> M</STRONG>essage<STRONG> P</STRONG>
rotocol. It is used for messages between IP implementations themselves,
whereas IP used is used between the clients of those implementations.
ICMP is, unsurprisingly, used for control messages. For example, it is
used to notify a sender that a desination is not reachable, or to tell
a router to reroute certain packets elsewhere.</P>
<P>ICMP handling is tricky for firewalls.</P>
<UL>
<LI>You definitely want some ICMP messages to get through; things won't
work without them. For example, your clients need to know if some
destination they ask for is unreachable.</LI>
<LI>On the other hand, you do equally definitely do not want untrusted
folk sending arbitrary control messages to your machines. Imagine what
someone moderately clever and moderately malicious could do to you,
given control of your network's routing.</LI>
</UL>
<P>ICMP does not use ports. Messages are distinguished by a &quot;message
type&quot; field and, for some types, by an additional &quot;code&quot; field. The
definitive list of types and codes is on the<A href="http://www.iana.org">
IANA</A> site.</P>
<P>One expert uses this definition for ICMP message types to be dropped
at the firewall.</P>
<PRE># ICMP types which lack socially redeeming value.
# 5 Redirect
# 9 Router Advertisement
# 10 Router Selection
# 15 Information Request
# 16 Information Reply
# 17 Address Mask Request
# 18 Address Mask Reply
badicmp='5 9 10 15 16 17 18'</PRE>
<P>A more conservative approach would be to make a list of allowed types
and drop everything else.</P>
<P>Whichever way you do it, your ICMP filtering rules on a FreeS/WAN
gateway should allow at least the following ICMP packet types:</P>
<DL>
<DT>echo (type 8)</DT>
<DD></DD>
<DT>echo reply (type 0)</DT>
<DD>These are used by ping(1). We recommend allowing both types through
the tunnel and to or from your gateway's external interface, since
ping(1) is an essential testing tool.
<P>It is fairly common for firewalls to drop ICMP echo packets addressed
to machines behind the firewall. If that is your policy, please create
an exception for such packets arriving via an IPsec tunnel, at least
during intial testing of those tunnels.</P>
</DD>
<DT>destination unreachable (type 3)</DT>
<DD>This is used, with code 4 (Fragmentation Needed and Don't Fragment
was Set) in the code field, to control<A href="glossary.html#pathMTU">
path MTU discovery</A>. Since IPsec processing adds headers, enlarges
packets and may cause fragmentation, an IPsec gateway should be able to
send and receive these ICMP messages<STRONG> on both inside and outside
interfaces</STRONG>.</DD>
</DL>
<H3><A name="traceroute">UDP packets for traceroute</A></H3>
<P>The traceroute(1) utility uses UDP port numbers from 33434 to
approximately 33633. Generally, these should be allowed through for
troubleshooting.</P>
<P>Some firewalls drop these packets to prevent outsiders exploring the
protected network with traceroute(1). If that is your policy, consider
creating an exception for such packets arriving via an IPsec tunnel, at
least during intial testing of those tunnels.</P>
<H3><A name="l2tp">UDP for L2TP</A></H3>
<P> Windows 2000 does, and products designed for compatibility with it
may, build<A href="glossary.html#L2TP"> L2TP</A> tunnels over IPsec
connections.</P>
<P>For this to work, you must allow UDP protocol 1701 packets coming out
of your tunnels to continue to their destination. You can, and probably
should, block such packets to or from your external interfaces, but
allow them from<VAR> ipsec0</VAR>.</P>
<P>See also our Windows 2000<A href="interop.html#win2k"> interoperation
discussion</A>.</P>
<H2><A name="packets">How it all works: IPsec packet details</A></H2>
<P>IPsec uses three main types of packet:</P>
<DL>
<DT><A href="glossary.html#IKE">IKE</A> uses<STRONG> the UDP protocol
and port 500</STRONG>.</DT>
<DD>Unless you are using only (less secure, not recommended) manual
keying, you need IKE to negotiate connection parameters, acceptable
algorithms, key sizes and key setup. IKE handles everything required to
set up, rekey, repair or tear down IPsec connections.</DD>
<DT><A href="glossary.html#ESP">ESP</A> is<STRONG> protocol number 50</STRONG>
</DT>
<DD>This is required for encrypted connections.</DD>
<DT><A href="glossary.html#AH">AH</A> is<STRONG> protocol number 51</STRONG>
</DT>
<DD>This can be used where only authentication, not encryption, is
required.</DD>
</DL>
<P>All of those packets should have appropriate IPsec gateway addresses
in both the to and from IP header fields. Firewall rules can check this
if you wish, though it is not strictly necessary. This is discussed in
more detail<A href="#unknowngate"> later</A>.</P>
<P>IPsec processing of incoming packets authenticates them then removes
the ESP or AH header and decrypts if necessary. Successful processing
exposes an inner packet which is then delivered back to the firewall
machinery, marked as having arrived on an<VAR> ipsec[0-3]</VAR>
interface. Firewall rules can use that interface label to distinguish
these packets from unencrypted packets which are labelled with the
physical interface they arrived on (or perhaps with a non-IPsec virtual
interface such as<VAR> ppp0</VAR>).</P>
<P>One of our users sent a mailing list message with a<A href="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/12/msg00006.html">
diagram</A> of the packet flow.</P>
<H3><A name="noport">ESP and AH do not have ports</A></H3>
<P>Some protocols, such as TCP and UDP, have the notion of ports. Others
protocols, including ESP and AH, do not. Quite a few IPsec newcomers
have become confused on this point. There are no ports<EM> in</EM> the
ESP or AH protocols, and no ports used<EM> for</EM> them. For these
protocols,<EM> the idea of ports is completely irrelevant</EM>.</P>
<H3><A name="header">Header layout</A></H3>
<P>The protocol numbers for ESP or AH are used in the 'next header'
field of the IP header. On most non-IPsec packets, that field would
have one of:</P>
<UL>
<LI>1 for ICMP</LI>
<LI>4 for IP-in-IP encapsulation</LI>
<LI>6 for TCP</LI>
<LI>17 for UDP</LI>
<LI>... or one of about 100 other possibilities listed by<A href="http://www.iana.org">
IANA</A></LI>
</UL>
<P>Each header in the sequence tells what the next header will be. IPsec
adds headers for ESP or AH near the beginning of the sequence. The
original headers are kept and the 'next header' fields adjusted so that
all headers can be correctly interpreted.</P>
<P>For example, using<STRONG> [</STRONG><STRONG> ]</STRONG> to indicate
data protected by ESP and unintelligible to an eavesdropper between the
gateways:</P>
<UL>
<LI>a simple packet might have only IP and TCP headers with:
<UL>
<LI>IP header says next header --&gt; TCP</LI>
<LI>TCP header port number --&gt; which process to send data to</LI>
<LI>data</LI>
</UL>
</LI>
<LI>with ESP<A href="glossary.html#transport"> transport mode</A>
encapsulation, that packet would have:
<UL>
<LI>IP header says next header --&gt; ESP</LI>
<LI>ESP header<STRONG> [</STRONG> says next --&gt; TCP</LI>
<LI>TCP header port number --&gt; which process to send data to</LI>
<LI>data<STRONG> ]</STRONG></LI>
</UL>
Note that the IP header is outside ESP protection, visible to an
attacker, and that the final destination must be the gateway.</LI>
<LI>with ESP in<A href="glossary.html#tunnel"> tunnel mode</A>, we might
have:
<UL>
<LI>IP header says next header --&gt; ESP</LI>
<LI>ESP header<STRONG> [</STRONG> says next --&gt; IP</LI>
<LI>IP header says next header --&gt; TCP</LI>
<LI>TCP header port number --&gt; which process to send data to</LI>
<LI>data<STRONG> ]</STRONG></LI>
</UL>
Here the inner IP header is protected by ESP, unreadable by an
attacker. Also, the inner header can have a different IP address than
the outer IP header, so the decrypted packet can be routed from the
IPsec gateway to a final destination which may be another machine.</LI>
</UL>
<P>Part of the ESP header itself is encrypted, which is why the<STRONG>
[</STRONG> indicating protected data appears in the middle of some
lines above. The next header field of the ESP header is protected. This
makes<A href="glossary.html#traffic"> traffic analysis</A> more
difficult. The next header field would tell an eavesdropper whether
your packet was UDP to the gateway, TCP to the gateway, or encapsulated
IP. It is better not to give this information away. A clever attacker
may deduce some of it from the pattern of packet sizes and timings, but
we need not make it easy.</P>
<P>IPsec allows various combinations of these to match local policies,
including combinations that use both AH and ESP headers or that nest
multiple copies of these headers.</P>
<P>For example, suppose my employer has an IPsec VPN running between two
offices so all packets travelling between the gateways for those
offices are encrypted. If gateway policies allow it (The admins could
block UDP 500 and protocols 50 and 51 to disallow it), I can build an
IPsec tunnel from my desktop to a machine in some remote office. Those
packets will have one ESP header throughout their life, for my
end-to-end tunnel. For part of the route, however, they will also have
another ESP layer for the corporate VPN's encapsulation. The whole
header scheme for a packet on the Internet might be:</P>
<UL>
<LI>IP header (with gateway address) says next header --&gt; ESP</LI>
<LI>ESP header<STRONG> [</STRONG> says next --&gt; IP</LI>
<LI>IP header (with receiving machine address) says next header --&gt; ESP</LI>
<LI>ESP header<STRONG> [</STRONG> says next --&gt; TCP</LI>
<LI>TCP header port number --&gt; which process to send data to</LI>
<LI>data<STRONG> ]]</STRONG></LI>
</UL>
<P>The first ESP (outermost) header is for the corporate VPN. The inner
ESP header is for the secure machine-to-machine link.</P>
<H3><A name="dhr">DHR on the updown script</A></H3>
<P>Here are some mailing list comments from<A href="manpage.d/ipsec_pluto.8.html">
pluto(8)</A> developer Hugh Redelmeier on an earlier draft of this
document:</P>
<PRE>There are many important things left out
- firewalling is important but must reflect (implement) policy. Since
policy isn't the same for all our customers, and we're not experts,
we should concentrate on FW and MASQ interactions with FreeS/WAN.
- we need a diagram to show packet flow WITHIN ONE MACHINE, assuming
IKE, IPsec, FW, and MASQ are all done on that machine. The flow is
obvious if the components are run on different machines (trace the
cables).
IKE input:
+ packet appears on public IF, as UDP port 500
+ input firewalling rules are applied (may discard)
+ Pluto sees the packet.
IKE output:
+ Pluto generates the packet &amp; writes to public IF, UDP port 500
+ output firewalling rules are applied (may discard)
+ packet sent out public IF
IPsec input, with encapsulated packet, outer destination of this host:
+ packet appears on public IF, protocol 50 or 51. If this
packet is the result of decapsulation, it will appear
instead on the paired ipsec IF.
+ input firewalling rules are applied (but packet is opaque)
+ KLIPS decapsulates it, writes result to paired ipsec IF
+ input firewalling rules are applied to resulting packet
as input on ipsec IF
+ if the destination of the packet is this machine, the
packet is passed on to the appropriate protocol handler.
If the original packet was encapsulated more than once
and the new outer destination is this machine, that
handler will be KLIPS.
+ otherwise:
* routing is done for the resulting packet. This may well
direct it into KLIPS for encoding or encrypting. What
happens then is described elsewhere.
* forwarding firewalling rules are applied
* output firewalling rules are applied
* the packet is sent where routing specified
IPsec input, with encapsulated packet, outer destination of another host:
+ packet appears on some IF, protocol 50 or 51
+ input firewalling rules are applied (but packet is opaque)
+ routing selects where to send the packet
+ forwarding firewalling rules are applied (but packet is opaque)
+ packet forwarded, still encapsulated
IPsec output, from this host or from a client:
+ if from a client, input firewalling rules are applied as the
packet arrives on the private IF
+ routing directs the packet to an ipsec IF (this is how the
system decides KLIPS processing is required)
+ if from a client, forwarding firewalling rules are applied
+ KLIPS eroute mechanism matches the source and destination
to registered eroutes, yielding a SPI group. This dictates
processing, and where the resulting packet is to be sent
(the destinations SG and the nexthop).
+ output firewalling is not applied to the resulting
encapsulated packet
- Until quite recently, KLIPS would double encapsulate packets that
didn't strictly need to be. Firewalling should be prepared for
those packets showing up as ESP and AH protocol input packets on
an ipsec IF.
- MASQ processing seems to be done as if it were part of the
forwarding firewall processing (this should be verified).
- If a firewall is being used, it is likely the case that it needs to
be adjusted whenever IPsec SAs are added or removed. Pluto invokes
a script to do this (and to adjust routing) at suitable times. The
default script is only suitable for ipfwadm-managed firewalls. Under
LINUX 2.2.x kernels, ipchains can be managed by ipfwadm (emulation),
but ipchains more powerful if manipulated using the ipchains command.
In this case, a custom updown script must be used.
We think that the flexibility of ipchains precludes us supplying an
updown script that would be widely appropriate.</PRE>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="manpages.html">Previous</A>
<A HREF="trouble.html">Next</A>
</BODY>
</HTML>

2132
doc/glossary.html Normal file
View File

File diff suppressed because it is too large Load Diff

127
doc/impl.notes Normal file
View File

@ -0,0 +1,127 @@
Introduction
This document is some quick notes to sophisticated implementors, on topics
which are a bit too arcane to be mentioned in the install instructions.
Beware that it is not updated very often, and may be behind the times.
This file is RCSID $Id: impl.notes,v 1.1 2004/03/15 20:35:21 as Exp $
Where are things?
If your kernel sources are not located in /usr/src/linux, or local manual
pages are not in /usr/local/man/man[1-8], you've got a problem. You may
be able to get around it to some extent just by modifying the top-level
Makefile, but we don't promise. For a different manpage location, that
will probably suffice; for a different kernel location, probably not.
We'd welcome reports of what needs to be fixed for this.
Cross-compiling
At the moment, this distribution makes no attempt to support building
the software on one machine for use on another. That's hard, especially
since the Linux kernel sources are not set up for it at all.
One thing at a time
(CAUTION: This is somewhat outdated. It's retained because it may be a
useful guide for experts. Consult the Makefile for current details.)
If you want to do the build and install one step at a time, instead of
using the prepackaged make commands like "make menugo", do the following
instead. (We do things in a slightly different order here, to avoid
unnecessary directory changing.)
To fit the kernel part of KLIPS into the kernel sources, do:
make insert
(This makes a symbolic link /usr/src/linux/net/ipsec, pointing to the
KLIPS source directory. It patches some kernel files, where necessary, to
know about KLIPS and/or to fix bugs. It adds a default configuration to
the kernel configuration file. Finally, it makes the KLIPS communication
file, /dev/ipsec, if it's not already there.)
Build the libraries, Pluto, and various user-level utilities:
make programs
Install the Pluto daemon and user-level utilities, and set things up for
boot-time startup:
make install
Configure the kernel:
cd /usr/src/linux
make menuconfig # (or xconfig, or whatever)
See the configuration step of INSTALL for details of what to do within
the configuration program. Don't forget to save the results.
Go through the usual kernel make process (still in /usr/src/linux):
make dep clean zImage
Caution: the Linux kernel Makefiles are not always careful about checking
for errors. We recommend capturing the output of this step and searching
it for any occurrence of "error", "Error", etc. The details of how to do
so are unfortunately somewhat shell-dependent, although if you are using
the standard shell (rather than csh, tcsh, etc.), this would do:
make dep clean zImage 2>&1 | tee junk
egrep -i error junk # no output is good output
(One glitch here is that the word "error" can sometimes occur legitimately
in the make output. For example, the kernel math emulation package has a
source file "errors.c". Some judgement is required to ignore such false
alarms.) The prepackaged make commands do all this for you.
If your kernel is using loadable modules, you'll also need to do:
make modules
Now you need to install the resulting kernel. If you're not using the
kernel's "make install" -- many people aren't -- then you need to do your
usual install procedure. You might want to read doc/kernel.notes, which
recounts some of our experiences with RedHat 5.2 kernel installation in
particular.
If "make install" is good enough for you, then:
make install
(Same comments on error checking as in previous step.) If your kernel is
using loadable modules, you'll also need to do:
make modules_install
Finally, go back to INSTALL for the remaining steps.
Klips as a module
It is possible to run Klips as a kernel module, meaning that it does not
have to be loaded until needed. Formerly this was necessary, in fact,
because Klips wouldn't run any other way. Now it will, and we recommend
static linking ("y", not "m", to the configuration question) for security.
Klips is not terribly large (tens of KB, not hundreds) and should not
cause size problems unless your kernel is already pushing the limits.
However, Klips does still run as a module, if you want (although beware
that we don't test this option very often). "ipsec setup start" and
"ipsec setup stop" load and unload it as appropriate, and you should not
need to do anything about that yourself.
Old Red Hats
Our development is currently on a mix of Red Hat 6.2 and 7.1, with 6.2
fading fast. Our older Red Hats have been retired, and although FreeS/WAN
should still work on them, we no longer make any attempt to ensure that.

55
doc/index.html Normal file
View File

@ -0,0 +1,55 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html">
<title>FreeS/WAN index</title>
<meta name="keywords"
content="Linux, IPsec, VPN, security, encryption, cryptography, FreeS/WAN, FreeSWAN">
<!--
Written by Claudia Schmeing for the Linux FreeS/WAN project
Freely distributable under the GNU General Public License
More information at www.freeswan.org
Feedback to users@lists.freeswan.org
CVS information:
RCS ID: $Id: index.html,v 1.1 2004/03/15 20:35:21 as Exp $
Last changed: $Date: 2004/03/15 20:35:21 $
Revision number: $Revision: 1.1 $
CVS revision numbers do not correspond to FreeS/WAN release numbers.
-->
</head>
<body>
<h1>FreeS/WAN documentation</h1>
<ul>
<li><a href="intro.html">Introduction</a></li>
<li><a href="upgrading.html">Upgrading to 2.x</a></li>
</ul>
<ul>
<li><a href="quickstart.html">Quickstart guide to Opportunistic Encryption</a></li>
<li><a href="install.html">Installing</a></li>
<li><a href="config.html">Configuring</a></li>
<li><a href="policygroups.html">Policy Groups</a>
</li>
<li><a href="interop.html">Interoperating</a>
<FONT COLOR="#FF0000">New and improved!</FONT></li>
<li><a href="faq.html">FAQ</a></li>
<li><a href="trouble.html">Troubleshooting and problem reporting</a></li>
</ul>
<ul>
<li><a href="toc.html">Full table of contents, with much more</a></li>
<li><a href="HowTo.html">All our docs as one big file</a></li>
</ul>
<p>For technical support and other questions, use our <a
href="mail.html">mailing lists</a>.</p>
<pre> This index last changed: $Date: 2004/03/15 20:35:21 $</pre>
</body>
</html>

286
doc/install.html Normal file
View File

@ -0,0 +1,286 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="adv_config.html">Previous</A>
<A HREF="config.html">Next</A>
<HR>
<H1><A name="install">Installing FreeS/WAN</A></H1>
<P>This document will teach you how to install Linux FreeS/WAN. If your
distribution comes with Linux FreeS/WAN, we offer tips to get you
started.</P>
<H2><A NAME="15_1">Requirements</A></H2>
<P>To install FreeS/WAN you must:</P>
<UL>
<LI>be running Linux with the 2.4 or 2.2 kernel series. See this<A HREF="http://www.freeswan.ca/download.php#contact">
kernel compatibility table</A>.
<BR>We also have experimental support for 2.6 kernels. Here are two
basic approaches:
<UL>
<LI> install FreeS/WAN, including its<A HREF="ipsec.html#parts"> KLIPS</A>
kernel code. This will remove the native IPsec stack and replace it
with KLIPS.</LI>
<LI> install the FreeS/WAN<A HREF="ipsec.html#parts"> userland tools</A>
(keying daemon and supporting scripts) for use with<A HREF="http://lartc.org/howto/lartc.ipsec.html">
2.6 kernel native IPsec</A>,</LI>
</UL>
See also these<A HREF="2.6.known-issues"> known issues with 2.6</A>.</LI>
<LI>have root access to your Linux box</LI>
<LI>choose the version of FreeS/WAN you wish to install based on<A HREF="http://www.freeswan.org/mail.html">
mailing list reports</A>
<!-- or
our updates page (coming soon)-->
</LI>
</UL>
<H2><A NAME="15_2">Choose your install method</A></H2>
<P>There are three basic ways to get FreeS/WAN onto your system:</P>
<UL>
<LI>activating and testing a FreeS/WAN that<A HREF="#distroinstall">
shipped with your Linux distribution</A></LI>
<LI><A HREF="#rpminstall">RPM install</A></LI>
<LI><A HREF="#srcinstall">Install from source</A></LI>
</UL>
<A NAME="distroinstall"></A>
<H2><A NAME="15_3">FreeS/WAN ships with some Linuxes</A></H2>
<P>FreeS/WAN comes with<A HREF="intro.html#distwith"> these
distributions</A>.</P>
<P>If you're running one of these, include FreeS/WAN in the choices you
make during installation, or add it later using the distribution's
tools.</P>
<H3><A NAME="15_3_1">FreeS/WAN may be altered...</A></H3>
<P>Your distribution may have integrated extra features, such as Andreas
Steffen's X.509 patch, into FreeS/WAN. It may also use custom startup
script locations or directory names.</P>
<H3><A NAME="15_3_2">You might need to create an authentication keypair</A>
</H3>
<P>If your FreeS/WAN came with your distribution, you may wish to
generate a fresh RSA key pair. FreeS/WAN will use these keys for
authentication.</P>
<P> To do this, become root, and type:</P>
<PRE> ipsec newhostkey --output /etc/ipsec.secrets --hostname xy.example.com
chmod 600 /etc/ipsec.secrets</PRE>
<P>where you replace xy.example.com with your machine's fully-qualified
domain name. Generate some randomness, for example by wiggling your
mouse, to speed the process.</P>
<P>The resulting ipsec.secrets looks like:</P>
<PRE>: RSA {
# RSA 2192 bits xy.example.com Sun Jun 8 13:42:19 2003
# for signatures only, UNSAFE FOR ENCRYPTION
#pubkey=0sAQOFppfeE3cC7wqJi...
Modulus: 0x85a697de137702ef0...
# everything after this point is secret
PrivateExponent: 0x16466ea5033e807...
Prime1: 0xdfb5003c8947b7cc88759065...
Prime2: 0x98f199b9149fde11ec956c814...
Exponent1: 0x9523557db0da7a885af90aee...
Exponent2: 0x65f6667b63153eb69db8f300dbb...
Coefficient: 0x90ad00415d3ca17bebff123413fc518...
}
# do not change the indenting of that &quot;}&quot;</PRE>
<P>In the actual file, the strings are much longer.</P>
<H3><A NAME="15_3_3">Start and test FreeS/WAN</A></H3>
<P>You can now<A HREF="install.html#starttest"> start FreeS/WAN and test
whether it's been successfully installed.</A>.</P>
<A NAME="rpminstall"></A>
<H2><A NAME="15_4">RPM install</A></H2>
<P>These instructions are for a recent Red Hat with a stock Red Hat
kernel. We know that Mandrake and SUSE also produce FreeS/WAN RPMs. If
you're running either, install using your distribution's tools.</P>
<H3><A NAME="15_4_1">Download RPMs</A></H3>
<P>Decide which functionality you need:</P>
<UL>
<LI>standard FreeS/WAN RPMs. Use these shortcuts:
<BR>
<UL>
<LI>(for 2.6 kernels: userland only)
<BR> ncftpget
ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/\*userland*
</LI>
<LI>(for 2.4 kernels)
<BR> ncftpget
ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/`uname -r
| tr -d 'a-wy-z'`/\*</LI>
<LI> or view all the offerings at our<A href="ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs">
FTP site</A>.</LI>
</UL>
</LI>
<LI>unofficial<A href="http://www.freeswan.ca/download.php"> Super
FreeS/WAN</A> RPMs, which include Andreas Steffen's X.509 patch and
more. Super FreeS/WAN RPMs do not currently include<A HREF="glossary.html#NAT.gloss">
Network Address Translation</A> (NAT) traversal, but Super FreeS/WAN
source does.</LI>
</UL>
<A NAME="2.6.rpm"></A>
<P>For 2.6 kernels, get the latest FreeS/WAN userland RPM, for example:</P>
<PRE> freeswan-userland-2.04.9-0.i386.rpm</PRE>
<P>Note: FreeS/WAN's support for 2.6 kernel IPsec is preliminary. Please
see<A HREf="2.6.known-issues"> 2.6.known-issues</A>, and the latest<A HREF="http://www.freeswan.org/mail.html">
mailing list reports</A>.</P>
<P>Change to your new FreeS/WAN directory, and make and install the</P>
<P>For 2.4 kernels, get both kernel and userland RPMs. Check your kernel
version with</P>
<PRE> uname -r</PRE>
<P>Get a kernel module which matches that version. For example:</P>
<PRE> freeswan-module-2.04_2.4.20_20.9-0.i386.rpm</PRE>
<P>Note: These modules<B> will only work on the Red Hat kernel they were
built for</B>, since they are very sensitive to small changes in the
kernel.</P>
<P>Get FreeS/WAN utilities to match. For example:</P>
<PRE> freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm</PRE>
<H3><A NAME="15_4_2">For freeswan.org RPMs: check signatures</A></H3>
<P>While you're at our ftp site, grab the RPM signing key</P>
<PRE> freeswan-rpmsign.asc</PRE>
<P>If you're running RedHat 8.x or later, import this key into the RPM
database:</P>
<PRE> rpm --import freeswan-rpmsign.asc</PRE>
<P>For RedHat 7.x systems, you'll need to add it to your<A HREF="glossary.html#PGP">
PGP</A> keyring:</P>
<PRE> pgp -ka freeswan-rpmsign.asc</PRE>
<P>Check the digital signatures on both RPMs using:</P>
<PRE> rpm --checksig freeswan*.rpm </PRE>
<P>You should see that these signatures are good:</P>
<PRE> freeswan-module-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK
freeswan-userland-2.04_2.4.20_20.9-0.i386.rpm: pgp md5 OK</PRE>
<H3><A NAME="15_4_3">Install the RPMs</A></H3>
<P>Become root:</P>
<PRE> su</PRE>
<P>For a first time install, use:</P>
<PRE> rpm -ivh freeswan*.rpm</PRE>
<P>To upgrade existing RPMs (and keep all .conf files in place), use:</P>
<PRE> rpm -Uvh freeswan*.rpm</PRE>
<P>If you're upgrading from FreeS/WAN 1.x to 2.x RPMs, and encounter
problems, see<A HREF="upgrading.html#upgrading.rpms"> this note</A>.</P>
<H3><A NAME="15_4_4">Start and Test FreeS/WAN</A></H3>
<P>Now,<A HREF="install.html#starttest"> start FreeS/WAN and test your
install</A>.</P>
<A NAME="srcinstall"></A>
<H2><A NAME="15_5">Install from Source</A></H2>
<!-- Most of this section, along with "Start and Test", can replace
INSTALL. -->
<H3><A NAME="15_5_1">Decide what functionality you need</A></H3>
<P>Your choices are:</P>
<UL>
<LI><A HREF="ftp://ftp.xs4all.nl/pub/crypto/freeswan">standard FreeS/WAN</A>
,</LI>
<LI>standard FreeS/WAN plus any of these<A HREF="web.html#patch">
user-supported patches</A>, or</LI>
<LI><A HREF="http://www.freeswan.ca/download">Super FreeS/WAN</A>, an
unofficial FreeS/WAN pre-patched with many of the above. Provides
additional algorithms, X.509, SA deletion, dead peer detection, and<A HREF="glossary.html#NAT.gloss">
Network Address Translation</A> (NAT) traversal.</LI>
</UL>
<H3><A NAME="15_5_2">Download FreeS/WAN</A></H3>
<P>Download the source tarball you've chosen, along with any patches.</P>
<H3><A NAME="15_5_3">For freeswan.org source: check its signature</A></H3>
<P>While you're at our ftp site, get our source signing key</P>
<PRE> freeswan-sigkey.asc</PRE>
<P>Add it to your PGP keyring:</P>
<PRE> pgp -ka freeswan-sigkey.asc</PRE>
<P>Check the signature using:</P>
<PRE> pgp freeswan-2.04.tar.gz.sig freeswan-2.04.tar.gz</PRE>
<P>You should see something like:</P>
<PRE> Good signature from user &quot;Linux FreeS/WAN Software Team (build@freeswan.org)&quot;.
Signature made 2002/06/26 21:04 GMT using 2047-bit key, key ID 46EAFCE1</PRE>
<!-- Note to self: build@freeswan.org has angled brackets in the original.
Changed because it conflicts with HTML tags. -->
<H3><A NAME="15_5_4">Untar, unzip</A></H3>
<P>As root, unpack your FreeS/WAN source into<VAR> /usr/src</VAR>.</P>
<PRE> su
mv freeswan-2.04.tar.gz /usr/src
cd /usr/src
tar -xzf freeswan-2.04.tar.gz
</PRE>
<H3><A NAME="15_5_5">Patch if desired</A></H3>
<P>Now's the time to add any patches. The contributor may have special
instructions, or you may simply use the patch command.</P>
<H3><A NAME="15_5_6">... and Make</A></H3>
<P>Choose one of the methods below.</P>
<H4>Userland-only Install for 2.6 kernels</H4>
<A NAME="2.6.src"></A>
<P>Note: FreeS/WAN's support for 2.6 kernel IPsec is preliminary. Please
see<A HREf="2.6.known-issues"> 2.6.known-issues</A>, and the latest<A HREF="http://www.freeswan.org/mail.html">
mailing list reports</A>.</P>
<P>Change to your new FreeS/WAN directory, and make and install the
FreeS/WAN userland tools.</P>
<PRE> cd /usr/src/freeswan-2.04
make programs
make install</PRE>
<P>Now,<A HREF="install.html#starttest"> start FreeS/WAN and test your
install</A>.</P>
<H4>KLIPS install for 2.2, 2.4, or 2.6 kernels</H4>
<A NAME="modinstall"></A>
<P>To make a modular version of KLIPS, along with other FreeS/WAN
programs you'll need, use the command sequence below. This will change
to your new FreeS/WAN directory, make the FreeS/WAN module (and other
stuff), and install it all.</P>
<PRE> cd /usr/src/freeswan-2.04
make oldmod
make minstall</PRE>
<P><A HREF="install.html#starttest">Start FreeS/WAN and test your
install</A>.</P>
<P>To link KLIPS statically into your kernel (using your old kernel
settings), and install other FreeS/WAN components, do:</P>
<PRE> cd /usr/src/freeswan-2.04
make oldmod
make minstall</PRE>
<P>Reboot your system and<A HREF="install.html#testonly"> test your
install</A>.</P>
<P>For other ways to compile KLIPS, see our Makefile.</P>
<A name="starttest"></A>
<H2><A NAME="15_6">Start FreeS/WAN and test your install</A></H2>
<P>Bring FreeS/WAN up with:</P>
<PRE> service ipsec start</PRE>
<P>This is not necessary if you've rebooted.</P>
<A name="testonly"></A>
<H2><A NAME="15_7">Test your install</A></H2>
<P>To check that you have a successful install, run:</P>
<PRE> ipsec verify</PRE>
<P>You should see at least:</P>
<PRE>
Checking your system to see if IPsec got installed and started correctly
Version check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) [OK]
Checking that pluto is running [OK]
</PRE>
<P>If any of these first four checks fails, see our<A href="trouble.html#install.check">
troubleshooting guide</A>.</P>
<H2><A NAME="15_8">Making FreeS/WAN play well with others</A></H2>
<P>There are at least a couple of things on your system that might
interfere with FreeS/WAN, and now's a good time to check these:</P>
<UL>
<LI>Firewalling. You need to allow UDP 500 through your firewall, plus
ESP (protocol 50) and AH (protocol 51). For more information, see our
updated firewalls document (coming soon).</LI>
<LI>Network address translation. Do not NAT the packets you will be
tunneling.</LI>
</UL>
<H2><A NAME="15_9">Configure for your needs</A></H2>
<P>You'll need to configure FreeS/WAN for your local site. Have a look
at our<A HREF="quickstart.html"> opportunism quickstart guide</A> to
see if that easy method is right for your needs. Or, see how to<A HREF="config.html">
configure a network-to-network or Road Warrior style VPN</A>.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="adv_config.html">Previous</A>
<A HREF="config.html">Next</A>
</BODY>
</HTML>

983
doc/interop.html Normal file
View File

@ -0,0 +1,983 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="compat.html">Previous</A>
<A HREF="performance.html">Next</A>
<HR>
<A NAME="interop"></A>
<H1><A NAME="10">Interoperating with FreeS/WAN</A></H1>
<P>The FreeS/WAN project needs you! We rely on the user community to
keep up to date. Mail users@lists.freeswan.org with your interop
success stories.</P>
<P><STRONG>Please note</STRONG>: Most of our interop examples feature
Linux FreeS/WAN 1.x config files. You can convert them to 2.x files
fairly easily with the patch in our<A HREF="upgrading.html#ipsec.conf_v2">
Upgrading Guide</A>.</P>
<H2><A NAME="10_1">Interop at a Glance</A></H2>
<TABLE BORDER="1">
<TR><TD>&nbsp;</TD><TD colspan="5">FreeS/WAN VPN</TD><TD>Road Warrior</TD><TD>
OE</TD></TR>
<TR><TD>&nbsp;</TD><TD>PSK</TD><TD>RSA Secret</TD><TD>X.509
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
NAT-Traversal
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
Manual
<BR>Keying</TD><TD>&nbsp;</TD><TD>&nbsp;</TD></TR>
<TR><TD colspan="8">More Compatible</TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="web.html#freeswan">FreeS/WAN</A><A NAME="freeswan.top">
&nbsp;</A></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#isakmpd">isakmpd (OpenBSD)</A><A NAME="isakmpd.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>
<FONT color="#cc0000">No&nbsp;&nbsp;&nbsp;&nbsp;</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#kame">Kame (FreeBSD,
<BR> NetBSD, MacOSX)
<BR> <SMALL>aka racoon</SMALL></A><A NAME="kame.top"> &nbsp;</A></TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#mcafee">McAfee VPN
<BR><SMALL>was PGPNet</SMALL></A><A NAME="mcafee.top"> &nbsp;</A></TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#microsoft">Microsoft
<BR> Windows 2000/XP</A><A NAME="microsoft.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cc0000">
No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="glossary.html#ssh">SSH Sentinel</A><A NAME="ssh.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>&nbsp;</TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#safenet">Safenet SoftPK
<BR>/SoftRemote</A><A NAME="safenet.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cc0000">
No</FONT></TD></TR>
<TR><TD colspan="8">Other</TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#6wind">6Wind</A><A NAME="6wind.top"> &nbsp;</A></TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
<FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#alcatel">Alcatel Timestep</A><A NAME="alcatel.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#apple">Apple Macintosh
<BR>System 10+</A><A NAME="apple.top"> &nbsp;</A></TD><TD><FONT color="#cccc00">
Maybe</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cccc00">
Maybe</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#ashleylaurent">AshleyLaurent
<BR> VPCom</A><A NAME="ashleylaurent.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT
color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#borderware">Borderware</A><A NAME="borderware.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD><TD><FONT color="#cc0000">
No</FONT></TD></TR>
<!--
http://www.cequrux.com/vpn-guides.php3
"coming soon" guide to connect with FreeS/WAN.
-->
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#checkpoint">Check Point FW-1/VPN-1</A><A NAME="checkpoint.top">
&nbsp;</A></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
<FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#cisco">Cisco with 3DES</A><A NAME="cisco.top"> &nbsp;</A></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#cccc00">Maybe</FONT>
</TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#equinux">Equinux VPN Tracker
<BR> (for Mac OS X)</A><A NAME="equinux.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#fsecure">F-Secure</A><A NAME="fsecure.top"> &nbsp;</A></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">
Maybe</FONT></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#gauntlet">Gauntlet GVPN</A><A NAME="gauntlet.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">
No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#aix">IBM AIX</A><A NAME="aix.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#as400">IBM AS/400</A><A NAME="as400"> &nbsp;</A></TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#intel">Intel Shiva
<BR>LANRover/Net Structure</A><A NAME="intel.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT
color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#lancom">LanCom (formerly ELSA)</A><A NAME="lancom.top">
&nbsp;</A></TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#linksys">Linksys</A><A NAME="linksys.top"> &nbsp;</A></TD><TD>
<FONT color="#cccc00">Maybe</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">
No</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>
<FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#lucent">Lucent</A><A NAME="lucent.top"> &nbsp;</A></TD><TD><FONT
color="#cccc00">Partial</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#netasq">Netasq</A><A NAME="netasq.top"> &nbsp;</A></TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#netcelo">netcelo</A><A NAME="netcelo.top"> &nbsp;</A></TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#netgear">Netgear fvs318</A><A NAME="netgear.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#netscreen">Netscreen 100
<BR>or 5xp</A><A NAME="netscreen.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cccc00">
Maybe</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#nortel">Nortel Contivity</A><A NAME="nortel.top"> &nbsp;</A>
</TD><TD><FONT color="#cccc00">Partial</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#radguard">RadGuard</A><A NAME="radguard.top"> &nbsp;</A></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#raptor">Raptor</A><A NAME="raptor"> &nbsp;</A></TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#redcreek">Redcreek Ravlin</A><A NAME="redcreek.top"> &nbsp;</A>
</TD><TD><FONT color="#00cc00">Yes</FONT><FONT color="#cccc00">/Partial</FONT>
</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">
No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#sonicwall">SonicWall</A><A NAME="sonicwall.top"> &nbsp;</A></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT
color="#cccc00">Maybe</FONT></TD><TD><FONT color="#cc0000">No</FONT></TD><TD>
<FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#sun">Sun Solaris</A><A NAME="sun.top"> &nbsp;</A></TD><TD><FONT
color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT>
</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT
color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#symantec">Symantec</A><A NAME="symantec.top"> &nbsp;</A></TD><TD>
<FONT color="#00cc00">Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>
&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#watchguard">Watchguard
<BR> Firebox</A><A NAME="watchguard.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD><FONT color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#xedia">Xedia Access Point
<BR>/QVPN</A><A NAME="xedia.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT
color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
<TR><TD><A HREF="#zyxel">Zyxel Zywall
<BR>/Prestige</A><A NAME="zyxel.top"> &nbsp;</A></TD><TD><FONT color="#00cc00">
Yes</FONT></TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD>&nbsp;</TD><TD><FONT
color="#cc0000">No</FONT></TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE
<TR>
<TD><A HREF="#sample">sample</A></TD>
<TD>&nbsp;</TD>
<TD>&nbsp;</TD>
<TD>&nbsp;</TD>
<TD>&nbsp;</TD>
<TD>&nbsp;</TD>
<TD>&nbsp;</TD>
<TD><FONT color="#cc0000">No</FONT></TD>
</TR>
-->
<TR><TD>&nbsp;</TD><TD>PSK</TD><TD>RSA Secret</TD><TD>X.509
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
NAT-Traversal
<BR><SMALL><A HREF="#interoprules">(requires patch)</A></SMALL></TD><TD>
Manual
<BR>Keying</TD><TD>&nbsp;</TD><TD>&nbsp;</TD></TR>
<TR><TD>&nbsp;</TD><TD colspan="5">FreeS/WAN VPN</TD><TD>Road Warrior</TD><TD>
OE</TD></TR>
<!-- PSK RSA X.509 NAT-T Manual RW OE -->
</TABLE>
<H3><A NAME="10_1_1">Key</A></H3>
<TABLE BORDER="1">
<TR><TD><FONT color="#00cc00">Yes</FONT></TD><TD>People report that this
works for them.</TD></TR>
<TR><TD>[Blank]</TD><TD>We don't know.</TD></TR>
<TR><TD><FONT color="#cc0000">No</FONT></TD><TD>We have reason to
believe it was, at some point, not possible to get this to work.</TD></TR>
<TR><TD><FONT color="#cccc00">Partial</FONT></TD><TD>Partial success.
For example, a connection can be created from one end only.</TD></TR>
<TR><TD><FONT color="#00cc00">Yes</FONT><FONT color="#cccc00">/Partial</FONT>
</TD><TD>Mixed reports.</TD></TR>
<TR><TD><FONT color="#cccc00">Maybe</FONT></TD><TD>We think the answer
is &quot;yes&quot;, but need confirmation.</TD></TR>
</TABLE>
<A NAME="interoprules"></A>
<H2><A NAME="10_2">Basic Interop Rules</A></H2>
<P>Vanilla FreeS/WAN implements<A HREF="compat.html#compat"> these parts</A>
of the IPSec specifications. You can add more with<A HREF="http://www.freeswan.ca">
Super FreeS/WAN</A>, but what we offer may be enough for many users.</P>
<UL>
<LI> To use X.509 certificates with FreeS/WAN, you will need the<A HREF="http://www.strongsec.org/freeswan">
X.509 patch</A> or<A HREF="http://www.freeswan.ca"> Super FreeS/WAN</A>
, which includes that patch.</LI>
<LI> To use<A HREF="glossary.html#NAT.gloss"> Network Address
Translation</A> (NAT) traversal with FreeS/WAN, you will need Arkoon
Network Security's<A HREF="http://open-source.arkoon.net"> NAT
traversal patch</A> or<A HREF="http://www.freeswan.ca"> Super FreeS/WAN</A>
, which includes it.</LI>
</UL>
<P>We offer a set of proposals which is not user-adjustable, but covers
all combinations that we can offer. FreeS/WAN always proposes triple
DES encryption and Perfect Forward Secrecy (PFS). In addition, we
propose Diffie Hellman groups 5 and 2 (in that order), and MD5 and
SHA-1 hashes. We accept the same proposals, in the same order of
preference.</P>
<P>Other interop notes:</P>
<UL>
<LI> A<A HREF="http://lists.freeswan.org/archives/users/2003-September/msg00462.html">
SHA-1 bug in FreeS/WAN 2.00, 2.01 and 2.02</A> may affect some interop
scenarios. It does not affect 1.x versions, and is fixed in 2.03 and
later.</LI>
<LI> Some other implementations will close a connection with FreeS/WAN
after some time. This may be a problem with rekey lifetimes. Please see<A
HREF="http://lists.freeswan.org/archives/users/2003-October/msg00293.html">
this tip</A> and<A HREF="http://lists.freeswan.org/pipermail/users/2001-December/005758.html">
this workaround</A>.</LI>
</UL>
<H2><A NAME="10_3">Longer Stories</A></H2>
<H3><A NAME="10_3_1">For<EM> More Compatible</EM> Implementations</A></H3>
<H4><A NAME="freeswan">FreeS/WAN</A></H4>
<P> See our documentation at<A HREF="http://www.freeswan.org">
freeswan.org</A> and the Super FreeS/WAN docs at<A HREF="http://www.freeswan.ca">
freeswan.ca</A>. Some user-written HOWTOs for FreeS/WAN-FreeS/WAN
connections are listed in<A HREF="intro.html#howto"> our Introduction</A>
.</P>
<P>See also:</P>
<UL>
<LI><A HREF="http://lugbe.ch/action/reports/ipsec_htbe.phtml"> A German
FreeS/WAN-FreeS/WAN page by Markus Wernig (X.509)</A></LI>
</UL>
<P><A HREF="#freeswan.top">Back to chart</A></P>
<H4><A NAME="isakmpd">isakmpd (OpenBSD)</A></H4>
<P><A HREF="http://www.openbsd.org/faq/faq13.html">OpenBSD FAQ: Using
IPsec</A>
<BR><A HREF="http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html">
Hans-Joerg Hoexer's interop Linux-OpenBSD (PSK)</A>
<BR><A HREF="http://www.segfault.net/ipsec/"> Skyper's configuration
(PSK)</A>
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs (X.509)</A></P>
<P><A HREF="#isakmpd.top">Back to chart</A></P>
<H4><A NAME="kame">Kame</A></H4>
<UL>
<LI>For FreeBSD and NetBSD. Ships with Mac OS X; see also our<A HREF="#apple">
Mac</A> section.</LI>
<LI>Also known as<EM> racoon</EM>, its keying daemon.</LI>
</UL>
<P><A HREF="http://www.kame.net">Kame homepage, with FAQ</A>
<BR><A HREF="http://www.netbsd.org/Documentation/network/ipsec">
NetBSD's IPSec FAQ</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/12/msg00560.html">
Ghislaine's post explaining some interop peculiarities</A></P>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/09/msg00511.html">
Itojun's Kame-FreeS/WAN interop tips (PSK)</A>
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2000"> Ghislaine
Labouret's French page with links to matching FreeS/WAN and Kame
configs (RSA)</A>
<BR><A HREF="http://lugbe.ch/lostfound/contrib/freebsd_router/"> Markus
Wernig's HOWTO (X.509, BSD gateway)</A>
<BR><A HREF="http://web.morgul.net/~frodo/docs/kame+freeswan_interop.html">
Frodo's Kame-FreeS/WAN interop (X.509)</A>
<BR><A HREF="http://www.wavesec.org/kame.phtml"> Kame as a WAVEsec
client.</A></P>
<P><A HREF="#kame.top">Back to chart</A></P>
<H4><A NAME="mcafee">PGPNet/McAfee</A></H4>
<P></P>
<UL>
<LI>Now called McAfee VPN Client.</LI>
<LI>PGPNet also came in a freeware version which did not support subnets</LI>
<LI>To support dhcp-over-ipsec, you need the X.509 patch, which is
included in<A HREF="http://www.freeswan.ca"> Super FreeS/WAN</A>.</LI>
</UL>
<P><A HREF="http://www.freeswan.ca/docs/WindowsInterop"> Tim Carr's
Windows Interop Guide (X.509)</A>
<BR><A HREF="http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html#Interop2">
Hans-Joerg Hoexer's Guide for Linux-PGPNet (PSK)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/04/msg00339.html">
Kai Martius' instructions using RSA Key-Extractor Tool (RSA)</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://www.zengl.net/freeswan/english.html">Christian
Zeng's page (RSA)</A> based on Kai's work. English or German.
<BR><A HREF="http://tirnanog.ls.fi.upm.es/CriptoLab/Biblioteca/InfTech/InfTech_CriptoLab.htm">
Oscar Delgado's PDF (X.509, no configs)</A>
<BR><A HREF="http://www-ec.njit.edu/~rxt1077/Howto.txt"> Ryan's HOWTO
for FreeS/WAN-PGPNet (X.509)</A>. Through a Linksys Router with IPsec
Passthru enabled.
<BR><A HREF="http://jixen.tripod.com/#RW-PGP-to-Fwan"> Jean-Francois
Nadeau's Practical Configuration (Road Warrior with PSK)</A>
<BR><A HREF="http://www.evolvedatacom.nl/freeswan.html#toc"> Wouter
Prins' HOWTO (Road Warrior with X.509)</A>
<BR></P>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/01/msg00271.html">
Rekeying problem with FreeS/WAN and older PGPNets</A>
<BR></P>
<P><A HREF="http://www.strongsec.com/freeswan/dhcprelay/index.htm"> DHCP
over IPSEC HOWTO for FreeS/WAN (requires X.509 and dhcprelay patches)</A>
</P>
<P><A HREF="#mcafee.top">Back to chart</A></P>
<H4><A NAME="microsoft">Microsoft Windows 2000/XP</A></H4>
<UL>
<LI>IPsec comes with Win2k, and with XP Support Tools. May require<A HREF="http://www.microsoft.com/windows2000/downloads/recommended/encryption/default.asp">
High Encryption Pack</A>. WinXP users have also reported better results
with Service Pack 1.</LI>
<LI>The Road Warrior setup works either way round. Windows (XP or 2K)
IPsec can connect as a Road Warrior to FreeS/WAN. However, FreeS/WAN
can also successfully connect as a Road Warrior to Windows IPsec (see
Nate Carlson's configs below).</LI>
<LI>FreeS/WAN version 1.92 or later is required to avoid an
interoperation problem with Windows native IPsec. Earlier FreeS/WAN
versions did not process the Commit Bit as Windows native IPsec
expected.</LI>
</UL>
<P><A HREF="http://www.freeswan.ca/docs/WindowsInterop"> Tim Carr's
Windows Interop Guide (X.509)</A>
<BR><A HREF="http://ipsec.math.ucla.edu/services/ipsec.html"> James
Carter's instructions (X.509, NAT-T)</A>
<BR><A HREF="http://jixen.tripod.com/#Win2000-Fwan"> Jean-Francois
Nadeau's Net-net Configuration (PSK)</A>
<BR><A HREF="http://security.nta.no/freeswan-w2k.html"> Telenor's
Node-node Config (Transport-mode PSK)</A>
<BR><A HREF="http://vpn.ebootis.de"> Marcus Mueller's HOWTO using his
VPN config tool (X.509).</A> Tool also works with PSK.
<BR><A HREF="http://www.natecarlson.com/include/showpage.php?cat=linux&page=ipsec-x509">
Nate Carlson's HOWTO using same tool (Road Warrior with X.509)</A>.
Unusually, FreeS/WAN is the Road Warrior here.
<BR><A HREF="http://tirnanog.ls.fi.upm.es/CriptoLab/Biblioteca/InfTech/InfTech_CriptoLab.htm">
Oscar Delgado's PDF (X.509, no configs)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2003-July/022425.html">
Tim Scannell's Windows XP Additional Checklist (X.509)</A>
<BR></P>
<!-- Note to self: Include L2TP references? -->
<P><A HREF="http://www.microsoft.com/windows2000/en/server/help/default.asp?url=/windows2000/en/server/help/sag_TCPIP_ovr_secfeatures.htm">
Microsoft's page on Win2k TCP/IP security features</A>
<BR><A HREF="http://support.microsoft.com/support/kb/articles/Q257/2/25.ASP">
Microsoft's Win2k IPsec debugging tips</A>
<BR>
<!-- Alt-URL http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257225
Perhaps newer? -->
<A HREF="http://www.wired.com/news/technology/0,1282,36336,00.html">
MS VPN may fall back to 1DES</A></P>
<P><A HREF="#microsoft.top">Back to chart</A></P>
<H4><A NAME="ssh">SSH Sentinel</A></H4>
<UL>
<LI>Popular and well tested.</LI>
<LI>Also rebranded in<A HREF="http://www.zyxel.com"> Zyxel Zywall</A>.
Our Zyxel interop notes are<A HREF="#zyxel"> here</A>.</LI>
<LI> SSH supports IPsec-over-UDP NAT traversal.</LI>
<LI>There is this<A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/12/msg00370.html">
potential problem</A> if you're not using the Legacy Proposal option.</LI>
</UL>
<P><A HREF="http://www.ssh.com/support/sentinel/documents.cfm"> SSH's
Sentinel-FreeSWAN interop PDF (X.509)</A>
<BR><A HREF="http://www.nadmm.com/show.php?story=articles/vpn.inc">
Nadeem Hassan's SUSE-to-Sentinel article (Road warrior with X.509)</A>
<BR><A HREF="http://www.zerozone.it/documents/Linux/HowTo/VPN-IPsec-Freeswan-HOWTO.html">
O-Zone's Italian HOWTO (Road Warrior, X.509, DHCP)</A>
<BR></P>
<P><A HREF="#ssh.top">Back to chart</A></P>
<H4><A NAME="safenet">Safenet SoftPK/SoftRemote</A></H4>
<UL>
<LI>People recommend SafeNet as a low cost Windows client.</LI>
<LI>SoftRemote seems to be the newer name for SoftPK.</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005061.html">
Whit Blauvelt's SoftRemote tips</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015591.html">
Tim Wilson's tips (X.509)</A><A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00607.html">
Workaround for a &quot;gotcha&quot;</A></P>
<P><A HREF="http://jixen.tripod.com/#Rw-IRE-to-Fwan"> Jean-Francois
Nadeau's Practical Configuration (Road Warrior with PSK)</A>
<BR><A HREF="http://www.terradoncommunications.com/security/whitepapers/safe_net-to-free_swan.pdf">
Terradon Communications' PDF (Road Warrior with PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/?????.html">
Seaan.net's PDF (Road Warrior to Subnet, with PSK)</A>
<BR><A HREF="http://www.redbaronconsulting.com/freeswan/fswansafenet.pdf">
Red Baron Consulting's PDF (Road Warrior with X.509)</A></P>
<P><A HREF="#safenet.top">Back to chart</A></P>
<H3><A NAME="10_3_2">For<EM> Other Implementations</EM></A></H3>
<H4><A NAME="6wind">6Wind</A></H4>
<P><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs (X.509)</A></P>
<P><A HREF="#6wind.top">Back to chart</A></P>
<H4><A NAME="alcatel">Alcatel Timestep</A></H4>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-June/011878.html">
Alain Sabban's settings (PSK or PSK road warrior; through static NAT)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/06/msg00100.html">
Derick Cassidy's configs (PSK)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/08/msg00194.html">
David Kerry's Timestep settings (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013711.html">
Kevin Gerbracht's ipsec.conf (X.509)</A></P>
<P><A HREF="#alcatel.top">Back to chart</A></P>
<H4><A NAME="apple">Apple Macintosh System 10+</A></H4>
<UL>
<LI>Since the system is based on FreeBSD, this should interoperate<A HREF="#kame">
just like FreeBSD</A>.</LI>
<LI> To use Appletalk over IPsec tunnels,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005116.html">
run it over TCP/IP</A>, or use Open Door Networks' Shareway IP tool,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005426.html">
described here.</A></LI>
<LI>See also the<A HREF="#equinux"> Equinux VPN Tracker</A> for Mac OS
X.</LI>
</UL>
<P><A HREF="http://ipsec.math.ucla.edu/services/ipsec.html"> James
Carter's instructions (X.509, NAT-T)</A></P>
<P><A HREF="#apple.top">Back to chart</A></P>
<H4><A NAME="ashleylaurent">AshleyLaurent VPCom</A></H4>
<P><A HREF="http://www.ashleylaurent.com/newsletter/01-28-00.htm">
Successful interop report, no details</A></P>
<P><A HREF="#ashleylaurent.top">Back to chart</A></P>
<H4><A NAME="borderware">Borderware</A></H4>
<UL>
<LI>I suspect the Borderware client is a rebranded Safenet. If that's
true, our<A HREF="#safenet"> Safenet section</A> will help.</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-March/008288.html">
Philip Reetz' configs (PSK)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/09/msg00217.html">
Borderware server does not support FreeS/WAN road warriors</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007733.html">
Older Borderware may not support Diffie Hellman groups 2, 5</A>
<BR></P>
<P><A HREF="#borderware.top">Back to chart</A></P>
<H4><A NAME="checkpoint">Check Point VPN-1 or FW-1</A></H4>
<UL>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00099.html">
Caveat about IP-range inclusion on Check Point.</A></LI>
<LI> Some versions of Check Point may require an aggressive mode patch
to interoperate with FreeS/WAN.
<BR><A HREF="http://www.freeswan.ca/code/super-freeswan"> Super
FreeS/WAN</A> now features this patch.
<!--
<A HREF="http://www.freeswan.ca/patches/aggressivemode">Steve Harvey's
aggressive mode patch for FreeS/WAN 1.5</A>
-->
</LI>
<LI></LI>
<LI>A Linux FreeS/WAN-Checkpoint connection may close after some time.
Try<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00293.html">
this tip</A> toward a workaround.</LI>
</UL>
<P><A HREF="http://www.fw-1.de/aerasec/ng/vpn-freeswan/CPNG+Linux-FreeSWAN.html">
AERAsec's Firewall-1 NG site (PSK, X.509, Road Warrior with X.509,
other algorithms)</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://www.fw-1.de/aerasec/ng/vpn-freeswan/CPNG+Linux-FreeSWAN.html#support-matrix">
AERAsec's detailed Check Point-FreeS/WAN support matrix</A>
<BR><A HREF="http://support.checkpoint.com/kb/docs/public/firewall1/4_1/pdf/fw-linuxvpn.pdf">
Checkpoint.com PDF: Linux as a VPN Client to FW-1 (PSK)</A>
<BR><A HREF="http://www.phoneboy.com"> PhoneBoy's Check Point FAQ (on
Check Point only, not FreeS/WAN)</A>
<BR></P>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2001-August/002351.html">
Chris Harwell's tips FreeS/WAN configs (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009362.html">
Daniel Tombeil's configs (PSK)</A></P>
<P><A HREF="#checkpoint.top">Back to chart</A></P>
<H4><A NAME="cisco">Cisco</A></H4>
<UL>
<LI> Cisco supports IPsec-over-UDP NAT traversal.</LI>
<LI>Cisco VPN Client appears to use nonstandard IPsec and does not work
with FreeS/WAN.<A HREF="https://mj2.freeswan.org/archives/2003-August/maillist.html">
This message</A> concerns Cisco VPN Client 4.01.
<!-- fix link -->
</LI>
<LI>A Linux FreeS/WAN-Cisco connection may close after some time.<A HREF="http://lists.freeswan.org/pipermail/users/2001-December/005758.html">
Here</A> is a workaround, and<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00293.html">
here</A> is another comment on the same subject.</LI>
<LI><A HREF="http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t2/3desips.htm">
Older Ciscos</A> purchased outside the United States may not have 3DES,
which FreeS/WAN requires.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2001-June/000406.html">
RSA keying may not be possible between Cisco and FreeS/WAN.</A></LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2001-October/004357.html">
In ipsec.conf, VPN3000 DN (distinguished name) must be in binary (X.509
only)</A></LI>
</UL>
<P><A HREF="http://rr.sans.org/encryption/cisco_router.php"> SANS
Institute HOWTO (PSK).</A> Detailed, with extensive references.
<BR><A HREF="http://www.worldbank.ro/IPSEC/cisco-linux.txt"> Short HOWTO
(PSK)</A>
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs for Cisco IOS, PIX and VPN 3000 (X.509)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-August/002966.html">
Dave McFerren's sample configs (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-September/003422.html">
Wolfgang Tremmel's sample configs (PSK road warrior)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00578.html">
Old doc from Pete Davis, with William Watson's updated Tips (PSK)</A>
<BR></P>
<P><STRONG>Some PIX specific information:</STRONG>
<BR><A HREF="http://www.wlug.org.nz/FreeSwanToCiscoPix"> Waikato Linux
Users' Group HOWTO. Nice detail (PSK)</A>
<BR><A HREF="http://www.johnleach.co.uk/documents/freeswan-pix/freeswan-pix.html">
John Leach's configs (PSK)</A>
<BR><A HREF="http://www.diverdown.cc/vpn/freeswanpix.html"> Greg
Robinson's settings (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007901.html">
Scott's ipsec.conf for PIX (PSK, FreeS/WAN side only)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-October/003949.html">
Rick Trimble's PIX and FreeS/WAN settings (PSK)</A>
<BR></P>
<P><A href="http://www.cisco.com/public/support/tac"> Cisco VPN support
page</A>
<BR><A href="http://www.ieng.com/warp/public/707/index.shtml#ipsec">
Cisco IPsec information page</A></P>
<P><A HREF="#cisco.top">Back to chart</A></P>
<H4><A NAME="equinux">Equinux VPN tracker (for Mac OS X)</A></H4>
<UL>
<LI>Graphical configurator for Mac OS X IPsec. May be an interface to
the<A HREF="#apple"> native Mac OS X IPsec</A>, which is essentially<A HREF="#kame">
KAME</A>.</LI>
<LI>To use Appletalk over IPsec tunnels,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005116.html">
run it over TCP/IP</A>, or use Open Door Networks' Shareway IP tool,<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005426.html">
described here.</A></LI>
</UL>
<P> Equinux provides<A HREF="http://www.equinux.com/download/HowTo_FreeSWAN.pdf">
this excellent interop PDF</A> (PSK, RSA, X.509).</P>
<P><A HREF="#equinux.top">Back to chart</A></P>
<H4><A NAME="fsecure">F-Secure</A></H4>
<UL>
<LI>
<!-- <A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007596.html"> -->
F-Secure supports IPsec-over-UDP NAT traversal.</LI>
</UL>
<P><A HREF="http://www.pingworks.de/tech/vpn/vpn.txt">pingworks.de's
&quot;Connecting F-Secure's VPN+ to Linux FreeS/WAN&quot; (PSK road warrior)</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://www.pingworks.de/tech/vpn/vpn.pdf">Same thing
as PDF</A>
<BR><A HREF="http://www.exim.org/pipermail/linux-ipsec/Week-of-Mon-20010122/000061.html">
Success report, no detail (PSK)</A>
<BR><A HREF="http://www.exim.org/pipermail/linux-ipsec/Week-of-Mon-20010122/000041.html">
Success report, no detail (Manual)</A></P>
<!-- Other NAT traversers:
http://lists.freeswan.org/pipermail/users/2002-April/009136.html
and ssh sentinel:
http://lists.freeswan.org/pipermail/users/2001-September/003108.html
-->
<P><A HREF="#fsecure.top">Back to chart</A></P>
<H4><A NAME="gauntlet">Gauntlet GVPN</A></H4>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/11/msg00535.html">
Richard Reiner's ipsec.conf (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-June/011434.html">
Might work without that pesky firewall... (PSK)</A>
<BR>
<!-- insert archive link -->
In late July, 2003 Alexandar Antik reported success interoperating
with Gauntlet 6.0 for Solaris (X.509). Unfortunately the message is not
properly archived at this time.</P>
<P><A HREF="#gauntlet.top">Back to chart</A></P>
<H4><A NAME="aix">IBM AIX</A></H4>
<P><A HREF="http://www-1.ibm.com/servers/esdd/articles/security.html">
IBM's &quot;Built-In Network Security with AIX&quot; (PSK, X.509)</A>
<BR><A HREF="http://www-1.ibm.com/servers/aix/products/ibmsw/security/vpn/faqandtips/#ques20">
IBM's tip: importing Linux FreeS/WAN settings into AIX's<VAR> ikedb</VAR>
(PSK)</A></P>
<P><A HREF="#aix.top">Back to chart</A></P>
<H4><A NAME="as400">IBM AS/400</A></H4>
<UL>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009106.html">
Road Warriors may act flaky</A>.</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-September/014264.html">
Richard Welty's tips and tricks</A>
<BR></P>
<P><A HREF="#as400.top">Back to chart</A></P>
<H4><A NAME="intel">Intel Shiva LANRover / Net Structure</A></H4>
<UL>
<LI>Intel Shiva LANRover is now known as Intel Net Structure.</LI>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/01/msg00298.html">
Shiva seems to have two modes: IPsec or the proprietary &quot;Shiva Tunnel&quot;.</A>
Of course, FreeS/WAN will only create IPsec tunnels.</LI>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00293.html">
AH may not work for Shiva-FreeS/WAN.</A> That's OK, since FreeS/WAN has
phased out the use of AH.</LI>
</UL>
<P><A HREF="http://snowcrash.tdyc.com/freeswan/"> Snowcrash's configs
(PSK)</A>
<BR><A HREF="http://www.opus1.com/vpn/index.html"> Old configs from an
interop (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-October/003831.html">
The day Shiva tickled a Pluto bug (PSK)</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://lists.freeswan.org/pipermail/users/2001-October/004270.html">
Follow up: success!</A></P>
<P><A HREF="#intel.top">Back to chart</A></P>
<H4><A NAME="lancom">LanCom (formerly ELSA)</A></H4>
<UL>
<LI>This router is popular in Germany.</LI>
</UL>
<P> Jakob Curdes successfully created a PSK connection with the LanCom
1612 in August 2003.
<!-- add ML link when it appears -->
</P>
<P><A HREF="#lancom.top">Back to chart</A></P>
<H4><A NAME="linksys">Linksys</A></H4>
<UL>
<LI>Linksys may be used as an IPsec tunnel endpoint,<STRONG> OR</STRONG>
as a router in &quot;IPsec passthrough&quot; mode, so that the IPsec tunnel
passes through the Linksys.</LI>
</UL>
<H5>As tunnel endpoint</H5>
<P><A HREF="http://www.freeswan.ca/docs/BEFVP41/"> Ken Bantoft's
instructions (Road Warrior with PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-February/007814.html">
Nate Carlson's caveats</A></P>
<H5>In IPsec passthrough mode</H5>
<P><A HREF="http://www-ec.njit.edu/~rxt1077/Howto.txt"> Sample HOWTO
through a Linksys Router</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2002/02/msg00114.html">
Nadeem Hasan's configs</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2002/02/msg00180.html">
Brock Nanson's tips</A>
<BR></P>
<P><A HREF="#linksys.top">Back to chart</A></P>
<H4><A NAME="lucent">Lucent</A></H4>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010976.html">
Partial success report; see also the next message in thread</A></P>
<!-- section done -->
<P><A HREF="#lucent.top">Back to chart</A></P>
<H4><A NAME="netasq">Netasq</A></H4>
<P><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs (X.509)</A></P>
<!-- section done -->
<P><A HREF="#netasq.top">Back to chart</A></P>
<H4><A NAME="netcelo">Netcelo</A></H4>
<P><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs (X.509)</A>
<!-- section done -->
</P>
<P><A HREF="#netcelo.top">Back to chart</A></P>
<H4><A NAME="netgear">Netgear fvs318</A></H4>
<UL>
<LI>With a recent Linux FreeS/WAN, you will require the latest (12/2002)
Netgear firmware, which supports Diffie-Hellman (DH) group 2. For
security reasons, we phased out DH 1 after Linux FreeS/WAN 1.5.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-June/011833.html">
This message</A> reports the incompatibility between Linux FreeS/WAN
1.6+ and Netgear fvs318 without the firmware upgrade.</LI>
<LI>We believe Linux FreeS/WAN 1.5 and earlier will interoperate with
any NetGear firmware.</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2003-February/017891.html">
John Morris' setup (PSK)</A></P>
<P><A HREF="#netgear.top">Back to chart</A></P>
<H4><A NAME="netscreen">Netscreen 100 or 5xp</A></H4>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013409.html">
Errol Neal's settings (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015265.html">
Corey Rogers' configs (PSK, no PFS)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013051.html">
Jordan Share's configs (PSK, 2 subnets, through static NAT)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/08/msg00404.html">
Set src proxy_id to your protected subnet/mask</A>
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with ipsec.conf, Netscreen screen shots (X.509, may need to
revert to PSK...)</A></P>
<P><A HREF="http://archives.neohapsis.com/archives/sf/linux/2001-q2/0123.html">
A report of a company using Netscreen with FreeS/WAN on a large scale
(FreeS/WAN road warriors?)</A></P>
<P><A HREF="#netscreen.top">Back to chart</A></P>
<H4><A NAME="nortel">Nortel Contivity</A></H4>
<UL>
<LI> Nortel supports IPsec-over-UDP NAT traversal.</LI>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00417.html">
Some older versions of Contivity and FreeS/WAN will not communicate.</A>
</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010924.html">
FreeS/WAN cannot be used as a &quot;client&quot; to a Nortel Contivity server,
but can be used as a branch-office tunnel.</A></LI>
<!-- Probably obsoleted by Ken's post
<LI>
(Matthias siebler from old interop)
At one point you could not configure Nortel-FreeS/WAN tunnels as
"Client Tunnels" since FreeS/WAN does not support Aggressive Mode.
Current status of this problem: unknown.
<LI>
<A HREF="http://lists.freeswan.org/pipermail/users/2001-November/004612.html">
How do we map group and user passwords onto the data that FreeS/WAN wants?
</A>
</LI>
-->
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015455.html">
Contivity does not send Distinguished Names in the order FS wants them
(X.509).</A></LI>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/03/msg00137.html">
Connections may time out after 30-40 minutes idle.</A></LI>
</UL>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/03/msg00137.html">
JJ Streicher-Bremer's mini HOWTO for old new software. (PSK with two
subnets)</A>
<BR><A HREF="http://www.hsc.fr/ressources/ipsec/ipsec2001/#config">
French page with configs (X.509)</A>. This succeeds using the above
X.509 tip.</P>
<!-- I could do more searching but this is a solid start. -->
<P><A HREF="#nortel.top">Back to chart</A></P>
<H4><A NAME="radguard">Radguard</A></H4>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/05/msg00009.html">
Marko Hausalo's configs (PSK).</A> Note: These do create a connection,
as you can see by &quot;IPsec SA established&quot;.
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/???.html">
Claudia Schmeing's comments</A></P>
<P><A HREF="#radguard.top">Back to chart</A></P>
<H4><A NAME="raptor">Raptor (NT or Solaris)</A></H4>
<P></P>
<UL>
<LI>Now known as Symantec Enterprise Firewall.</LI>
<LI>The Raptor does not normally come with X.509, but this may be
available as an add-on.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010256.html">
Raptor requires alphanumberic PSK values, whereas FreeS/WAN uses hex.</A>
</LI>
<LI>Raptor's tunnel endpoint may be a host, subnet or group of subnets
(see<A HREF="http://lists.freeswan.org/pipermail/design/2001-November/001295.html">
this message</A> ). FreeS/WAN cannot handle the group of subnets; you
must create separate connections for each in order to interoperate.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010113.html">
Some versions of Raptor accept only single DES.</A> According to this
German message,<A HREF="http://radawana.cg.tuwien.ac.at/mail-archives/lll/200012/msg00065.html">
the Raptor Mobile Client demo offers single DES only.</A></LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-January/006935.html">
Peter Mazinger's settings (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2001-November/005522.html">
Peter Gerland's configs (PSK)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/07/msg00597.html">
Charles Griebel's configs (PSK).</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-July/012275.html">
Lumir Srch's tips (PSK)</A></P>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/05/msg00214.html">
John Hardy's configs (Manual)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/01/msg00236.html">
Older Raptors want 3DES keys in 3 parts (Manual).</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/06/msg00480.html">
Different keys for each direction? (Manual)</A>
<BR></P>
<P><A HREF="#raptor.top">Back to chart</A></P>
<H4><A NAME="redcreek">Redcreek Ravlin</A></H4>
<UL>
<LI>Known issue #1: The Ravlin expects a quick mode renegotiation right
after every Main Mode negotiation.</LI>
<LI> Known issue #2: The Ravlin tries to negotiate a zero connection
lifetime, which it takes to mean &quot;infinite&quot;.<A HREF="http://www.bear-cave.org.uk/linux/ravlin/">
Jim Hague's patch</A> addresses both issues.</LI>
<LI><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/03/msg00191.html">
Interop works with Ravlin Firmware &gt; 3.33. Includes tips (PSK).</A></LI>
</UL>
<P><A HREF="#redcreek.top">Back to chart</A></P>
<H4><A NAME="sonicwall">SonicWall</A></H4>
<UL>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2001-June/000998.html">
Sonicwall cannot be used for Road Warrior setups</A></LI>
<LI> At one point,<A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2000/05/msg00217.html">
only Sonicwall PRO supported triple DES</A>.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-March/008600.html">
Older Sonicwalls (before Nov 2001) feature Diffie Hellman group 1 only</A>
.</LI>
</UL>
<P><A HREF="http://www.xinit.cx/docs/freeswan.html"> Paul Wouters'
config (PSK)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00073.html">
Dilan Arumainathan's configuration (PSK)</A>
<BR><A HREF="http://www.gravitas.co.uk/vpndebug"> Dariush's setup...
only opens one way (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2003-July/022302.html">
Andreas Steffen's tips (X.509)</A>
<BR></P>
<P><A HREF="#sonicwall.top">Back to chart</A></P>
<H4><A NAME="sun">Sun Solaris</A></H4>
<UL>
<LI> Solaris 8+ has a native (in kernel) IPsec implementation.</LI>
<LI><A HREF="http://lists.freeswan.org/pipermail/users/2002-May/010503.html">
Solaris does not seem to support tunnel mode, but you can make IP-in-IP
tunnels instead, like this.</A></LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2003-June/022216.html">
Reports of some successful interops</A> from a fellow @sun.com. See
also<A HREF="http://lists.freeswan.org/pipermail/users/2003-July/022247.html">
these follow up posts</A>.
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/03/msg00332.html">
Aleks Shenkman's configs (Manual in transport mode)</A>
<BR>
<!--sparc 64 stuff goes where?-->
</P>
<P><A HREF="#solaris.top">Back to chart</A></P>
<H4><A NAME="symantec">Symantec</A></H4>
<UL>
<LI>The Raptor, covered<A HREF="#raptor"> above</A>, is now known as
Symantec Enterprise Firewall.</LI>
<LI>Symantec's &quot;distinguished name&quot; is a KEY_ID. See Andreas Steffen's
post, below.</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009037.html">
Andreas Steffen's configs for Symantec 200R (PSK)</A></P>
<P><A HREF="#symantec.top">Back to chart</A></P>
<H4><A NAME="watchguard">Watchguard Firebox</A></H4>
<UL>
<LI>Automatic keying works with WatchGuard 5.0+ only.</LI>
<LI>Seen to interoperate with WatchGuard 1000, II, III; firmware v. 5,
6..</LI>
<LI>For manual keying, Watchguard's Policy Manager expects SPI numbers
and encryption and authentication keys in decimal (not hex).</LI>
</UL>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-July/012595.html">
WatchGuard's HOWTO (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-August/013342.html">
Ronald C. Riviera's Settings (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00179.html">
Walter Wickersham's Notes (PSK)</A>
<BR><A HREF="http://lists.freeswan.org/pipermail/users/2002-October/015587.html">
Max Enders' Configs (Manual)</A></P>
<P><A HREF="http://lists.freeswan.org/pipermail/users/2002-April/009404.html">
Old known issue with auto keying</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/02/msg00124.html">
Tips on key generation and format (Manual)</A>
<BR></P>
<P><A HREF="#watchguard.top">Back to chart</A></P>
<H4><A NAME="xedia">Xedia Access Point/QVPN</A></H4>
<P><A HREF="http://www.sandelman.ottawa.on.ca/linux-ipsec/html/2001/12/msg00520.html">
Hybrid IPsec/L2TP connection settings (X.509)</A>
<BR><A HREF="http://www.sandelman.ottawa.on.ca/ipsec/1999/08/msg00140.html">
Xedia's LAN-LAN links don't use multiple tunnels</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;<A HREF="http://www.sandelman.ottawa.on.ca/ipsec/1999/08/msg00140.html">
That explanation, continued</A></P>
<P><A HREF="#xedia.top">Back to chart</A></P>
<H4><A NAME="zyxel">Zyxel</A></H4>
<UL>
<LI>The Zyxel Zywall is a rebranded SSH Sentinel box. See also our
section on<A HREF="glossary.html#ssh"> SSH</A>.</LI>
<LI>There seems to be a problem with keeping this connection alive. This
is caused at the Zyxel end. See this brief<A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00141.html">
discussion and solution.</A></LI>
</UL>
<P><A HREF="http://www.zyxel.com/support/supportnote/zywall/app/zw_freeswan.htm">
Zyxel's Zywall to FreeS/WAN instructions (PSK)</A>
<BR><A HREF="http://www.zyxel.com/support/supportnote/p652/app/zw_freeswan.htm">
Zyxel's Prestige to FreeS/WAN instructions (PSK)</A>. Note: not all
Prestige versions include VPN software.
<BR><A HREF="http://www.lancry.net/techdocs/freeswan-zyxel.txt"> Fabrice
Cahen's HOWTO (PSK)</A>
<BR> &nbsp;&nbsp;&nbsp;&nbsp;</P>
<P><A HREF="#zyxel.top">Back to chart</A></P>
<!-- SAMPLE ENTRY
<H4><A NAME="timestep">Timestep</A></H4>
<P>Text goes here.
</P>
-->
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="compat.html">Previous</A>
<A HREF="performance.html">Next</A>
</BODY>
</HTML>

733
doc/intro.html Normal file
View File

@ -0,0 +1,733 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="upgrading.html">Next</A>
<HR>
<H1><A name="intro">Introduction</A></H1>
<P>This section gives an overview of:</P>
<UL>
<LI>what IP Security (IPsec) does</LI>
<LI>how IPsec works</LI>
<LI>why we are implementing it for Linux</LI>
<LI>how this implementation works</LI>
</UL>
<P>This section is intended to cover only the essentials,<EM> things you
should know before trying to use FreeS/WAN.</EM></P>
<P>For more detailed background information, see the<A href="politics.html#politics">
history and politics</A> and<A href="ipsec.html#ipsec.detail"> IPsec
protocols</A> sections.</P>
<H2><A name="ipsec.intro">IPsec, Security for the Internet Protocol</A></H2>
<P>FreeS/WAN is a Linux implementation of the IPsec (IP security)
protocols. IPsec provides<A href="glossary.html#encryption"> encryption</A>
and<A href="glossary.html#authentication"> authentication</A> services
at the IP (Internet Protocol) level of the network protocol stack.</P>
<P>Working at this level, IPsec can protect any traffic carried over IP,
unlike other encryption which generally protects only a particular
higher-level protocol --<A href="glossary.html#PGP"> PGP</A> for mail,<A
href="glossary.html#SSH"> SSH</A> for remote login,<A href="glossary.html#SSL">
SSL</A> for web work, and so on. This approach has both considerable
advantages and some limitations. For discussion, see our<A href="ipsec.html#others">
IPsec section</A></P>
<P>IPsec can be used on any machine which does IP networking. Dedicated
IPsec gateway machines can be installed wherever required to protect
traffic. IPsec can also run on routers, on firewall machines, on
various application servers, and on end-user desktop or laptop
machines.</P>
<P>Three protocols are used</P>
<UL>
<LI><A href="glossary.html#AH">AH</A> (Authentication Header) provides a
packet-level authentication service</LI>
<LI><A href="glossary.html#ESP">ESP</A> (Encapsulating Security Payload)
provides encryption plus authentication</LI>
<LI><A href="glossary.html#IKE">IKE</A> (Internet Key Exchange)
negotiates connection parameters, including keys, for the other two</LI>
</UL>
<P>Our implementation has three main parts:</P>
<UL>
<LI><A href="glossary.html#KLIPS">KLIPS</A> (kernel IPsec) implements
AH, ESP, and packet handling within the kernel</LI>
<LI><A href="glossary.html#Pluto">Pluto</A> (an IKE daemon) implements
IKE, negotiating connections with other systems</LI>
<LI>various scripts provide an adminstrator's interface to the machinery</LI>
</UL>
<P>IPsec is optional for the current (version 4) Internet Protocol.
FreeS/WAN adds IPsec to the Linux IPv4 network stack. Implementations
of<A href="glossary.html#ipv6.gloss"> IP version 6</A> are required to
include IPsec. Work toward integrating FreeS/WAN into the Linux IPv6
stack has<A href="compat.html#ipv6"> started</A>.</P>
<P>For more information on IPsec, see our<A href="ipsec.html#ipsec.detail">
IPsec protocols</A> section, our collection of<A href="web.html#ipsec.link">
IPsec links</A> or the<A href="rfc.html#RFC"> RFCs</A> which are the
official definitions of these protocols.</P>
<H3><A name="intro.interop">Interoperating with other IPsec
implementations</A></H3>
<P>IPsec is designed to let different implementations work together. We
provide:</P>
<UL>
<LI>a<A href="web.html#implement"> list</A> of some other
implementations</LI>
<LI>information on<A href="interop.html#interop"> using FreeS/WAN with
other implementations</A></LI>
</UL>
<P>The VPN Consortium fosters cooperation among implementers and
interoperability among implementations. Their<A href="http://www.vpnc.org/">
web site</A> has much more information.</P>
<H3><A name="advantages">Advantages of IPsec</A></H3>
<P>IPsec has a number of security advantages. Here are some
independently written articles which discuss these:</P>
<P><A HREF="http://www.sans.org/rr/"> SANS institute papers</A>. See the
section on Encryption &amp;VPNs.
<BR><A HREF="http://www.cisco.com/en/US/netsol/ns110/ns170/ns171/ns128/networking_solutions_white_papers_list.html">
Cisco's white papers on &quot;Networking Solutions&quot;</A>.
<BR><A HREF="http://iscs.sourceforge.net/HowWhyBrief/HowWhyBrief.html">
Advantages of ISCS (Linux Integrated Secure Communications System;
includes FreeS/WAN and other software)</A>.</P>
<H3><A name="applications">Applications of IPsec</A></H3>
<P>Because IPsec operates at the network layer, it is remarkably
flexible and can be used to secure nearly any type of Internet traffic.
Two applications, however, are extremely widespread:</P>
<UL>
<LI>a<A href="glossary.html#VPN"> Virtual Private Network</A>, or VPN,
allows multiple sites to communicate securely over an insecure Internet
by encrypting all communication between the sites.</LI>
<LI>&quot;Road Warriors&quot; connect to the office from home, or perhaps from a
hotel somewhere</LI>
</UL>
<P>There is enough opportunity in these applications that vendors are
flocking to them. IPsec is being built into routers, into firewall
products, and into major operating systems, primarily to support these
applications. See our<A href="web.html#implement"> list</A> of
implementations for details.</P>
<P>We support both of those applications, and various less common IPsec
applications as well, but we also add one of our own:</P>
<UL>
<LI>opportunistic encryption, the ability to set up FreeS/WAN gateways
so that any two of them can encrypt to each other, and will do so
whenever packets pass between them.</LI>
</UL>
<P>This is an extension we are adding to the protocols. FreeS/WAN is the
first prototype implementation, though we hope other IPsec
implementations will adopt the technique once we demonstrate it. See<A href="#goals">
project goals</A> below for why we think this is important.</P>
<P>A somewhat more detailed description of each of these applications is
below. Our<A href="quickstart.html#quick_guide"> quickstart</A> section
will show you how to build each of them.</P>
<H4><A name="makeVPN">Using secure tunnels to create a VPN</A></H4>
<P>A VPN, or<STRONG> V</STRONG>irtual<STRONG> P</STRONG>rivate<STRONG> N</STRONG>
etwork lets two networks communicate securely when the only connection
between them is over a third network which they do not trust.</P>
<P>The method is to put a security gateway machine between each of the
communicating networks and the untrusted network. The gateway machines
encrypt packets entering the untrusted net and decrypt packets leaving
it, creating a secure tunnel through it.</P>
<P>If the cryptography is strong, the implementation is careful, and the
administration of the gateways is competent, then one can reasonably
trust the security of the tunnel. The two networks then behave like a
single large private network, some of whose links are encrypted tunnels
through untrusted nets.</P>
<P>Actual VPNs are often more complex. One organisation may have fifty
branch offices, plus some suppliers and clients, with whom it needs to
communicate securely. Another might have 5,000 stores, or 50,000
point-of-sale devices. The untrusted network need not be the Internet.
All the same issues arise on a corporate or institutional network
whenever two departments want to communicate privately with each other.</P>
<P>Administratively, the nice thing about many VPN setups is that large
parts of them are static. You know the IP addresses of most of the
machines involved. More important, you know they will not change on
you. This simplifies some of the admin work. For cases where the
addresses do change, see the next section.</P>
<H4><A name="road.intro">Road Warriors</A></H4>
<P>The prototypical &quot;Road Warrior&quot; is a traveller connecting to home
base from a laptop machine. Administratively, most of the same problems
arise for a telecommuter connecting from home to the office, especially
if the telecommuter does not have a static IP address.</P>
<P>For purposes of this document:</P>
<UL>
<LI>anyone with a dynamic IP address is a &quot;Road Warrior&quot;.</LI>
<LI>any machine doing IPsec processing is a &quot;gateway&quot;. Think of the
single-user road warrior machine as a gateway with a degenerate subnet
(one machine, itself) behind it.</LI>
</UL>
<P>These require somewhat different setup than VPN gateways with static
addresses and with client systems behind them, but are basically not
problematic.</P>
<P>There are some difficulties which appear for some road warrior
connections:</P>
<UL>
<LI>Road Wariors who get their addresses via DHCP may have a problem.
FreeS/WAN can quite happily build and use a tunnel to such an address,
but when the DHCP lease expires, FreeS/WAN does not know that. The
tunnel fails, and the only recovery method is to tear it down and
re-build it.</LI>
<LI>If<A href="glossary.html#NAT.gloss"> Network Address Translation</A>
(NAT) is applied between the two IPsec Gateways, this breaks IPsec.
IPsec authenticates packets on an end-to-end basis, to ensure they are
not altered en route. NAT rewrites packets as they go by. See our<A href="firewall.html#NAT">
firewalls</A> document for details.</LI>
</UL>
<P>In most situations, however, FreeS/WAN supports road warrior
connections just fine.</P>
<H4><A name="opp.intro">Opportunistic encryption</A></H4>
<P>One of the reasons we are working on FreeS/WAN is that it gives us
the opportunity to add what we call opportuntistic encryption. This
means that any two FreeS/WAN gateways will be able to encrypt their
traffic, even if the two gateway administrators have had no prior
contact and neither system has any preset information about the other.</P>
<P>Both systems pick up the authentication information they need from
the<A href="glossary.html#DNS"> DNS</A> (domain name service), the
service they already use to look up IP addresses. Of course the
administrators must put that information in the DNS, and must set up
their gateways with opportunistic encryption enabled. Once that is
done, everything is automatic. The gateways look for opportunities to
encrypt, and encrypt whatever they can. Whether they also accept
unencrypted communication is a policy decision the administrator can
make.</P>
<P>This technique can give two large payoffs:</P>
<UL>
<LI>It reduces the administrative overhead for IPsec enormously. You
configure your gateway and thereafter everything is automatic. The need
to configure the system on a per-tunnel basis disappears. Of course,
FreeS/WAN allows specifically configured tunnels to co-exist with
opportunistic encryption, but we hope to make them unnecessary in most
cases.</LI>
<LI>It moves us toward a more secure Internet, allowing users to create
an environment where message privacy is the default. All messages can
be encrypted, provided the other end is willing to co-operate. See our<A
href="politics.html#politics"> history and politics of cryptography</A>
section for discussion of why we think this is needed.</LI>
</UL>
<P>Opportunistic encryption is not (yet?) a standard part of the IPsec
protocols, but an extension we are proposing and demonstrating. For
details of our design, see<A href="#applied"> links</A> below.</P>
<P>Only one current product we know of implements a form of
opportunistic encryption.<A href="web.html#ssmail"> Secure sendmail</A>
will automatically encrypt server-to-server mail transfers whenever
possible.</P>
<H3><A name="types">The need to authenticate gateways</A></H3>
<P>A complication, which applies to any type of connection -- VPN, Road
Warrior or opportunistic -- is that a secure connection cannot be
created magically.<EM> There must be some mechanism which enables the
gateways to reliably identify each other.</EM> Without this, they
cannot sensibly trust each other and cannot create a genuinely secure
link.</P>
<P>Any link they do create without some form of<A href="glossary.html#authentication">
authentication</A> will be vulnerable to a<A href="glossary.html#middle">
man-in-the-middle attack</A>. If<A href="glossary.html#alicebob"> Alice
and Bob</A> are the people creating the connection, a villian who can
re-route or intercept the packets can pose as Alice while talking to
Bob and pose as Bob while talking to Alice. Alice and Bob then both
talk to the man in the middle, thinking they are talking to each other,
and the villain gets everything sent on the bogus &quot;secure&quot; connection.</P>
<P>There are two ways to build links securely, both of which exclude the
man-in-the middle:</P>
<UL>
<LI>with<STRONG> manual keying</STRONG>, Alice and Bob share a secret
key (which must be transmitted securely, perhaps in a note or via PGP
or SSH) to encrypt their messages. For FreeS/WAN, such keys are stored
in the<A href="manpage.d/ipsec.conf.5.html"> ipsec.conf(5)</A> file. Of
course, if an enemy gets the key, all is lost.</LI>
<LI>with<STRONG> automatic keying</STRONG>, the two systems authenticate
each other and negotiate their own secret keys. The keys are
automatically changed periodically.</LI>
</UL>
<P>Automatic keying is much more secure, since if an enemy gets one key
only messages between the previous re-keying and the next are exposed.
It is therefore the usual mode of operation for most IPsec deployment,
and the mode we use in our setup examples. FreeS/WAN does support
manual keying for special circumstanes. See this<A href="adv_config.html#prodman">
section</A>.</P>
<P>For automatic keying, the two systems must authenticate each other
during the negotiations. There is a choice of methods for this:</P>
<UL>
<LI>a<STRONG> shared secret</STRONG> provides authentication. If Alice
and Bob are the only ones who know a secret and Alice recives a message
which could not have been created without that secret, then Alice can
safely believe the message came from Bob.</LI>
<LI>a<A href="glossary.html#public"> public key</A> can also provide
authentication. If Alice receives a message signed with Bob's private
key (which of course only he should know) and she has a trustworthy
copy of his public key (so that she can verify the signature), then she
can safely believe the message came from Bob.</LI>
</UL>
<P>Public key techniques are much preferable, for reasons discussed<A href="config.html#choose">
later</A>, and will be used in all our setup examples. FreeS/WAN does
also support auto-keying with shared secret authentication. See this<A href="adv_config.html#prodsecrets">
section</A>.</P>
<H2><A name="project">The FreeS/WAN project</A></H2>
<P>For complete information on the project, see our web site,<A href="http://liberty.freeswan.org">
freeswan.org</A>.</P>
<P>In summary, we are implementing the<A href="glossary.html#IPsec">
IPsec</A> protocols for Linux and extending them to do<A href="glossary.html#carpediem">
opportunistic encryption</A>.</P>
<H3><A name="goals">Project goals</A></H3>
<P>Our overall goal in FreeS/WAN is to make the Internet more secure and
more private.</P>
<P>Our IPsec implementation supports VPNs and Road Warriors of course.
Those are important applications. Many users will want FreeS/WAN to
build corporate VPNs or to provide secure remote access.</P>
<P>However, our goals in building it go beyond that. We are trying to
help<STRONG> build security into the fabric of the Internet</STRONG> so
that anyone who choses to communicate securely can do so, as easily as
they can do anything else on the net.</P>
<P>More detailed objectives are:</P>
<UL>
<LI>extend IPsec to do<A href="glossary.html#carpediem"> opportunistic
encryption</A> so that
<UL>
<LI>any two systems can secure their communications without a
pre-arranged connection</LI>
<LI><STRONG>secure connections can be the default</STRONG>, falling back
to unencrypted connections only if:
<UL>
<LI><EM>both</EM> the partner is not set up to co-operate on securing
the connection</LI>
<LI><EM>and</EM> your policy allows insecure connections</LI>
</UL>
</LI>
<LI>a significant fraction of all Internet traffic is encrypted</LI>
<LI>wholesale monitoring of the net (<A href="politics.html#intro.poli">
examples</A>) becomes difficult or impossible</LI>
</UL>
</LI>
<LI>help make IPsec widespread by providing an implementation with no
restrictions:
<UL>
<LI>freely available in source code under the<A href="glossary.html#GPL">
GNU General Public License</A></LI>
<LI>running on a range of readily available hardware</LI>
<LI>not subject to US or other nations'<A href="politics.html#exlaw">
export restrictions</A>.
<BR> Note that in order to avoid<EM> even the appearance</EM> of being
subject to those laws, the project cannot accept software contributions
--<EM> not even one-line bug fixes</EM> -- from US residents or
citizens.</LI>
</UL>
</LI>
<LI>provide a high-quality IPsec implementation for Linux
<UL>
<LI>portable to all CPUs Linux supports:<A href="compat.html#CPUs">
(current list)</A></LI>
<LI>interoperable with other IPsec implementations:<A href="interop.html#interop">
(current list)</A></LI>
</UL>
</LI>
</UL>
<P>If we can get opportunistic encryption implemented and widely
deployed, then it becomes impossible for even huge well-funded agencies
to monitor the net.</P>
<P>See also our section on<A href="politics.html#politics"> history and
politics</A> of cryptography, which includes our project leader's<A href="politics.html#gilmore">
rationale</A> for starting the project.</P>
<H3><A name="staff">Project team</A></H3>
<P>Two of the team are from the US and can therefore contribute no code:</P>
<UL>
<LI>John Gilmore: founder and policy-maker (<A href="http://www.toad.com/gnu/">
home page</A>)</LI>
<LI>Hugh Daniel: project manager, Most Demented Tester, and occasionally
Pointy-Haired Boss</LI>
</UL>
<P>The rest of the team are Canadians, working in Canada. (<A href="politics.html#status">
Why Canada?</A>)</P>
<UL>
<LI>Hugh Redelmeier:<A href="glossary.html#Pluto"> Pluto daemon</A>
programmer</LI>
<LI>Richard Guy Briggs:<A href="glossary.html#KLIPS"> KLIPS</A>
programmer</LI>
<LI>Michael Richardson: hacker without portfolio</LI>
<LI>Claudia Schmeing: documentation</LI>
<LI>Sam Sgro: technical support via the<A href="mail.html#lists">
mailing lists</A></LI>
</UL>
<P>The project is funded by civil libertarians who consider our goals
worthwhile. Most of the team are paid for this work.</P>
<P>People outside this core team have made substantial contributions.
See</P>
<UL>
<LI>our<A href="../CREDITS"> CREDITS</A> file</LI>
<LI>the<A href="web.html#patch"> patches and add-ons</A> section of our
web references file</LI>
<LI>lists below of user-written<A href="#howto"> HowTos</A> and<A href="#applied">
other papers</A></LI>
</UL>
<P>Additional contributions are welcome. See the<A href="faq.html#contrib.faq">
FAQ</A> for details.</P>
<H2><A name="products">Products containing FreeS/WAN</A></H2>
<P>Unfortunately the<A href="politics.html#exlaw"> export laws</A> of
some countries restrict the distribution of strong cryptography.
FreeS/WAN is therefore not in the standard Linux kernel and not in all
CD or web distributions.</P>
<P>FreeS/WAN is, however, quite widely used. Products we know of that
use it are listed below. We would appreciate hearing, via the<A href="mail.html#lists">
mailing lists</A>, of any we don't know of.</P>
<H3><A name="distwith">Full Linux distributions</A></H3>
<P>FreeS/WAN is included in various general-purpose Linux distributions,
mostly from countries (shown in brackets) with more sensible laws:</P>
<UL>
<LI><A href="http://www.suse.com/">SuSE Linux</A> (Germany)</LI>
<LI><A href="http://www.conectiva.com">Conectiva</A> (Brazil)</LI>
<LI><A href="http://www.linux-mandrake.com/en/">Mandrake</A> (France)</LI>
<LI><A href="http://www.debian.org">Debian</A></LI>
<LI>the<A href="http://www.pld.org.pl/"> Polish(ed) Linux Distribution</A>
(Poland)</LI>
<LI><A>Best Linux</A> (Finland)</LI>
</UL>
<P>For distributions which do not include FreeS/WAN and are not Redhat
(which we develop and test on), there is additional information in our<A
href="compat.html#otherdist"> compatibility</A> section.</P>
<P>The server edition of<A href="http://www.corel.com"> Corel</A> Linux
(Canada) also had FreeS/WAN, but Corel have dropped that product line.</P>
<H3><A name="kernel_dist">Linux kernel distributions</A></H3>
<UL>
<LI><A href="http://sourceforge.net/projects/wolk/">Working Overloaded
Linux Kernel (WOLK)</A></LI>
</UL>
<H3><A name="office_dist">Office server distributions</A></H3>
<P>FreeS/WAN is also included in several distributions aimed at the
market for turnkey business servers:</P>
<UL>
<LI><A href="http://www.e-smith.com/">e-Smith</A> (Canada), which has
recently been acquired and become the Network Server Solutions group of<A
href="http://www.mitel.com/"> Mitel Networks</A> (Canada)</LI>
<LI><A href="http://www.clarkconnect.org/">ClarkConnect</A> from Point
Clark Networks (Canada)</LI>
<LI><A href="http://www.trustix.net/">Trustix Secure Linux</A> (Norway)</LI>
</UL>
<H3><A name="fw_dist">Firewall distributions</A></H3>
<P>Several distributions intended for firewall and router applications
include FreeS/WAN:</P>
<UL>
<LI>The<A href="http://www.linuxrouter.org/"> Linux Router Project</A>
produces a Linux distribution that will boot from a single floppy. The<A
href="http://leaf.sourceforge.net"> LEAF</A> firewall project provides
several different LRP-based firewall packages. At least one of them,
Charles Steinkuehler's Dachstein, includes FreeS/WAN with X.509
patches.</LI>
<LI>there are several distributions bootable directly from CD-ROM,
usable on a machine without hard disk.
<UL>
<LI>Dachstein (see above) can be used this way</LI>
<LI><A href="http://www.gibraltar.at/">Gibraltar</A> is based on Debian
GNU/Linux.</LI>
<LI>at time of writing,<A href="www.xiloo.com"> Xiloo</A> is available
only in Chinese. An English version is expected.</LI>
</UL>
</LI>
<LI><A href="http://www.astaro.com/products/index.html">Astaro Security
Linux</A> includes FreeS/WAN. It has some web-based tools for managing
the firewall that include FreeS/WAN configuration management.</LI>
<LI><A href="http://www.linuxwall.de">Linuxwall</A></LI>
<LI><A href="http://www.smoothwall.org/">Smoothwall</A></LI>
<LI><A href="http://www.devil-linux.org/">Devil Linux</A></LI>
<LI>Coyote Linux has a<A href="http://embedded.coyotelinux.com/wolverine/index.php">
Wolverine</A> firewall/VPN server</LI>
</UL>
<P>There are also several sets of scripts available for managing a
firewall which is also acting as a FreeS/WAN IPsec gateway. See this<A href="firewall.html#rules.pub">
list</A>.</P>
<H3><A name="turnkey">Firewall and VPN products</A></H3>
<P>Several vendors use FreeS/WAN as the IPsec component of a turnkey
firewall or VPN product.</P>
<P>Software-only products:</P>
<UL>
<LI><A href="http://www.linuxmagic.com/vpn/index.html">Linux Magic</A>
offer a VPN/Firewall product using FreeS/WAN</LI>
<LI>The Software Group's<A href="http://www.wanware.com/sentinet/">
Sentinet</A> product uses FreeS/WAN</LI>
<LI><A href="http://www.merilus.com">Merilus</A> use FreeS/WAN in their
Gateway Guardian firewall product</LI>
</UL>
<P>Products that include the hardware:</P>
<UL>
<LI>The<A href="http://www.lasat.com"> LASAT SafePipe[tm]</A> series. is
an IPsec box based on an embedded MIPS running Linux with FreeS/WAN and
a web-config front end. This company also host our freeswan.org web
site.</LI>
<LI>Merilus<A href="http://www.merilus.com/products/fc/index.shtml">
Firecard</A> is a Linux firewall on a PCI card.</LI>
<LI><A href="http://www.kyzo.com/">Kyzo</A> have a &quot;pizza box&quot; product
line with various types of server, all running from flash. One of them
is an IPsec/PPTP VPN server</LI>
<LI><A href="http://www.pfn.com">PFN</A> use FreeS/WAN in some of their
products</LI>
</UL>
<P><A href="www.rebel.com">Rebel.com</A>, makers of the Netwinder Linux
machines (ARM or Crusoe based), had a product that used FreeS/WAN. The
company is in receivership so the future of the Netwinder is at best
unclear.<A href="web.html#patch"> PKIX patches</A> for FreeS/WAN
developed at Rebel are listed in our web links document.</P>
<H2><A name="docs">Information sources</A></H2>
<H3><A name="docformats">This HowTo, in multiple formats</A></H3>
<P>FreeS/WAN documentation up to version 1.5 was available only in HTML.
Now we ship two formats:</P>
<UL>
<LI>as HTML, one file for each doc section plus a global<A href="toc.html">
Table of Contents</A></LI>
<LI><A href="HowTo.html">one big HTML file</A> for easy searching</LI>
</UL>
<P>and provide a Makefile to generate other formats if required:</P>
<UL>
<LI><A href="HowTo.pdf">PDF</A></LI>
<LI><A href="HowTo.ps">Postscript</A></LI>
<LI><A href="HowTo.txt">ASCII text</A></LI>
</UL>
<P>The Makefile assumes the htmldoc tool is available. You can download
it from<A href="http://www.easysw.com"> Easy Software</A>.</P>
<P>All formats should be available at the following websites:</P>
<UL>
<LI><A href="http://www.freeswan.org/doc.html">FreeS/WAN project</A></LI>
<LI><A href="http://www.linuxdoc.org">Linux Documentation Project</A></LI>
</UL>
<P>The distribution tarball has only the two HTML formats.</P>
<P><STRONG>Note:</STRONG> If you need the latest doc version, for
example to see if anyone has managed to set up interoperation between
FreeS/WAN and whatever, then you should download the current snapshot.
What is on the web is documentation as of the last release. Snapshots
have all changes I've checked in to date.</P>
<H3><A name="rtfm">RTFM (please Read The Fine Manuals)</A></H3>
<P>As with most things on any Unix-like system, most parts of Linux
FreeS/WAN are documented in online manual pages. We provide a list of<A href="/mnt/floppy/manpages.html">
FreeS/WAN man pages</A>, with links to HTML versions of them.</P>
<P>The man pages describing configuration files are:</P>
<UL>
<LI><A href="/mnt/floppy/manpage.d/ipsec.conf.5.html">ipsec.conf(5)</A></LI>
<LI><A href="/mnt/floppy/manpage.d/ipsec.secrets.5.html">
ipsec.secrets(5)</A></LI>
</UL>
<P>Man pages for common commands include:</P>
<UL>
<LI><A href="/mnt/floppy/manpage.d/ipsec.8.html">ipsec(8)</A></LI>
<LI><A href="/mnt/floppy/manpage.d/ipsec_pluto.8.html">ipsec_pluto(8)</A>
</LI>
<LI><A href="/mnt/floppy/manpage.d/ipsec_newhostkey.8.html">
ipsec_newhostkey(8)</A></LI>
<LI><A href="/mnt/floppy/manpage.d/ipsec_auto.8.html">ipsec_auto(8)</A></LI>
</UL>
<P>You can read these either in HTML using the links above or with the<VAR>
man(1)</VAR> command.</P>
<P>In the event of disagreement between this HTML documentation and the
man pages, the man pages are more likely correct since they are written
by the implementers. Please report any such inconsistency on the<A href="mail.html#lists">
mailing list</A>.</P>
<H3><A name="text">Other documents in the distribution</A></H3>
<P>Text files in the main distribution directory are README, INSTALL,
CREDITS, CHANGES, BUGS and COPYING.</P>
<P>The Libdes encryption library we use has its own documentation. You
can find it in the library directory..</P>
<H3><A name="assumptions">Background material</A></H3>
<P>Throughout this documentation, I write as if the reader had at least
a general familiarity with Linux, with Internet Protocol networking,
and with the basic ideas of system and network security. Of course that
will certainly not be true for all readers, and quite likely not even
for a majority.</P>
<P>However, I must limit amount of detail on these topics in the main
text. For one thing, I don't understand all the details of those topics
myself. Even if I did, trying to explain everything here would produce
extremely long and almost completely unreadable documentation.</P>
<P>If one or more of those areas is unknown territory for you, there are
plenty of other resources you could look at:</P>
<DL>
<DT>Linux</DT>
<DD>the<A href="http://www.linuxdoc.org"> Linux Documentation Project</A>
or a local<A href="http://www.linux.org/groups/"> Linux User Group</A>
and these<A href="web.html#linux.link"> links</A></DD>
<DT>IP networks</DT>
<DD>Rusty Russell's<A href="http://netfilter.samba.org/unreliable-guides/networking-concepts-HOWTO/index.html">
Networking Concepts HowTo</A> and these<A href="web.html#IP.background">
links</A></DD>
<DT>Security</DT>
<DD>Schneier's book<A href="biblio.html#secrets"> Secrets and Lies</A>
and these<A href="web.html#crypto.link"> links</A></DD>
</DL>
<P>Also, I do make an effort to provide some background material in
these documents. All the basic ideas behind IPsec and FreeS/WAN are
explained here. Explanations that do not fit in the main text, or that
not everyone will need, are often in the<A href="glossary.html#ourgloss">
glossary</A>, which is the largest single file in this document set.
There is also a<A href="background.html#background"> background</A>
file containing various explanations too long to fit in glossary
definitions. All files are heavily sprinkled with links to each other
and to the glossary.<STRONG> If some passage makes no sense to you, try
the links</STRONG>.</P>
<P>For other reference material, see the<A href="biblio.html#biblio">
bibliography</A> and our collection of<A href="web.html#weblinks"> web
links</A>.</P>
<P>Of course, no doubt I get this (and other things) wrong sometimes.
Feedback via the<A href="mail.html#lists"> mailing lists</A> is
welcome.</P>
<H3><A name="archives">Archives of the project mailing list</A></H3>
<P>Until quite recently, there was only one FreeS/WAN mailing list, and
archives of it were:</P>
<UL>
<LI><A href="http://www.sandelman.ottawa.on.ca/linux-ipsec">Canada</A></LI>
<LI><A href="http://www.nexial.com">Holland</A></LI>
</UL>
The two archives use completely different search engines. You might
want to try both.
<P>More recently we have expanded to five lists, each with its own
archive.</P>
<P><A href="mail.html#lists">More information</A> on mailing lists.</P>
<H3><A name="howto">User-written HowTo information</A></H3>
<P>Various user-written HowTo documents are available. The ones covering
FreeS/WAN-to-FreeS/WAN connections are:</P>
<UL>
<LI>Jean-Francois Nadeau's<A href="http://jixen.tripod.com/"> practical
configurations</A> document</LI>
<LI>Jens Zerbst's HowTo on<A href="http://dynipsec.tripod.com/"> Using
FreeS/WAN with dynamic IP addresses</A>.</LI>
<LI>an entry in Kurt Seifried's<A href="http://www.securityportal.com/lskb/kben00000013.html">
Linux Security Knowledge Base</A>.</LI>
<LI>a section of David Ranch's<A href="http://www.ecst.csuchico.edu/~dranch/LINUX/index-linux.html#trinityos">
Trinity OS Guide</A></LI>
<LI>a section in David Bander's book<A href="biblio.html#bander"> Linux
Security Toolkit</A></LI>
</UL>
<P>User-wriiten HowTo material may be<STRONG> especially helpful if you
need to interoperate with another IPsec implementation</STRONG>. We
have neither the equipment nor the manpower to test such
configurations. Users seem to be doing an admirable job of filling the
gaps.</P>
<UL>
<LI>list of user-written<A href="interop.html#otherpub"> interoperation
HowTos</A> in our interop document</LI>
</UL>
<P>Check what version of FreeS/WAN user-written documents cover. The
software is under active development and the current version may be
significantly different from what an older document describes.</P>
<H3><A name="applied">Papers on FreeS/WAN</A></H3>
<P>Two design documents show team thinking on new developments:</P>
<UL>
<LI><A href="opportunism.spec">Opportunistic Encryption</A> by technical
lead Henry Spencer and Pluto programmer Hugh Redelemeier</LI>
<LI>discussion of<A href="http://www.sandelman.ottawa.on.ca/SSW/freeswan/klips2req/">
KLIPS redesign</A></LI>
</UL>
<P>Both documents are works in progress and are frequently revised. For
the latest version, see the<A href="mail.html#lists"> design mailing
list</A>. Comments should go to that list.</P>
<P>There is now an<A href="http://www.ietf.org/internet-drafts/draft-richardson-ipsec-opportunistic-06.txt">
Internet Draft on Opportunistic Encryption</A> by Michael Richardson,
Hugh Redelmeier and Henry Spencer. This is a first step toward getting
the protocol standardised so there can be multiple implementations of
it. Discussion of it takes place on the<A href="http://www.ietf.org/html.charters/ipsec-charter.html">
IETF IPsec Working Group</A> mailing list.</P>
<P>A number of papers giving further background on FreeS/WAN, or
exploring its future or its applications, are also available:</P>
<UL>
<LI>Both Henry and Richard gave talks on FreeS/WAN at the 2000<A href="http://www.linuxsymposium.org">
Ottawa Linux Symposium</A>.
<UL>
<LI>Richard's<A href="http://www.conscoop.ottawa.on.ca/rgb/freeswan/ols2k/">
slides</A></LI>
<LI>Henry's paper</LI>
<LI>MP3 audio of their talks is available from the<A href="http://www.linuxsymposium.org/">
conference page</A></LI>
</UL>
</LI>
<LI><CITE>Moat: A Virtual Private Network Appliances and Services
Platform</CITE> is a paper about large-scale (a few 100 links) use of
FreeS/WAN in a production application at AT&amp;T Research. It is available
in Postscript or PDF from co-author Steve Bellovin's<A href="http://www.research.att.com/~smb/papers/index.html">
papers list page</A>.</LI>
<LI>One of the Moat co-authors, John Denker, has also written
<UL>
<LI>a<A href="http://www.av8n.com/vpn/ipsec+routing.htm"> proposal</A>
for how future versions of FreeS/WAN might interact with routing
protocols</LI>
<LI>a<A href="http://www.av8n.com/vpn/wishlist.htm"> wishlist</A> of
possible new features</LI>
</UL>
</LI>
<LI>Bart Trojanowski's web page has a draft design for<A href="http://www.jukie.net/~bart/linux-ipsec/">
hardware acceleration</A> of FreeS/WAN</LI>
</UL>
<P>Several of these provoked interesting discussions on the mailing
lists, worth searching for in the<A href="mail.html#archive"> archives</A>
.</P>
<P>There are also several papers in languages other than English, see
our<A href="web.html#otherlang"> web links</A>.</P>
<H3><A name="licensing">License and copyright information</A></H3>
<P>All code and documentation written for this project is distributed
under either the GNU General Public License (<A href="glossary.html#GPL">
GPL</A>) or the GNU Library General Public License. For details see the
COPYING file in the distribution.</P>
<P>Not all code in the distribution is ours, however. See the CREDITS
file for details. In particular, note that the<A href="glossary.html#LIBDES">
Libdes</A> library and the version of<A href="glossary.html#MD5"> MD5</A>
that we use each have their own license.</P>
<H2><A name="sites">Distribution sites</A></H2>
<P>FreeS/WAN is available from a number of sites.</P>
<H3><A NAME="1_5_1">Primary site</A></H3>
<P>Our primary site, is at xs4all (Thanks, folks!) in Holland:</P>
<UL>
<LI><A href="http://www.xs4all.nl/~freeswan">HTTP</A></LI>
<LI><A href="ftp://ftp.xs4all.nl/pub/crypto/freeswan">FTP</A></LI>
</UL>
<H3><A name="mirrors">Mirrors</A></H3>
<P>There are also mirror sites all over the world:</P>
<UL>
<LI><A href="http://www.flora.org/freeswan">Eastern Canada</A> (limited
resouces)</LI>
<LI><A href="ftp://ludwig.doculink.com/pub/freeswan/">Eastern Canada</A>
(has older versions too)</LI>
<LI><A href="ftp://ntsc.notBSD.org/pub/crypto/freeswan/">Eastern Canada</A>
(has older versions too)</LI>
<LI><A href="ftp://ftp.kame.net/pub/freeswan/">Japan</A></LI>
<LI><A href="ftp://ftp.futuredynamics.com/freecrypto/FreeSWAN/">Hong
Kong</A></LI>
<LI><A href="ftp://ipsec.dk/pub/freeswan/">Denmark</A></LI>
<LI><A href="ftp://ftp.net.lut.ac.uk/freeswan">the UK</A></LI>
<LI><A href="http://storm.alert.sk/comp/mirrors/freeswan/">Slovak
Republic</A></LI>
<LI><A href="http://the.wiretapped.net/security/vpn-tunnelling/freeswan/">
Australia</A></LI>
<LI><A href="http://freeswan.technolust.cx/">technolust</A></LI>
<LI><A href="http://freeswan.devguide.de/">Germany</A></LI>
<LI>Ivan Moore's<A href="http://snowcrash.tdyc.com/freeswan/"> site</A></LI>
<LI>the<A href="http://www.cryptoarchive.net/"> Crypto Archive</A> on
the<A href="http://www.securityportal.com/"> Security Portal</A> site</LI>
<LI><A href="http://www.wiretapped.net/">Wiretapped.net</A> in Australia</LI>
</UL>
<P>Thanks to those folks as well.</P>
<H3><A name="munitions">The &quot;munitions&quot; archive of Linux crypto software</A>
</H3>
<P>There is also an archive of Linux crypto software called &quot;munitions&quot;,
with its own mirrors in a number of countries. It includes FreeS/WAN,
though not always the latest version. Some of its sites are:</P>
<UL>
<LI><A href="http://munitions.vipul.net/">Germany</A></LI>
<LI><A href="http://munitions.iglu.cjb.net/">Italy</A></LI>
<LI><A href="http://munitions2.xs4all.nl/">Netherlands</A></LI>
</UL>
<P>Any of those will have a list of other &quot;munitions&quot; mirrors. There is
also a CD available.</P>
<H2><A NAME="1_6">Links to other sections</A></H2>
<P>For more detailed background information, see:</P>
<UL>
<LI><A href="politics.html#politics">history and politics</A> of
cryptography</LI>
<LI><A href="ipsec.html#ipsec.detail">IPsec protocols</A></LI>
</UL>
<P>To begin working with FreeS/WAN, go to our<A href="quickstart.html#quick.guide">
quickstart</A> guide.</P>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="upgrading.html">Next</A>
</BODY>
</HTML>

22
doc/ipsec.conf.2_to_1 Normal file
View File

@ -0,0 +1,22 @@
version 2
# If you put the preceding line in front of a 1.x ipsec.conf,
# it should work within 2.x.
# Merge the following sections with your existing config setup
# and conn %default.
# Allot these values to any you have not explictly defined.
config setup
interfaces=%none # new default is %defaultroute
plutoload=%none # new default is %search
plutostart=%none # new default is %search
conn %default
uniqueids=no # new default is yes
keyingtries=3 # new default is %forever
disablearrivalcheck=yes # new default is no
authby=secret # new default is rsasig
leftrsasigkey=%none # new default %dnsondemand
rightrsasigkey=%none # new default %dnsondemand

1040
doc/ipsec.html Normal file
View File

File diff suppressed because it is too large Load Diff

353
doc/kernel.html Normal file
View File

@ -0,0 +1,353 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="testing.html">Previous</A>
<A HREF="adv_config.html">Next</A>
<HR>
<H1><A name="kernelconfig">Kernel configuration for FreeS/WAN</A></H1>
<P> This section lists many of the options available when configuring a
Linux kernel, and explains how they should be set on a FreeS/WAN IPsec
gateway.</P>
<H2><A name="notall">Not everyone needs to worry about kernel
configuration</A></H2>
<P>Note that in many cases you do not need to mess with these.</P>
<P> You may have a Linux distribution which comes with FreeS/WAN
installed (see this<A href="intro.html#products"> list</A>). In that
case, you need not do a FreeS/WAN installation or a kernel
configuration. Of course, you might still want to configure and rebuild
your kernel to improve performance or security. This can be done with
standard tools described in the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
Kernel HowTo</A>.</P>
<P>If you need to install FreeS/WAN, then you do need to configure a
kernel. However, you may choose to do that using the simplest
procedure:</P>
<UL>
<LI>Configure, build and test a kernel for your system before adding
FreeS/WAN. See the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
Kernel HowTo</A> for details.<STRONG> This step cannot be skipped</STRONG>
. FreeS/WAN needs the results of your configuration.</LI>
<LI>Then use FreeS/WAN's<VAR> make oldgo</VAR> command. This sets
everything FreeS/WAN needs and retains your values everywhere else.</LI>
</UL>
<P> This document is for those who choose to configure their FreeS/WAN
kernel themselves.</P>
<H2><A name="assume">Assumptions and notation</A></H2>
<P> Help text for most kernel options is included with the kernel files,
and is accessible from within the configuration utilities. We assume
you will refer to that, and to the<A href="http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html">
Kernel HowTo</A>, as necessary. This document covers only the
FreeS/WAN-specific aspects of the problem.</P>
<P> To avoid duplication, this document section does not cover settings
for the additional IPsec-related kernel options which become available
after you have patched your kernel with FreeS/WAN patches. There is
help text for those available from within the configuration utility.</P>
<P> We assume a common configuration in which the FreeS/WAN IPsec
gateway is also doing ipchains(8) firewalling for a local network, and
possibly masquerading as well.</P>
<P> Some suggestions below are labelled as appropriate for &quot;a true
paranoid&quot;. By this we mean they may cause inconvenience and it is not
entirely clear they are necessary, but they appear to be the safest
choice. Not using them might entail some risk. Of course one suggested
mantra for security administrators is: &quot;I know I'm paranoid. I wonder
if I'm paranoid enough.&quot;</P>
<H3><A name="labels">Labels used</A></H3>
<P> Six labels are used to indicate how options should be set. We mark
the labels with [square brackets]. For two of these labels, you have no
choice:</P>
<DL>
<DT>[required]</DT>
<DD>essential for FreeS/WAN operation.</DD>
<DT>[incompatible]</DT>
<DD>incompatible with FreeS/WAN.</DD>
</DL>
<P>those must be set correctly or FreeS/WAN will not work</P>
<P>FreeS/WAN should work with any settings of the others, though of
course not all combinations have been tested. We do label these in
various ways, but<EM> these labels are only suggestions</EM>.</P>
<DL>
<DT>[recommended]</DT>
<DD>useful on most FreeS/WAN gateways</DD>
<DT>[disable]</DT>
<DD>an unwelcome complication on a FreeS/WAN gateway.</DD>
<DT>[optional]</DT>
<DD>Your choice. We outline issues you might consider.</DD>
<DT>[anything]</DT>
<DD>This option has no direct effect on FreeS/WAN and related tools, so
you should be able to set it as you please.</DD>
</DL>
<P> Of course complexity is an enemy in any effort to build secure
systems.<STRONG> For maximum security, any feature that can reasonably
be turned off should be</STRONG>. &quot;If in doubt, leave it out.&quot;</P>
<H2><A name="kernelopt">Kernel options for FreeS/WAN</A></H2>
<P> Indentation is based on the nesting shown by 'make menuconfig' with
a 2.2.16 kernel for the i386 architecture.</P>
<DL>
<DT><A name="maturity">Code maturity and level options</A></DT>
<DD>
<DL>
<DT><A name="devel">Prompt for development ... code/drivers</A></DT>
<DD>[optional] If this is<VAR> no</VAR>, experimental drivers are not
shown in later menus.
<P>For most FreeS/WAN work,<VAR> no</VAR> is the preferred setting.
Using new or untested components is too risky for a security gateway.</P>
<P>However, for some hardware (such as the author's network cards) the
only drivers available are marked<VAR> new/experimental</VAR>. In such
cases, you must enable this option or your cards will not appear under
&quot;network device support&quot;. A true paranoid would leave this option off
and replace the cards.</P>
</DD>
<DT>Processor type and features</DT>
<DD>[anything]</DD>
<DT>Loadable module support</DT>
<DD>
<DL>
<DT>Enable loadable module support</DT>
<DD>[optional] A true paranoid would disable this. An attacker who has
root access to your machine can fairly easily install a bogus module
that does awful things, provided modules are enabled. A common tool for
attackers is a &quot;rootkit&quot;, a set of tools the attacker uses once he or
she has become root on your system. The kit introduces assorted
additional compromises so that the attacker will continue to &quot;own&quot; your
system despite most things you might do to recovery the situation. For
Linux, there is a tool called<A href="http://www.sans.org/newlook/resources/IDFAQ/knark.htm">
knark</A> which is basically a rootkit packaged as a kernel module.
<P>With modules disabled, an attacker cannot install a bogus module. The
only way he can achieve the same effects is to install a new kernel and
reboot. This is considerably more likely to be noticed.</P>
<P>Many FreeS/WAN gateways run with modules enabled. This simplifies
some administrative tasks and some ipchains features are available only
as modules. Once an enemy has root on your machine your security is
nil, so arguably defenses which come into play only in that situation
are pointless.</P>
<P></P>
</DD>
<DT>Set version information ....</DT>
<DD>[optional] This provides a check to prevent loading modules compiled
for a different kernel.</DD>
<DT>Kernel module loader</DT>
<DD>[disable] It gives little benefit on a typical FreeS/WAN gate and
entails some risk.</DD>
</DL>
</DD>
<DT>General setup</DT>
<DD>We list here only the options that matter for FreeS/WAN.
<DL>
<DT>Networking support</DT>
<DD>[required]</DD>
<DT>Sysctl interface</DT>
<DD>[optional] If this option is turned on and the<VAR> /proc</VAR>
filesystem installed, then you can control various system behaviours by
writing to files under<VAR> /proc/sys</VAR>. For example:
<PRE> echo 1 &gt; /proc/sys/net/ipv4/ipforward</PRE>
turns IP forwarding on.
<P>Disabling this option breaks many firewall scripts. A true paranoid
would disable it anyway since it might conceivably be of use to an
attacker.</P>
</DD>
</DL>
</DD>
<DT>Plug and Play support</DT>
<DD>[anything]</DD>
<DT>Block devices</DT>
<DD>[anything]</DD>
<DT>Networking options</DT>
<DD>
<DL>
<DT>Packet socket</DT>
<DD>[optional] This kernel feature supports tools such as tcpdump(8)
which communicate directly with network hardware, bypassing kernel
protocols. This is very much a two-edged sword:
<UL>
<LI>such tools can be very useful to the firewall admin, especially
during initial testing</LI>
<LI>should an evildoer breach your firewall, such tools could give him
or her a great deal of information about the rest of your network</LI>
</UL>
We recommend disabling this option on production gateways.</DD>
<DT><A name="netlink">Kernel/User netlink socket</A></DT>
<DD>[optional] Required if you want to use<A href="#adv"> advanced
router</A> features.</DD>
<DT>Routing messages</DT>
<DD>[optional]</DD>
<DT>Netlink device emulation</DT>
<DD>[optional]</DD>
<DT>Network firewalls</DT>
<DD>[recommended] You need this if the IPsec gateway also functions as a
firewall.
<P>Even if the IPsec gateway is not your primary firewall, we suggest
setting this so that you can protect the gateway with at least basic
local packet filters.</P>
</DD>
<DT>Socket filtering</DT>
<DD>[disable] This enables an older filtering interface. We suggest
using ipchains(8) instead. To do that, set the &quot;Network firewalls&quot;
option just above, and not this one.</DD>
<DT>Unix domain sockets</DT>
<DD>[required] These sockets are used for communication between the<A href="manpage.d/ipsec.8.html">
ipsec(8)</A> commands and the<A href="manpage.d/ipsec_pluto.8.html">
ipsec_pluto(8)</A> daemon.</DD>
<DT>TCP/IP networking</DT>
<DD>[required]
<DL>
<DT>IP: multicasting</DT>
<DD>[anything]</DD>
<DT><A name="adv">IP: advanced router</A></DT>
<DD>[optional] This gives you policy routing, which some people have
used to good advantage in their scripts for FreeS/WAN gateway
management. It is not used in our distributed scripts, so not required
unless you want it for custom scripts. It requires the<A href="#netlink">
netlink</A> interface between kernel code and the iproute2(8) command.</DD>
<DT>IP: kernel level autoconfiguration</DT>
<DD>[disable] It gives little benefit on a typical FreeS/WAN gate and
entails some risk.</DD>
<DT>IP: firewall packet netlink device</DT>
<DD>[disable]</DD>
<DT>IP: transparent proxy support</DT>
<DD>[optional] This is required in some firewall configurations, but
should be disabled unless you have a definite need for it.</DD>
<DT>IP: masquerading</DT>
<DD>[optional] Required if you want to use<A href="glossary.html#non-routable">
non-routable</A> private IP addresses for your local network.</DD>
<DT>IP: Optimize as router not host</DT>
<DD>[recommended]</DD>
<DT>IP: tunneling</DT>
<DD>[required]</DD>
<DT>IP: GRE tunnels over IP</DT>
<DD>[anything]</DD>
<DT>IP: aliasing support</DT>
<DD>[anything]</DD>
<DT>IP: ARP daemon support (EXPERIMENTAL)</DT>
<DD>Not required on most systems, but might prove useful on
heavily-loaded gateways.</DD>
<DT>IP: TCP syncookie support</DT>
<DD>[recommended] It provides a defense against a<A href="glossary.html#DOS">
denial of service attack</A> which uses bogus TCP connection requests
to waste resources on the victim machine.</DD>
<DT>IP: Reverse ARP</DT>
<DD></DD>
<DT>IP: large window support</DT>
<DD>[recommended] unless you have less than 16 meg RAM</DD>
</DL>
</DD>
<DT>IPv6</DT>
<DD>[optional] FreeS/WAN does not currently support IPv6, though work on
integrating FreeS/WAN with the Linux IPv6 stack has begun.<A href="compat.html#ipv6">
Details</A>.
<P> It should be possible to use IPv4 FreeS/WAN on a machine which also
does IPv6. This combination is not yet well tested. We would be quite
interested in hearing results from anyone expermenting with it, via the<A
href="mail.html"> mailing list</A>.</P>
<P> We do not recommend using IPv6 on production FreeS/WAN gateways
until more testing has been done.</P>
</DD>
<DT>Novell IPX</DT>
<DD>[disable]</DD>
<DT>Appletalk</DT>
<DD>[disable] Quite a few Linux installations use IP but also have some
other protocol, such as Appletalk or IPX, for communication with local
desktop machines. In theory it should be possible to configure IPsec
for the IP side of things without interfering with the second protocol.
<P>We do not recommend this. Keep the software on your gateway as simple
as possible. If you need a Linux-based Appletalk or IPX server, use a
separate machine.</P>
</DD>
</DL>
</DD>
<DT>Telephony support</DT>
<DD>[anything]</DD>
<DT>SCSI support</DT>
<DD>[anything]</DD>
<DT>I2O device support</DT>
<DD>[anything]</DD>
<DT>Network device support</DT>
<DD>[anything] should work, but there are some points to note.
<P>The development team test almost entirely on 10 or 100 megabit
Ethernet and modems. In principle, any device that can do IP should be
just fine for IPsec, but in the real world any device that has not been
well-tested is somewhat risky. By all means try it, but don't bet your
project on it until you have solid test results.</P>
<P>If you disabled experimental drivers in the<A href="#maturity"> Code
maturity</A> section above, then those drivers will not be shown here.
Check that option before going off to hunt for missing drivers.</P>
<P>If you want Linux to automatically find more than one ethernet
interface at boot time, you need to:</P>
<UL>
<LI>compile the appropriate driver(s) into your kernel. Modules will not
work for this</LI>
<LI>add a line such as
<PRE>
append=&quot;ether=0,0,eth0 ether=0,0,eth1&quot;
</PRE>
to your /etc/lilo.conf file. In some cases you may need to specify
parameters such as IRQ or base address. The example uses &quot;0,0&quot; for
these, which tells the system to search. If the search does not succeed
on your hardware, then you should retry with explicit parameters. See
the lilo.conf(5) man page for details.</LI>
<LI>run lilo(8)</LI>
</UL>
Having Linux find the cards this way is not necessary, but is usually
more convenient than loading modules in your boot scripts.</DD>
<DT>Amateur radio support</DT>
<DD>[anything]</DD>
<DT>IrDA (infrared) support</DT>
<DD>[anything]</DD>
<DT>ISDN subsystem</DT>
<DD>[anything]</DD>
<DT>Old CDROM drivers</DT>
<DD>[anything]</DD>
<DT>Character devices</DT>
<DD>The only required character device is:
<DL>
<DT>random(4)</DT>
<DD>[required] This is a source of<A href="glossary.html#random"> random</A>
numbers which are required for many cryptographic protocols, including
several used in IPsec.
<P>If you are comfortable with C source code, it is likely a good idea
to go in and adjust the<VAR> #define</VAR> lines in<VAR>
/usr/src/linux/drivers/char/random.c</VAR> to ensure that all sources
of randomness are enabled. Relying solely on keyboard and mouse
randomness is dubious procedure for a gateway machine. You could also
increase the randomness pool size from the default 512 bytes (128
32-bit words).</P>
</DD>
</DL>
</DD>
<DT>Filesystems</DT>
<DD>[anything] should work, but we suggest limiting a gateway machine to
the standard Linux ext2 filesystem in most cases.</DD>
<DT>Network filesystems</DT>
<DD>[disable] These systems are an unnecessary risk on an IPsec gateway.</DD>
<DT>Console drivers</DT>
<DD>[anything]</DD>
<DT>Sound</DT>
<DD>[anything] should work, but we suggest enabling sound only if you
plan to use audible alarms for firewall problems.</DD>
<DT>Kernel hacking</DT>
<DD>[disable] This might be enabled on test machines, but should not be
on production gateways.</DD>
</DL>
</DD>
</DL>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="testing.html">Previous</A>
<A HREF="adv_config.html">Next</A>
</BODY>
</HTML>

173
doc/kernel.notes Normal file
View File

@ -0,0 +1,173 @@
Notes on Red Hat 5.2 kernel installation (See Addendum for RH6.1)
=================================================================
Warning: We (the FreeS/WAN Project http://www.xs4all.nl/~freeswan/)
had nothing to do with designing the kernel installation process. This
document explains some tricky points that we wish we had been told.
We don't know if these notes apply to systems other than Red Hat 5.2.
This is meant as a supplement to other kernel install guides (such as
the Red Hat 5.2 Installation Guide section 11.6).
Goal: install a new kernel on RH5.2 in such a way that it doesn't
interfere with any other kernels. This should be repeatable: each new
kernel should have this property. Each should remain bootable.
Problem: there are several components to a kernel, and each must be
segregated. How are the parts kept apart? How are they found?
All the parts live in the file system, so it all comes down to
pathnames. Well, except for the fiddly bits in /etc/lilo.conf. What
are the parts?
/lib/modules/VER/ directory for kernel modules
/boot/vmlinux-VER the kernel
/boot/System.map-VER the kernel symbol table
/boot/initrd-VER.img the initial ramdisk (for modules needed
at boot time -- usually not necessary)
/boot/boot.b the second-stage loader
/boot/map the map file, an index into system index for
all files used by boot loader (all kernels,
all initrds, perhaps /boot/boot.b, and itself)
This list does not include /boot/module-info-VER. That is supplied
by RedHat, and it isn't clear to me how to build it or why.
In each entry, I've used "VER" to signify a version number. For
RH-supplied kernels, these look like 2.0.36-0.7 (the original 5.2) or
2.0.36-3 (the kernel updates).
There are also symbolic links:
/lib/modules/preferred created by /etc/rc.d/rc.sysinit
/boot/System.map created by /etc/rc.d/rc.sysinit
/boot/module-info created by /etc/rc.d/rc.sysinit
/vmlinuz created by ???
I don't know when the /vmlinuz symlink is set up and I don't know
for what it is used.
If you follow the RH procedures, documented in 11.6 of their Installation
Guide, all your VERs will be 2.0.36. This is very bad: all your builds
will step on each other. Worse, your new module directory will be half
picked up when you boot a stock RH kernel binary!
It is important to know how the various parts of the built kernel are
found at booting.
- the kernel path is specified in the image= option in lilo.conf.
(Lilo.conf may specify several and one is selected at boot time
by default or user selection.) The kernel is loaded by the
boot loader.
- The initial ramdisk is a per-image option (initrd=) specified in
lilo.conf. (It isn't described in the RH5.2 lilo.conf(5) manpage!).
The initial ramdisk is loaded into RAM by the boot loader.
- Since the boot loader doesn't know about the file system, it needs a
map to figure out which absolute disk blocks to load, and where.
This is /boot/map. It is built by the lilo command (also known as
the map installer). It will have indices for the all the kernels
that can be booted, all their initial ram disks, perhaps
/boot/boot.b, and itself. This is why moving the blocks of these
files throws off the boot loader -- lilo must be rerun after even a
cp command to one of them.
- the modules directory is found two different ways. Unfortunately,
they don't mesh properly:
+ at boot time, /etc/rc.d/rc.sysinit tries to figure out the correct
subdirectory of /lib/modules, using the .rhkmvtag trick (see
later). It then builds a symlink /lib/modules/preferred to
record this. It also invokes depmod to build the module
dependency info. At the same time, it creates the symlinks
/boot/System.map and /boot/module-info, using the inferred
value for VER!
+ modprobe and friends stupidly look first in /lib/modules/2.0.36
(more precisely, /lib/modules/`uname -r`) and then in
/lib/modules/preferred. So if there is a /lib/modules/2.0.36 and
it is the wrong one, you are in trouble.
If there is no /lib/modules/2.0.36, then both searches above will
agree (a very Good Thing). So I recommend strongly that you not
have a /lib/boot/2.0.36 at boot time. Unfortunately, you will get
one during the kernel install process. Be sure to rename it. I
suggest using 2.0.36-x (for some unique x) as VER.
- Red Hat supplied /lib/modules/VER directories contain a hidden file
.rhkmvtag. This file contains exactly one line. This line is
exactly the same as the contents of /proc/version while the
corresponding kernel is running. For the stock kernel, the line is:
Linux version 2.0.36 (root@porky.redhat.com) (gcc version 2.7.2.3) #1 Tue Dec 29 13:11:13 EST 1998
- At boot time, /etc/rc.d/rc.sysinit uses the .rhkmvtag files to
figure out which of the /lib/modules/* directories matches the
kernel. If it could figure out the directory, it uses this
information to set the symlinks mentioned above. It then runs
depmod to build the module dependency information (in
/lib/modules/preferred/modules.dep, if it created the
/lib/modules/preferred symlink). I recommend looking at the code.
- The documented kernel install procedures DO NOT fill in the
.rhkmvtag file for the new modules directory! So you should do so
by hand. You have to figure out what the contents should be. Here
is is a command that will do the job, assuming that
/usr/src/linux/vmlinux is the kernel associated with
/lib/modules/2.0.36/:
strings /usr/src/linux/vmlinux \
| grep 'x version' >/lib/modules/2.0.36/.rhkmvtag
I've recommended (above) that you use 2.0.36-x for VER when you install
a kernel. What should x be? I have found that there is a hidden file
/usr/src/linux/.version which contains a counter that gets incremented
whenever you do a "make install" in the kernel (see target
newversion). There are some other times that it gets incremented, but
I think that it all works out. It also gets incorporated into the
resulting kernel's /proc/version, prefixed with ``#''. This makes it
a natural.
Here is a script to do the recommended renaming:
# VER will eventually need to be updated
VER=2.0.36
VERX=${VER}-`cat /usr/src/linux/.version`
strings /usr/src/linux/vmlinux | grep 'x version' >/lib/modules/$VER/.rhkmvtag
mv /lib/modules/$VER /lib/modules/$VERX
mv /boot/System.map-$VER /boot/System.map-$VERX
mv /boot/vmlinuz-$VER /boot/vmlinuz-$VERX
And, if an initrd has been built (usually it is best to arrange not to
use one -- see the Red Hat Installation Guide):
/sbin/mkinitrd /boot/initrd-$VERX.img $VERX
Remember: a new lilo.conf entry is needed for the new kernel, and then
the lilo command will need to be rerun.
Now that kernel installs don't overwrite the results of previous ones,
you will need to manually delete the components and their lilo entry
to get rid of them.
Please send comments, additions, and corrections to:
Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253
Addendum: Red Hat 6.1
=====================
The kernel supplied with RH6.1 kernel is out of date, so you might
wish to use a newer one.
Much of the description for 5.2 still applies, but the procedure is
quite different because the .version file is no longer used. Instead,
the top-level Makefile contains a definition EXTRAVERSION which adds a
qualifier to the version for most purposes. No manual renaming is
required.
Before building the kernel, change EXTRAVERSION by editing
/usr/src/linux/Makefile, and make an appropriate entry in /etc/lilo.conf.
EXTRAVERSION is a feature of the standard kernel sources, not just the
ones supplied by Red Hat.

216
doc/mail.html Normal file
View File

@ -0,0 +1,216 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="ipsec.html">Previous</A>
<A HREF="web.html">Next</A>
<HR>
<H1><A name="lists">Mailing lists and newsgroups</A></H1>
<H2><A name="list.fs">Mailing lists about FreeS/WAN</A></H2>
<H3><A name="projlist">The project mailing lists</A></H3>
<P>The Linux FreeS/WAN project has several email lists for user support,
bug reports and software development discussions.</P>
<P>We had a single list on clinet.fi for several years (Thanks, folks!),
then one list on freeswan.org, but now we've split into several lists:</P>
<DL>
<DT><A href="mailto:users-request@lists.freeswan.org?body=subscribe">
users</A></DT>
<DD>
<UL>
<LI>The general list for discussing use of the software</LI>
<LI>The place for seeking<STRONG> help with problems</STRONG> (but
please check the<A href="faq.html"> FAQ</A> first).</LI>
<LI>Anyone can post.</LI>
</UL>
</DD>
<DT><A href="mailto:bugs-request@lists.freeswan.org?body=subscribe">bugs</A>
</DT>
<DD>
<UL>
<LI>For<STRONG> bug reports</STRONG>.</LI>
<LI>If you are not certain what is going on -- could be a bug, a
configuration error, a network problem, ... -- please post to the users
list instead.</LI>
<LI>Anyone can post.</LI>
</UL>
</DD>
<DT><A href="mailto:design-request@lists.freeswan.org?body=subscribe">
design</A></DT>
<DD>
<UL>
<LI><STRONG>Design discussions</STRONG>, for people working on FreeS/WAN
development or others with an interest in design and security issues.</LI>
<LI>It would be a good idea to read the existing design papers (see this<A
href="intro.html#applied"> list</A>) before posting.</LI>
<LI>Anyone can post.</LI>
</UL>
</DD>
<DT><A href="mailto:announce-request@lists.freeswan.org?body=subscribe">
announce</A></DT>
<DD>
<UL>
<LI>A<STRONG> low-traffic</STRONG> list.</LI>
<LI><STRONG>Announcements</STRONG> about FreeS/WAN and related software.</LI>
<LI>All posts here are also sent to the users list. You need not
subscribe to both.</LI>
<LI>Only the FreeS/WAN team can post.</LI>
<LI>If you have something you feel should go on this list, send it to<VAR>
announce-admin@lists.freeswan.org</VAR>. Unless it is obvious, please
include a short note explaining why we should post it.</LI>
</UL>
</DD>
<DT><A href="mailto:briefs-request@lists.freeswan.org?body=subscribe">
briefs</A></DT>
<DD>
<UL>
<LI>A<STRONG> low-traffic</STRONG> list.</LI>
<LI><STRONG>Weekly summaries</STRONG> of activity on the users list.</LI>
<LI>All posts here are also sent to the users list. You need not
subscribe to both.</LI>
<LI>Only the FreeS/WAN team can post.</LI>
</UL>
</DD>
</DL>
<P>To subscribe to any of these, you can:</P>
<UL>
<LI>just follow the links above</LI>
<LI>use our<A href="http://www.freeswan.org/mail.html"> web interface</A>
</LI>
<LI>send mail to<VAR> listname</VAR>-request@lists.freeswan.org with a
one-line message body &quot;subscribe&quot;</LI>
</UL>
<P>Archives of these lists are available via the<A href="http://www.freeswan.org/mail.html">
web interface</A>.</P>
<H4><A name="which.list">Which list should I use?</A></H4>
<P>For most questions, please check the<A href="faq.html"> FAQ</A>
first, and if that does not have an answer, ask on the users list. &quot;My
configuration doesn't work.&quot; does not belong on the bugs list, and &quot;Can
FreeS/WAN do such-and-such&quot; or &quot;How do I configure it to...&quot; do not
belong in design discussions.</P>
<P>Cross-posting the same message to two or more of these lists is
discouraged. Quite a few people read more than one list and getting
multiple copies is annoying.</P>
<H4><A name="policy.list">List policies</A></H4>
<P><STRONG>US citizens or residents are asked not to post code to the
lists, not even one-line bug fixes</STRONG>. The project cannot accept
code which might entangle it in US<A href="politics.html#exlaw"> export
restrictions</A>.</P>
<P>Non-subscribers can post to some of these lists. This is necessary;
someone working on a gateway install who encounters a problem may not
have access to a subscribed account.</P>
<P>Some spam turns up on these lists from time to time. For discussion
of why we do not attempt to filter it, see the<A href="faq.html#spam">
FAQ</A>. Please do not clutter the lists with complaints about this.</P>
<H3><A name="archive">Archives of the lists</A></H3>
<P>Searchable archives of the old single list have existed for some
time. At time of writing, it is not yet clear how they will change for
the new multi-list structure.</P>
<UL>
<LI><A href="http://www.sandelman.ottawa.on.ca/linux-ipsec">Canada</A></LI>
<LI><A href="http://www.nexial.com">Holland</A></LI>
</UL>
<P>Note that these use different search engines. Try both.</P>
<P>Archives of the new lists are available via the<A href="http://www.freeswan.org/mail.html">
web interface</A>.</P>
<H2><A name="indexes">Indexes of mailing lists</A></H2>
<P><A href="http://paml.net/">PAML</A> is the standard reference for<STRONG>
P</STRONG>ublicly<STRONG> A</STRONG>ccessible<STRONG> M</STRONG>ailing<STRONG>
L</STRONG>ists. When we last checked, it had over 7500 lists on an
amazing variety of topics. It also has FAQ information and a search
engine.</P>
<P>There is an index of<A href="http://oslab.snu.ac.kr/~djshin/linux/mail-list/index.shtml">
Linux mailing lists</A> available.</P>
<P>A list of<A href="http://xforce.iss.net/maillists/otherlists.php">
computer security mailing lists</A>, with descriptions.</P>
<H2><A name="otherlists">Lists for related software and topics</A></H2>
<P>Most links in this section point to subscription addresses for the
various lists. Send the one-line message &quot;subscribe<VAR> list_name</VAR>
&quot; to subscribe to any of them.</P>
<H3><A NAME="28_3_1">Products that include FreeS/WAN</A></H3>
<P>Our introduction document gives a<A href="intro.html#products"> list
of products that include FreeS/WAN</A>. If you have, or are
considering, one of those, check the supplier's web site for
information on mailing lists for their users.</P>
<H3><A name="linux.lists">Linux mailing lists</A></H3>
<UL>
<LI><A href="mailto:majordomo@vger.kernel.org">
linux-admin@vger.kernel.org</A>, for Linux system administrators</LI>
<LI><A href="mailto:netfilter-request@lists.samba.org">
netfilter@lists.samba.org</A>, about Netfilter, which replaces IPchains
in kernels 2.3.15 and later</LI>
<LI><A href="mailto:security-audit-request@ferret.lmh.ox.ac.uk">
security-audit@ferret.lmh.ox.ac.uk</A>, for people working on security
audits of various Linux programs</LI>
<LI><A href="mailto:securedistros-request@humbolt.geo.uu.nl">
securedistros@humbolt.geo.uu.nl</A>, for discussion of issues common to
all the half dozen projects working on secure Linux distributions.</LI>
</UL>
<P>Each of the scure distribution projects also has its own web site and
mailing list. Some of the sites are:</P>
<UL>
<LI><A href="http://bastille-linux.org/">Bastille Linux</A> scripts to
harden Redhat, e.g. by changing permissions and modifying inialisation
scripts</LI>
<LI><A href="http://immunix.org/">Immunix</A> take a different approach,
using a modified compiler to build kernel and utilities with better
resistance to various types of overflow and exploit</LI>
<LI>the<A href="glossary.html#NSA"> NSA</A> have contractors working on
a<A href="glossary.html#SElinux"> Security Enhanced Linux</A>,
primarily adding stronger access control mechanisms. You can download
the current version (which interestingly is under GPL and not export
resrtricted) or subscribe to the mailing list from the<A href="http://www.nsa.gov/selinux">
project web page</A>.</LI>
</UL>
<H3><A name="ietf">Lists for IETF working groups</A></H3>
<P>Each<A href="glossary.html#IETF"> IETF</A> working group has an
associated mailing list where much of the work takes place.</P>
<UL>
<LI><A href="mailto:majordomo@lists.tislabs.com">ipsec@lists.tislabs.com</A>
, the IPsec<A href="http://www.ietf.org/html.charters/ipsec-charter.html">
working group</A>. This is where the protocols are discussed, new
drafts announced, and so on. By now, the IPsec working group is winding
down since the work is essentially complete. A<A href="http://www.sandelman.ottawa.on.ca/ipsec/">
list archive</A> is available.</LI>
<LI><A href="mailto:ipsec-policy-request@vpnc.org">IPsec policy</A>
list, and its<A href="http://www.vpnc.org/ipsec-policy/"> archive</A></LI>
<LI><A href="mailto:ietf-ipsra-request@vpnc.org">IP secure remote access</A>
list, and its<A href="http://www.vpnc.org/ietf-ipsra/mail-archive/">
archive</A></LI>
</UL>
<H3><A name="other">Other mailing lists</A></H3>
<UL>
<LI><A href="mailto:ipc-announce-request@privacy.org">
ipc-announce@privacy.org</A> a low-traffic list with announcements of
developments in privacy, encryption and online civil rights</LI>
<LI>a VPN mailing list's<A href="http://kubarb.phsx.ukans.edu/~tbird/vpn.html">
home page</A></LI>
</UL>
<H2><A name="newsgroups">Usenet newsgroups</A></H2>
<UL>
<LI>sci.crypt</LI>
<LI>sci.crypt.research</LI>
<LI>comp.dcom.vpn</LI>
<LI>talk.politics.crypto</LI>
</UL>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="ipsec.html">Previous</A>
<A HREF="web.html">Next</A>
</BODY>
</HTML>

523
doc/makecheck.html Normal file
View File

@ -0,0 +1,523 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<TITLE>Introduction to FreeS/WAN</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=iso-8859-1">
<STYLE TYPE="text/css"><!--
BODY { font-family: serif }
H1 { font-family: sans-serif }
H2 { font-family: sans-serif }
H3 { font-family: sans-serif }
H4 { font-family: sans-serif }
H5 { font-family: sans-serif }
H6 { font-family: sans-serif }
SUB { font-size: smaller }
SUP { font-size: smaller }
PRE { font-family: monospace }
--></STYLE>
</HEAD>
<BODY>
<A HREF="toc.html">Contents</A>
<A HREF="umltesting.html">Previous</A>
<A HREF="nightly.html">Next</A>
<HR>
<H1><A name="makecheck">How to configure to use &quot;make check&quot;</A></H1>
<H2><A NAME="38_1">What is &quot;make check&quot;</A></H2>
<P> &quot;make check&quot; is a target in the top level makefile. It takes care of
running a number of unit and system tests to confirm that FreeSWAN has
been compiled correctly, and that no new bugs have been introduced.</P>
<P> As FreeSWAN contains both kernel and userspace components, doing
testing of FreeSWAN requires that the kernel be simulated. This is
typically difficult to do as a kernel requires that it be run on bare
hardware. A technology has emerged that makes this simpler. This is<A HREF="http://user-mode-linux.sourceforge.net">
User Mode Linux</A>.</P>
<P> User-Mode Linux is a way to build a Linux kernel such that it can
run as a process under another Linux (or in the future other) kernel.
Presently, this can only be done for 2.4 guest kernels. The host kernel
can be 2.2 or 2.4.</P>
<P> &quot;make check&quot; expects to be able to build User-Mode Linux kernels
with FreeSWAN included. To do this it needs to have some files
downloaded and extracted prior to running &quot;make check&quot;. This is
described in the<A HREF="umltesting.html"> UML testing</A> document.</P>
<P> After having run the example in the UML testing document and
successfully brought up the four machine combination, you are ready to
use &quot;make check&quot;</P>
<H2><A NAME="38_2">Running &quot;make check&quot;</A></H2>
<P> &quot;make check&quot; works by walking the FreeSWAN source tree invoking the
&quot;check&quot; target at each node. At present there are tests defined only
for the <CODE>klips</CODE> directory. These tests will use the UML
infrastructure to test out pieces of the <CODE>klips</CODE> code.</P>
<P> The results of the tests can be recorded. If the environment
variable <CODE>$REGRESSRESULTS</CODE> is non-null, then the results of
each test will be recorded. This can be used as part of a nightly
regression testing system, see<A HREF="nightly.html"> Nightly testing</A>
for more details.</P>
<P> &quot;make check&quot; otherwise prints a minimal amount of output for each
test, and indicates pass/fail status of each test as they are run.
Failed tests do not cause failure of the target in the form of exit
codes.</P>
<H1><A NAME="39">How to write a &quot;make check&quot; test</A></H1>
<H2><A NAME="39_1">Structure of a test</A></H2>
<P> Each test consists of a set of directories under <CODE>testing/</CODE>
. There are directories for <CODE>klips</CODE>, <CODE>pluto</CODE>, <CODE>
packaging</CODE> and <CODE>libraries</CODE>. Each directory has a list
of tests to run is stored in a file called <CODE>TESTLIST</CODE> in
that directory. e.g. <CODE>testing/klips/TESTLIST</CODE>.</P>
<H2 NAME="TESTLIST"><A NAME="39_2">The TESTLIST</A></H2>
<P> This isn't actually a shell script. It just looks like one. Some
tools other than /bin/sh process it. Lines that start with # are
comments.</P>
<PRE>
# test-kind directory-containing-test expectation [PR#]
</PRE>
<P>The first word provides the test type, detailed below.</P>
<P> The second word is the name of the test to run. This the directory
in which the test case is to be found..</P>
<P>The third word may be one of:</P>
<DL>
<DT> blank/good</DT>
<DD>the test is believed to function, report failure</DD>
<DT> bad</DT>
<DD> the test is known to fail, report unexpected success</DD>
<DT> suspended</DT>
<DD> the test should not be run</DD>
</DL>
<P> The fourth word may be a number, which is a PR# if the test is
failing.</P>
<H2><A NAME="39_3">Test kinds</A></H2>
The test types are:
<DL>
<DT>skiptest</DT>
<DD>means run no test.</DD>
<DT>ctltest</DT>
<DD>means run a single system without input/output.</DD>
<DT>klipstest</DT>
<DD>means run a single system with input/output networks</DD>
<DT><A HREF="#umlplutotest">umlplutotest</A></DT>
<DD>means run a pair of systems</DD>
<DT><A HREF="#umlXhost">umlXhost</A></DT>
<DD>run an arbitrary number of systems</DD>
<DT>suntest (TBD)</DT>
<DD>means run a quad of east/west/sunrise/sunset</DD>
<DT>roadtest (TBD)</DT>
<DD>means run a trio of east-sunrise + warrior</DD>
<DT>extrudedtest (TBD)</DT>
<DD>means run a quad of east-sunrise + warriorsouth + park</DD>
<DT>mkinsttest</DT>
<DD>a test of the &quot;make install&quot; machinery.</DD>
<DT>kernel_test_patch</DT>
<DD>a test of the &quot;make kernelpatch&quot; machinery.</DD>
</DL>
Tests marked (TBD) have yet to be fully defined.
<P> Each test directory has a file in it called <CODE>testparams.sh</CODE>
. This file sets a number of environment variables to define the
parameters of the test.</P>
<H2><A NAME="39_4">Common parameters</A></H2>
<DL>
<DT>TESTNAME</DT>
<DD>the name of the test (repeated for checking purposes)</DD>
<DT>TEST_TYPE</DT>
<DD>the type of the test (repeat of type type above)</DD>
<DT>TESTHOST</DT>
<DD>the name of the UML machine to run for the test, typically &quot;east&quot; or
&quot;west&quot;</DD>
<DT>TEST_PURPOSE</DT>
<DD>The purpose of the test is one of:
<DL>
<DT>goal</DT>
<DD>The goal purpose is where a test is defined for code that is not yet
finished. The test indicates when the goals have in fact been reached.</DD>
<DT>regress</DT>
<DD>This is a test to determine that a previously existing bug has been
repaired. This test will initially be created to reproduce the bug in
isolation, and then the bug will be fixed.</DD>
<DT>exploit</DT>
<DD>This is a set of packets/programs that causes a vulnerability to be
exposed. It is a specific variation of the regress option.</DD>
</DL>
</DD>
<DT>TEST_GOAL_ITEM</DT>
<DT></DT>
<DD>in the case of a goal test, this is a reference to the requirements
document</DD>
<DT>TEST_PROB_REPORT</DT>
<DD>in the case of regression test, this the problem report number from
GNATS</DD>
<DT>TEST_EXPLOIT_URL</DT>
<DD>in the case of an exploit, this is a URL referencing the paper
explaining the origin of the test and the origin of exploit software</DD>
<DT>REF_CONSOLE_OUTPUT</DT>
<DD>a file in the test directory that contains the sanitized console
output against which to compare the output of the actual test.</DD>
<DT>REF_CONSOLE_FIXUPS</DT>
<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
to sanitize the console output of the machine under test. These are
typically perl, awk or sed scripts that remove things in the kernel
output that change each time the test is run and/or compiled.</DD>
<DT>INIT_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode prior to starting the tests. This file will usually
set up any eroute's and SADB entries that are required for the test.</P>
<P>Lines beginning with # are skipped. Blank lines are skipped.
Otherwise, a shell prompted is waited for each time (consisting of <CODE>
\n#</CODE>) and then the command is sent. Note that the prompt is waited
for before the command and not after, so completion of the last command
in the script is not required. This is often used to invoke a program
to monitor the system, e.g. <CODE>ipsec pf_key</CODE>.</P>
</DD>
<DT>RUN_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode, before the packets are sent. On single machine tests,
this script doesn't provide any more power than INIT_SCRIPT, but is
implemented for consistency's sake.</P>
</DD>
<DT>FINAL_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode after the final packet is sent. Similar to
INIT_SCRIPT, above. If not specified, then the single command &quot;halt&quot; is
sent. If specified, then the script should end with a halt command to
nicely shutdown the UML.</P>
</DD>
<DT>CONSOLEDIFFDEBUG</DT>
<DD>If set to &quot;true&quot; then the series of console fixups (see
REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
be set to &quot;false&quot;, or unset otherwise)</DD>
<DT>NETJIGDEBUG</DT>
<DD>If set to &quot;true&quot; then the series of console fixups (see
REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should
be set to &quot;false&quot;, or unset otherwise)</DD>
<DT>NETJIGTESTDEBUG</DT>
<DD> If set to &quot;netjig&quot;, then the results of talking to the <CODE>
uml_netjig</CODE> will be printed to stderr during the test. In
addition, the jig will be invoked with --debug, which causes it to log
its process ID, and wait 60 seconds before continuing. This can be used
if you are trying to debug the <CODE>uml_netjig</CODE> program itself.</DD>
<DT>HOSTTESTDEBUG</DT>
<DD> If set to &quot;hosttest&quot;, then the results of taling to the consoles of
the UMLs will be printed to stderr during the test.</DD>
<DT>NETJIGWAITUSER</DT>
<DD> If set to &quot;waituser&quot;, then the scripts will wait forever for user
input before they shut the tests down. Use this is if you are debugging
through the kernel.</DD>
<DT>PACKETRATE</DT>
<DD> A number, in miliseconds (default is 500ms) at which packets will
be replayed by the netjig.</DD>
</DL>
<H2><A NAME="39_5">KLIPStest paramaters</A></H2>
<P> The klipstest function starts a program (<CODE>
testing/utils/uml_netjig/uml_netjig</CODE>) to setup a bunch of I/O
sockets (that simulate network interfaces). It then exports the
references to these sockets to the environment and invokes (using
system()) a given script. It waits for the script to finish.</P>
<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
<P> The script invoked (<CODE>testing/utils/host-test.tcl</CODE>) is a
TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
to start the UML and configure it appropriately for the test. The
configuration is done with the script given above for<VAR> INIT_SCRIPT</VAR>
. The TCL script then forks, leaves the UML in the background and exits.
uml_netjig continues. It then starts listening to the simulated network
answering ARPs and inserting packets as appropriate.</P>
<P> The klipstest function invokes <CODE>uml_netjig</CODE> with
arguments to capture output from network interface(s) and insert
packets as appropriate:</P>
<DL>
<DT>PUB_INPUT</DT>
<DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
public (encrypted) interface. (typically, eth1)</DD>
<DT>PRIV_INPUT</DT>
<DD>a pcap file to feed in on the private (plain-text) interface
(typically, eth0).</DD>
<DT>REF_PUB_OUTPUT</DT>
<DD>a text file containing tcpdump output. Packets on the public (eth1)
interface are captured to a<A HREF="http://www.tcpdump.org/"> pcap</A>
file by <CODE>uml_netjig</CODE>. The klipstest function then uses
tcpdump on the file to produce text output, which is compared to the
file given.</DD>
<DT>REF_PUB_FILTER</DT>
<DD>a program that will filter the TCPDUMP output to do further
processing. Defaults to &quot;cat&quot;.</DD>
<DT>REF_PRIV_OUTPUT</DT>
<DD>a text file containing tcpdump output. Packets on the private (eth0)
interface are captured and compared after conversion by tcpdump, as
with<VAR> REFPUBOUTPUT</VAR>.</DD>
<DT>REF_PRIV_FILTER</DT>
<DD>a program that will filter the TCPDUMP output to do further
processing. Defaults to &quot;cat&quot;.</DD>
<DT>EXITONEMPTY</DT>
<DD>a flag for <CODE>uml_netjig</CODE>. It should contain
&quot;--exitonempty&quot; of uml_netjig should exit when all of the input (<VAR>
PUBINPUT</VAR>,<VAR>PRIVINPUT</VAR>) packets have been injected.</DD>
<DT>ARPREPLY</DT>
<DD>a flag for <CODE>uml_netjig</CODE>. It should contain &quot;--arpreply&quot;
if <CODE>uml_netjig</CODE> should reply to ARP requests. One will
typically set this to avoid having to fudge the ARP cache manually.</DD>
<DT>TCPDUMPFLAGS</DT>
<DD>a set of flags for the tcpdump used when converting captured output.
Typical values will include &quot;-n&quot; to turn off DNS, and often &quot;-E&quot; to set
the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
&quot;-t&quot; flag (turn off timestamps) is provided automatically</DD>
<DT>NETJIG_EXTRA</DT>
<DD>additional comments to be sent to the netjig. This may arrange to
record or create additional networks, or may toggle options.</DD>
</DL>
<H2><A NAME="39_6">mkinsttest paramaters</A></H2>
<P> The basic concept of the <CODE>mkinsttest</CODE> test type is that
it performs a &quot;make install&quot; to a temporary $DESTDIR. The resulting
tree can then be examined to determine if it was done properly. The
files can be uninstalled to determine if the file list was correct, or
the contents of files can be examined more precisely.</P>
<DL>
<DT>INSTALL_FLAGS</DT>
<DD>If set, then an install will be done. This provides the set of flags
to provide for the install. The target to be used (usually &quot;install&quot;)
must be among the flags.</DD>
<DT>POSTINSTALL_SCRIPT</DT>
<DD>If set, a script to run after initial &quot;make install&quot;. Two arguments
are provided: an absolute path to the root of the FreeSWAN src tree,
and an absolute path to the temporary installation area.</DD>
<DT>INSTALL2_FLAGS</DT>
<DD>If set, a second install will be done using these flags. Similarly
to INSTALL_FLAGS, the target must be among the flags.</DD>
<DT>UNINSTALL_FLAGS</DT>
<DD>If set, an uninstall will be done using these flags. Similarly to
INSTALL_FLAGS, the target (usually &quot;uninstall&quot;) must be among the
flags.</DD>
<DT>REF_FIND_f_l_OUTPUT</DT>
<DD>If set, a <CODE>find $ROOT ( -type f -or -type -l )</CODE> will be
done to get a list of a real files and symlinks. The resulting file
will be compared to the file listed by this option.</DD>
<DT>REF_FILE_CONTENTS</DT>
<DD>If set, it should point to a file containing records for the form:
<PRE>
<!--VARIABLE-->
reffile</(null)>
<!--VARIABLE-->
samplefile</(null)>
</PRE>
one record per line. A diff between the provided reference file, and
the sample file (located in the temporary installation root) will be
done for each record.</DD>
</DL>
<H2><A NAME="39_7">rpm_build_install_test paramaters</A></H2>
<P> The <CODE>rpm_build_install_test</CODE> type is to verify that the
proper packing list is produced by &quot;make rpm&quot;, and that the mechanisms
for building the kernel modules produce consistent results.</P>
<DL>
<DT>RPM_KERNEL_SOURCE</DT>
<DD>Point to an extracted copy of the RedHat kernel source code.
Variables from the environment may be used.</DD>
<DT>REF_RPM_CONTENTS</DT>
<DD>This is a file containing one record per line. Each record consists
of a RPM name (may contain wildcards) and a filename to compare the
contents to. The RPM will be located and a file list will be produced
with rpm2cpio.</DD>
</DL>
<H2><A NAME="39_8">libtest paramaters</A></H2>
<P> The libtest test is for testing library routines. The library file
is expected to provided an <CODE>#ifdef</CODE> by the name of<VAR>
library</VAR>
<!--CODE_MAIN</CODE-->
. The libtest type invokes the C compiler to compile this
file, links it against <CODE>libfreeswan.a</CODE> (to resolve any other
dependancies) and runs the test with the <CODE>-r</CODE> argument to
invoke a regression test.</(null)></P>
<P>The library test case is expected to do a self-test, exiting with
status code 0 if everything is okay, and with non-zero otherwise. A
core dump (exit code greater than 128) is noted specifically.</P>
<P> Unlike other tests, there are no subdirectories required, or other
parameters to set.</P>
<H2 NAME="umlplutotest"><A NAME="39_9">umlplutotest paramaters</A></H2>
<P> The umlplutotest function starts a pair of user mode line processes.
This is a 2-host version of umlXhost. The &quot;EAST&quot; and &quot;WEST&quot; slots are
defined.</P>
<H2 NAME="umlXhost"><A NAME="39_10">umlXhost parameters</A></H2>
<P> The umlXtest function starts an arbitrary number of user mode line
processes.</P>
<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> -->
<P> The script invoked (<CODE>testing/utils/Xhost-test.tcl</CODE>) is a
TCL<A HREF="http://expect.nist.gov/"> expect</A> script that arranges
to start each UML and configure it appropriately for the test. It then
starts listening (using uml_netjig) to the simulated network answering
ARPs and inserting packets as appropriate.</P>
<P> umlXtest has a series of slots, each of which should be filled by a
host. The list of slots is controlled by the variable, XHOST_LIST. This
variable should be set to a space seperated list of slots. The former
umlplutotest is now implemented as a variation of the umlXhost test,
with XHOST_LIST=&quot;EAST WEST&quot;.</P>
<P> For each host slot that is defined, a series of variables should be
filled in, defining what configuration scripts to use for that host.</P>
<P> The following are used to control the console input and output to
the system. Where the string ${host} is present, the host slot should
be filled in. I.e. for the two host system with XHOST_LIST=&quot;EAST WEST&quot;,
then the variables: EAST_INIT_SCRIPT and WEST_INIT_SCRIPT will exist.</P>
<DL>
<DT>${host}HOST</DT>
<DD>The name of the UML host which will fill this slot</DD>
<DT>${host}_INIT_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode prior to starting the tests. This file will usually
set up any eroute's and SADB entries that are required for the test.
Similar to INIT_SCRIPT, above.</P>
</DD>
<DT>${host}_RUN_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode, before the packets are sent. This set of commands is
run after all of the virtual machines are initialized. I.e. after
EAST_INIT_SCRIPT<B> AND</B> WEST_INIT_SCRIPT. This script can therefore
do things that require that all machines are properly configured.</P>
</DD>
<DT>${host}_RUN2_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode, after the packets are sent. This set of commands is
run before any of the virtual machines have been shut down. (I.e.
before EAST_FINAL_SCRIPT<B> AND</B> WEST_FINAL_SCRIPT.) This script can
therefore catch post-activity status reports.</P>
</DD>
<DT>${host}_FINAL_SCRIPT</DT>
<DD>
<P>a file of commands that is fed into the virtual machine's console in
single user mode after the final packet is sent. Similar to
INIT_SCRIPT, above. If not specified, then the single command &quot;halt&quot; is
sent. Note that when this script is run, the other virtual machines may
already have been killed. If specified, then the script should end with
a halt command to nicely shutdown the UML.</P>
</DD>
<DT>REF_${host}_CONSOLE_OUTPUT</DT>
<DD>Similar to REF_CONSOLE_OUTPUT, above.</DD>
</DL>
<P>Some additional flags apply to all hosts:</P>
<DL>
<DT>REF_CONSOLE_FIXUPS</DT>
<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to apply
to sanitize the console output of the machine under test. These are
typically perl, awk or sed scripts that remove things in the kernel
output that change each time the test is run and/or compiled.</DD>
</DL>
<P> In addition to input to the console, the networks may have input fed
to them:</P>
<DL>
<DT>EAST_INPUT/WEST_INPUT</DT>
<DD>a<A HREF="http://www.tcpdump.org/"> pcap</A> file to feed in on the
private network side of each network. The &quot;EAST&quot; and &quot;WEST&quot; here refer
to the networks, not the hosts.</DD>
<DT>REF_PUB_FILTER</DT>
<DD>a program that will filter the TCPDUMP output to do further
processing. Defaults to &quot;cat&quot;.</DD>
<DT>REF_EAST_FILTER/REF_WEST_FILTER</DT>
<DD>a program that will filter the TCPDUMP output to do further
processing. Defaults to &quot;cat&quot;.</DD>
&lt;
<DT>TCPDUMPFLAGS</DT>
<DD>a set of flags for the tcpdump used when converting captured output.
Typical values will include &quot;-n&quot; to turn off DNS, and often &quot;-E&quot; to set
the decryption key (tcpdump 3.7.1 and higher only) for ESP packets. The
&quot;-t&quot; flag (turn off timestamps) is provided automatically</DD>
<DT>REF_EAST_OUTPUT/REF_WEST_OUTPUT</DT>
<DD>a text file containing tcpdump output. Packets on the private (eth0)
interface are captured and compared after conversion by tcpdump, as
with<VAR> REF_PUB_OUTPUT</VAR>.</DD>
<P> There are two additional environment variables that may be set on
the command line:</P>
<DL>
<DT> NETJIGVERBOSE=verbose export NETJIGVERBOSE</DT>
<DD> If set, then the test output will be &quot;chatty&quot;, and let you know
what commands it is running, and as packets are sent. Without it set,
the output is limited to success/failure messages.</DD>
<DT> NETJIGTESTDEBUG=netjig export NETJIGTESTDEBUG</DT>
<DD> This will enable debugging of the communication with uml_netjig,
and turn on debugging in this utility. This does not imply
NETJIGVERBOSE.</DD>
</DL>
<DT> HOSTTESTDEBUG=hosttest export HOSTTESTDEBUG</DT>
<DD> This will show all interactions with the user-mode-linux consoles</DD>
</DL>
<H2 NAME="kernelpatch"><A NAME="39_11">kernel_patch_test paramaters</A></H2>
<P> The kernel_patch_test function takes some kernel source, copies it
with lndir, and then applies the patch as produced by &quot;make
kernelpatch&quot;.</P>
<P> The following are used to control the input and output to the
system:</P>
<DL>
<DT>KERNEL_NAME</DT>
<DD>the kernel name, typically something like &quot;linus&quot; or &quot;rh&quot;</DD>
<DT>KERNEL_VERSION</DT>
<DD>the kernel version number, as in &quot;2.2&quot; or &quot;2.4&quot;.</DD>
<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
<DD>This variable should set in the environment, probably in
~/freeswan-regress-env.sh. Examples of this variables would be
KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
an extracted copy of the kernel source in question.</DD>
<DT>REF_PATCH_OUTPUT</DT>
<DD>a copy of the patch output to compare against</DD>
<DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
<DD>If set to a non-empty string, then the patched kernel source is not
removed at the end of the test. This will typically be set in the
environment while debugging.</DD>
</DL>
<H2 NAME="modtest"><A NAME="39_12">module_compile paramaters</A></H2>
<P> The module_compile test attempts to build the KLIPS module against a
given set of kernel source. This is also done by the RPM tests, but in
a very specific manner.</P>
<P> There are two variations of this test - one where the kernel either
doesn't need to be configured, or is already done, and tests were there
is a local configuration file.</P>
<P> Where the kernel doesn't need to be configured, the kernel source
that is found is simply used. It may be a RedHat-style kernel, where
one can cause it to configure itself via rhconfig.h-style definitions.
Or, it may just be a kernel tree that has been configured.</P>
<P> If the variable KERNEL_CONFIG_FILE is set, then a new directory is
created for the kernel source. It is populated with lndir(1). The
referenced file is then copied in as .config, and &quot;make oldconfig&quot; is
used to configure the kernel. This resulting kernel is then used as the
reference source.</P>
<P> In all cases, the kernel source is found the same was for the
kernelpatch test, i.e. via KERNEL_VERSION/KERNEL_NAME and
KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC.</P>
<P> Once there is kernel source, the module is compiled using the
top-level &quot;make module&quot; target.</P>
<P> The test is considered successful if an executable is found in
OUTPUT/module/ipsec.o at the end of the test.</P>
<DL>
<DT>KERNEL_NAME</DT>
<DD>the kernel name, typically something like &quot;linus&quot; or &quot;rh&quot;</DD>
<DT>KERNEL_VERSION</DT>
<DD>the kernel version number, as in &quot;2.2&quot; or &quot;2.4&quot;.</DD>
<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT>
<DD>This variable should set in the environment, probably in
~/freeswan-regress-env.sh. Examples of this variables would be
KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point to
an extracted copy of the kernel source in question.</DD>
<DT>KERNEL_CONFIG_FILE</DT>
<DD>The configuration file for the kernel.</DD>
<DT>KERNEL_PATCH_LEAVE_SOURCE</DT>
<DD>If set to a non-empty string, then the configured kernel source is
not removed at the end of the test. This will typically be set in the
environment while debugging.</DD>
<DT>MODULE_DEF_INCLUDE</DT>
<DD>The include file that will be used to configure the KLIPS module,
and possibly the kernel source.</DD>
</DL>
<H1><A NAME="40">Current pitfalls</A></H1>
<DL>
<DT> &quot;tcpdump dissector&quot; not available.</DT>
<DD> This is a non-fatal warning. If uml_netjig is invoked with the -t
option, then it will attempt to use tcpdump's dissector to decode each
packet that it processes. The dissector is presently not available, so
this option it normally turned off at compile time. The dissector
library will be released with tcpdump version 4.0.</DD>
</DL>
<HR>
<A HREF="toc.html">Contents</A>
<A HREF="umltesting.html">Previous</A>
<A HREF="nightly.html">Next</A>
</BODY>
</HTML>

215
doc/manpage.d/ipsec.8.html Normal file
View File

@ -0,0 +1,215 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC</TITLE>
</HEAD><BODY>
<H1>IPSEC</H1>
Section: Maintenance Commands (8)<BR>Updated: 26 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec - invoke IPsec utilities
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
command [ argument ...]
<P>
<B>ipsec</B>
<B>--help</B>
<BR>
<B>ipsec</B>
<B>--version</B>
<BR>
<B>ipsec</B>
<B>--versioncode</B>
<BR>
<B>ipsec</B>
<B>--copyright</B>
<BR>
<B>ipsec</B>
<B>--directory</B>
<BR>
<B>ipsec</B>
<B>--confdir</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Ipsec</I>
invokes any of several utilities involved in controlling the IPsec
encryption/authentication system,
running the specified
<I>command</I>
with the specified
<I>argument</I>s
as if it had been invoked directly.
This largely eliminates possible name collisions with other software,
and also permits some centralized services.
<P>
In particular,
<I>ipsec</I>
supplies the invoked
<I>command</I>
with a suitable PATH environment variable,
and also provides IPSEC_DIR,
IPSEC_CONFS, and IPSEC_VERSION environment variables,
containing respectively
the full pathname of the directory where the IPsec utilities are stored,
the full pathname of the directory where the configuration files live,
and the IPsec version number.
<P>
<B>ipsec --help</B>
lists the available commands.
Most have their own manual pages, e.g.
<I><A HREF="ipsec_auto.8.html">ipsec_auto</A></I>(8)
for
<I>auto</I>.
<P>
<B>ipsec --version</B>
outputs version information about Linux FreeS/WAN.
A version code of the form ``U<I>xxx</I>/K<I>yyy</I>''
indicates that the user-level utilities are version <I>xxx</I>
but the kernel portion appears to be version <I>yyy</I>
(this form is used only if the two disagree).
<P>
<B>ipsec --versioncode</B>
outputs <I>just</I> the version code,
with none of
<B>--version</B>'s
supporting information,
for use by scripts.
<P>
<B>ipsec --copyright</B>
supplies boring copyright details.
<P>
<B>ipsec --directory</B>
reports where
<I>ipsec</I>
thinks the IPsec utilities are stored.
<P>
<B>ipsec --confdir</B>
reports where
<I>ipsec</I>
thinks the IPsec configuration files are stored.
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
/usr/local/lib/ipsec<TT>&nbsp;&nbsp;&nbsp;</TT>usual utilities directory<BR>
<A NAME="lbAF">&nbsp;</A>
<H2>ENVIRONMENT</H2>
<P>
The following environment variables control where FreeS/WAN finds its
components.
The
<B>ipsec</B>
command sets them if they are not already set.
<PRE>
IPSEC_EXECDIR directory containing published commands
IPSEC_LIBDIR directory containing internal executables
IPSEC_SBINDIR directory containing <B>ipsec</B> command
IPSEC_CONFS directory containing configuration files
</PRE>
<A NAME="lbAG">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.conf.5.html">ipsec.conf</A>(5), <A HREF="ipsec.secrets.5.html">ipsec.secrets</A>(5),
<A HREF="ipsec_auto.8.html">ipsec_auto</A>(8),
<A HREF="ipsec_barf.8.html">ipsec_barf</A>(8),
<A HREF="ipsec_setup.8.html">ipsec_setup</A>(8),
<A HREF="ipsec_showdefaults.8.html">ipsec_showdefaults</A>(8),
<A HREF="ipsec_showhostkey.8.html">ipsec_showhostkey</A>(8)
<P>
HTML documentation shipped with the release, starting with
<I>doc/index.html</I>.
<I>&lt;<A HREF="http://www.freeswan.org/doc.html">http://www.freeswan.org/doc.html</A>&gt;</I>
may also be of use.
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for Linux FreeS/WAN
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Henry Spencer.
<A NAME="lbAI">&nbsp;</A>
<H2>BUGS</H2>
The provision of centralized services,
while convenient,
does compromise the original concept of making the utilities
invocable directly as well as via
<I>ipsec</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">ENVIRONMENT</A><DD>
<DT><A HREF="#lbAG">SEE ALSO</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
<DT><A HREF="#lbAI">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

1830
doc/manpage.d/ipsec.conf.5.html Normal file
View File

File diff suppressed because it is too large Load Diff

227
doc/manpage.d/ipsec.secrets.5.html Normal file
View File

@ -0,0 +1,227 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC.SECRETS</TITLE>
</HEAD><BODY>
<H1>IPSEC.SECRETS</H1>
Section: File Formats (5)<BR>Updated: 28 March 1999<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec.secrets - secrets for IKE/IPsec authentication
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
The file <I>ipsec.secrets</I> holds a table of secrets.
These secrets are used by <I><A HREF="ipsec_pluto.8.html">ipsec_pluto</A></I>(8), the FreeS/WAN Internet Key
Exchange daemon, to authenticate other hosts.
Currently there are two kinds of secrets: preshared secrets and
RSA private keys.
<P>
It is vital that these secrets be protected. The file should be owned
by the super-user,
and its permissions should be set to block all access by others.
<P>
The file is a sequence of entries and include directives.
Here is an example. Each entry or directive must start at the
left margin, but if it continues beyond a single line, each continuation
line must be indented.
<P>
<DL COMPACT><DT><DD>
<PRE>
# sample /etc/ipsec.secrets file for 10.1.0.1
10.1.0.1 10.2.0.1: PSK &quot;secret shared by two hosts&quot;
# an entry may be split across lines,
# but indentation matters
<A HREF="http://www.xs4all.nl">www.xs4all.nl</A> @<A HREF="http://www.kremvax.ru">www.kremvax.ru</A>
&nbsp;&nbsp;&nbsp;&nbsp;10.6.0.1 10.7.0.1 1.8.0.1: PSK &quot;secret shared by 5&quot;
# an RSA private key.
# note that the lines are too wide for a
# man page, so ... has been substituted for
# the truncated part
@my.com: rsa {
&nbsp;&nbsp;&nbsp;&nbsp;Modulus:&nbsp;0syXpo/6waam+ZhSs8Lt6jnBzu3C4grtt...
&nbsp;&nbsp;&nbsp;&nbsp;PublicExponent:&nbsp;0sAw==
&nbsp;&nbsp;&nbsp;&nbsp;PrivateExponent:&nbsp;0shlGbVR1m8Z+7rhzSyenCaBN...
&nbsp;&nbsp;&nbsp;&nbsp;Prime1:&nbsp;0s8njV7WTxzVzRz7AP+0OraDxmEAt1BL5l...
&nbsp;&nbsp;&nbsp;&nbsp;Prime2:&nbsp;0s1LgR7/oUMo9BvfU8yRFNos1s211KX5K0...
&nbsp;&nbsp;&nbsp;&nbsp;Exponent1:&nbsp;0soaXj85ihM5M2inVf/NfHmtLutVz4r...
&nbsp;&nbsp;&nbsp;&nbsp;Exponent2:&nbsp;0sjdAL9VFizF+BKU4ohguJFzOd55OG6...
&nbsp;&nbsp;&nbsp;&nbsp;Coefficient:&nbsp;0sK1LWwgnNrNFGZsS/2GuMBg9nYVZ...
&nbsp;&nbsp;&nbsp;&nbsp;}
include ipsec.*.secrets # get secrets from other files
</PRE>
</DL>
<P>
Each entry in the file is a list of indices, followed by a secret.
The two parts are separated by a colon (<B>:</B>) that is
followed by whitespace or a newline. For compatability
with the previous form of this file, if the key part is just a
double-quoted string the colon may be left out.
<P>
An index is an IP address, or a Fully Qualified Domain Name, <A HREF="mailto:user@FQDN">user@FQDN</A>,
<B>%any</B> or <B>%any6</B> (other kinds may come). An IP address may be written
in the familiar dotted quad form or as a domain name to be looked up
when the file is loaded
(or in any of the forms supported by the FreeS/WAN <I><A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A></I>(3)
routine). In many cases it is a bad idea to use domain names because
the name server may not be running or may be insecure. To denote a
Fully Qualified Domain Name (as opposed to an IP address denoted by
its domain name), precede the name with an at sign (<B>@</B>).
<P>
Matching IDs with indices is fairly straightforward: they have to be
equal. In the case of a ``Road Warrior'' connection, if an equal
match is not found for the Peer's ID, and it is in the form of an IP
address, an index of <B>%any</B> will match the peer's IP address if IPV4
and <B>%any6</B> will match a the peer's IP address if IPV6.
Currently, the obsolete notation <B>0.0.0.0</B> may be used in place of
<B>%any</B>.
<P>
An additional complexity
arises in the case of authentication by preshared secret: the
responder will need to look up the secret before the Peer's ID payload has
been decoded, so the ID used will be the IP address.
<P>
To authenticate a connection between two hosts, the entry that most
specifically matches the host and peer IDs is used. An entry with no
index will match any host and peer. More specifically, an entry with one index will
match a host and peer if the index matches the host's ID (the peer isn't
considered). Still more specifically, an entry with multiple indices will match a host and
peer if the host ID and peer ID each match one of the indices. If the key
is for an asymmetric authentication technique (i.e. a public key
system such as RSA), an entry with multiple indices will match a host
and peer even if only the host ID matches an index (it is presumed that the
multiple indices are all identities of the host).
It is acceptable for two entries to be the best match as
long as they agree about the secret or private key.
<P>
Authentication by preshared secret requires that both systems find the
identical secret (the secret is not actually transmitted by the IKE
protocol). If both the host and peer appear in the index list, the
same entry will be suitable for both systems so verbatim copying
between systems can be used. This naturally extends to larger groups
sharing the same secret. Thus multiple-index entries are best for PSK
authentication.
<P>
Authentication by RSA Signatures requires that each host have its own private
key. A host could reasonably use a different private keys
for different interfaces and for different peers. But it would not
be normal to share entries between systems. Thus thus no-index and
one-index forms of entry often make sense for RSA Signature authentication.
<P>
The key part of an entry may start with a token indicating the kind of
key. ``RSA'' signifies RSA private key and ``PSK'' signifies
PreShared Key (case is ignored). For compatability with previous
forms of this file, PSK is the default.
<P>
A preshared secret is most conveniently represented as a sequence of
characters, delimited by the double-quote
character (<B>&quot;</B>). The sequence cannot contain a newline or
double-quote. Strictly speaking, the secret is actually the sequence
of bytes that is used in the file to represent the sequence of
characters (excluding the delimiters).
A preshared secret may also be represented, without quotes, in any form supported by
<I><A HREF="ipsec_ttodata.3.html">ipsec_ttodata</A></I>(3).
<P>
An RSA private key is a composite of eight generally large numbers. The notation
used is a brace-enclosed list of field name and value pairs (see the example above).
A suitable key, in a suitable format, may be generated by <I><A HREF="ipsec_rsasigkey.8.html">ipsec_rsasigkey</A></I>(8).
The structure is very similar to that used by BIND 8.2.2 or later, but note that
the numbers must have a ``0s'' prefix if they are in base 64. The order of
the fields is fixed.
<P>
The first token an entry must start in
the first column of its line. Subsequent tokens must be
separated by whitespace,
except for a colon token, which only needs to be followed by whitespace.
A newline is taken as whitespace, but every
line of an entry after the first must be indented.
<P>
Whitespace at the end of a line is ignored (except in the 0t
notation for a key). At the start of line or
after whitespace, <B>#</B> and the following text up to the end of the
line is treated as a comment. Within entries, all lines must be
indented (except for lines with no tokens).
Outside entries, no line may be indented (this is to make sure that
the file layout reflects its structure).
<P>
An include directive causes the contents of the named file to be processed
before continuing with the current file. The filename is subject to
``globbing'' as in <I><A HREF="sh.1.html">sh</A></I>(1), so every file with a matching name
is processed. Includes may be nested to a modest
depth (10, currently). If the filename doesn't start with a <B>/</B>, the
directory containing the current file is prepended to the name. The
include directive is a line that starts with the word <B>include</B>,
followed by whitespace, followed by the filename (which must not contain
whitespace).
<A NAME="lbAD">&nbsp;</A>
<H2>FILES</H2>
/etc/ipsec.secrets
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
The rest of the FreeS/WAN distribution, in particular
<I><A HREF="ipsec.conf.5.html">ipsec.conf</A></I>(5),
<I><A HREF="ipsec.8.html">ipsec</A></I>(8),
<I><A HREF="ipsec_newhostkey.8.html">ipsec_newhostkey</A></I>(8),
<I><A HREF="ipsec_rsasigkey.8.html">ipsec_rsasigkey</A></I>(8),
<I><A HREF="ipsec_showhostkey.8.html">ipsec_showhostkey</A></I>(8),
<I><A HREF="ipsec_auto.8.html">ipsec_auto</A></I>(8) <B>--rereadsecrets</B>,
and <I><A HREF="ipsec_pluto.8.html">ipsec_pluto</A></I>(8) <B>--listen</B>,.
<BR>
BIND 8.2.2 or later, <A HREF="ftp://ftp.isc.org/isc/bind/src/">ftp://ftp.isc.org/isc/bind/src/</A>
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Designed for the FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by D. Hugh Redelmeier.
<A NAME="lbAG">&nbsp;</A>
<H2>BUGS</H2>
If an ID is <B>0.0.0.0</B>, it will match <B>%any</B>;
if it is <B>0::0</B>, it will match <B>%any6</B>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">FILES</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
<DT><A HREF="#lbAG">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

58
doc/manpage.d/ipsec__confread.8.html Normal file
View File

@ -0,0 +1,58 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _CONFREAD</TITLE>
</HEAD><BODY>
<H1>_CONFREAD</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _confread - internal routing to parse config file
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_confread </I>
is an internal script used for parsing /etc/ipsec.conf into a canonical format.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_conf.8.html">ipsec_conf</A>(8)
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

62
doc/manpage.d/ipsec__copyright.8.html Normal file
View File

@ -0,0 +1,62 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _COPYRIGHT</TITLE>
</HEAD><BODY>
<H1>_COPYRIGHT</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _copyright - prints FreeSWAN copyright
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_copyright</I>
outputs the FreeSWAN copyright, and version numbers for &quot;ipsec --copyright&quot;
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8)
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

67
doc/manpage.d/ipsec__include.8.html Normal file
View File

@ -0,0 +1,67 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _INCLUDE</TITLE>
</HEAD><BODY>
<H1>_INCLUDE</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _include - internal script to process config files
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_include</I>
is used by
<I>_confread </I>
to process
<B>include </B>
directives in /etc/ipsec.conf.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec__confread.8.html">ipsec__confread</A>(8)
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

64
doc/manpage.d/ipsec__keycensor.8.html Normal file
View File

@ -0,0 +1,64 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _KEYCENSOR</TITLE>
</HEAD><BODY>
<H1>_KEYCENSOR</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _keycensor - internal routine to remove sensitive information
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_keycensor</I>
is used by
<B>ipsec barf</B>
to process the /etc/ipsec.secrets file, removing private key info.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_barf.8.html">ipsec_barf</A>(8)
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

64
doc/manpage.d/ipsec__plutoload.8.html Normal file
View File

@ -0,0 +1,64 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _PLUTOLOAD</TITLE>
</HEAD><BODY>
<H1>_PLUTOLOAD</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _plutoload - internal script to start pluto
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_plutoload</I>
is called by
<B>_plutorun</B>
to actually start the pluto executable.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_setup.8.html">ipsec_setup</A>(8), <A HREF="ipsec__realsetup.8.html">ipsec__realsetup</A>(8), <A HREF="ipsec__plutorun.8.html">ipsec__plutorun</A>(8)
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

70
doc/manpage.d/ipsec__plutorun.8.html Normal file
View File

@ -0,0 +1,70 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _PLUTORUN</TITLE>
</HEAD><BODY>
<H1>_PLUTORUN</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _plutorun - internal script to start pluto
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_plutorun</I>
is called by
<B>_realsetup</B>
to configure and bring up
<B><A HREF="ipsec_pluto.8.html">ipsec_pluto</A>(8).</B>
It calls
<B>_plutoload</B>
to invoke pluto, and watches to makes sure that pluto is restarted if it fails.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_setup.8.html">ipsec_setup</A>(8), <A HREF="ipsec__realsetup.8.html">ipsec__realsetup</A>(8), <A HREF="ipsec__plutoload.8.html">ipsec__plutoload</A>(8), <A HREF="ipsec_pluto.8.html">ipsec_pluto</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

68
doc/manpage.d/ipsec__realsetup.8.html Normal file
View File

@ -0,0 +1,68 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _REALSETUP</TITLE>
</HEAD><BODY>
<H1>_REALSETUP</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _realsetup - internal routine to start FreeS/WAN.
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_realsetup</I>
is called by the system init scripts to start the FreeS/WAN
system. It starts
<B>KLIPS </B>
(the kernel component) and
<B>pluto </B>
(the userspace keying component).
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec__klipsstart.8.html">ipsec__klipsstart</A>(8), <A HREF="ipsec__plutorun.8.html">ipsec__plutorun</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

65
doc/manpage.d/ipsec__secretcensor.8.html Normal file
View File

@ -0,0 +1,65 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _SECRETCENSOR</TITLE>
</HEAD><BODY>
<H1>_SECRETCENSOR</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _secretcensor - internal routing to sanitize files
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_secretcensor</I>
is called by
<B>ipsec barf</B>
to process the /etc/ipsec.secrets file to remove the private key components
from the file prior to revealing the contents.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_barf.8.html">ipsec_barf</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

63
doc/manpage.d/ipsec__startklips.8.html Normal file
View File

@ -0,0 +1,63 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _STARTKLIPS</TITLE>
</HEAD><BODY>
<H1>_STARTKLIPS</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _startklips - internal script to bring up kernel components
<A NAME="lbAC">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>_startklips</I>
brings up the FreeS/WAN kernel component. This involves loading any
required modules, attaching and configuring the ipsecX pseudo-devices and
attaching the pseudo-devices to the physical devices.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_tncfg.8.html">ipsec_tncfg</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">DESCRIPTION</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

63
doc/manpage.d/ipsec__updown.8.html Normal file
View File

@ -0,0 +1,63 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of _UPDOWN</TITLE>
</HEAD><BODY>
<H1>_UPDOWN</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec _updown - klips manipulation script
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<I>_updown</I>
is invoked by pluto when it has brought up a new connection. This script
is used to insert the appropriate routing entries for IPsec operation.
The interface to the script is documented in the pluto man page.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_pluto.8.html">ipsec_pluto</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

232
doc/manpage.d/ipsec_addrbytesof.3.html Normal file
View File

@ -0,0 +1,232 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initaddr - initialize an ip_address
<BR>
ipsec addrtypeof - get address type of an ip_address
<BR>
ipsec addrlenof - get length of address within an ip_address
<BR>
ipsec addrbytesof - get copy of address within an ip_address
<BR>
ipsec addrbytesptr - get pointer to address within an ip_address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *dst);</B>
<BR>
<B>int addrtypeof(const ip_address *src);</B>
<BR>
<B>size_t addrlenof(const ip_address *src);</B>
<BR>
<B>size_t addrbytesof(const ip_address *src,</B>
<BR>
&nbsp;
<B>unsigned char *dst, size_t dstlen);</B>
<BR>
<B>size_t addrbytesptr(const ip_address *src,</B>
<BR>
&nbsp;
<B>const unsigned char **dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_address</I>
to contain one of the (currently two) types of IP address.
These functions provide basic tools for creating and examining this type.
<P>
<I>Initaddr</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_address</I>
from an address
(in network byte order,
indicated by a pointer
<I>src</I>
and a length
<I>srclen</I>)
and an address family
<I>af</I>
(typically
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The length must be consistent with the address family.
<P>
<I>Addrtypeof</I>
returns the address type of an address,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Addrlenof</I>
returns the size (in bytes) of the address within an
<I>ip_address</I>,
to permit storage allocation etc.
<P>
<I>Addrbytesof</I>
copies the address within the
<I>ip_address</I>
<I>src</I>
to the buffer indicated by the pointer
<I>dst</I>
and the length
<I>dstlen</I>,
and returns the address length (in bytes).
If the address will not fit,
as many bytes as will fit are copied;
the returned length is still the full length.
It is the caller's responsibility to check the
returned value to ensure that there was enough room.
<P>
<I>Addrbytesptr</I>
sets
<I>*dst</I>
to a pointer to the internal address within the
<I>ip_address</I>,
and returns the address length (in bytes).
If
<I>dst</I>
is
<B>NULL</B>,
it just returns the address length.
The pointer points to
<B>const</B>
to discourage misuse.
<P>
<I>Initaddr</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
The functions which return
<I>size_t</I>
return
<B>0</B>
for a failure.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
An unknown address family is a fatal error for any of these functions
except
<I>addrtypeof</I>.
An address-size mismatch is a fatal error for
<I>initaddr</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Addrtypeof</I>
should probably have been named
<I>addrfamilyof</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

232
doc/manpage.d/ipsec_addrbytesptr.3.html Normal file
View File

@ -0,0 +1,232 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initaddr - initialize an ip_address
<BR>
ipsec addrtypeof - get address type of an ip_address
<BR>
ipsec addrlenof - get length of address within an ip_address
<BR>
ipsec addrbytesof - get copy of address within an ip_address
<BR>
ipsec addrbytesptr - get pointer to address within an ip_address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *dst);</B>
<BR>
<B>int addrtypeof(const ip_address *src);</B>
<BR>
<B>size_t addrlenof(const ip_address *src);</B>
<BR>
<B>size_t addrbytesof(const ip_address *src,</B>
<BR>
&nbsp;
<B>unsigned char *dst, size_t dstlen);</B>
<BR>
<B>size_t addrbytesptr(const ip_address *src,</B>
<BR>
&nbsp;
<B>const unsigned char **dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_address</I>
to contain one of the (currently two) types of IP address.
These functions provide basic tools for creating and examining this type.
<P>
<I>Initaddr</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_address</I>
from an address
(in network byte order,
indicated by a pointer
<I>src</I>
and a length
<I>srclen</I>)
and an address family
<I>af</I>
(typically
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The length must be consistent with the address family.
<P>
<I>Addrtypeof</I>
returns the address type of an address,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Addrlenof</I>
returns the size (in bytes) of the address within an
<I>ip_address</I>,
to permit storage allocation etc.
<P>
<I>Addrbytesof</I>
copies the address within the
<I>ip_address</I>
<I>src</I>
to the buffer indicated by the pointer
<I>dst</I>
and the length
<I>dstlen</I>,
and returns the address length (in bytes).
If the address will not fit,
as many bytes as will fit are copied;
the returned length is still the full length.
It is the caller's responsibility to check the
returned value to ensure that there was enough room.
<P>
<I>Addrbytesptr</I>
sets
<I>*dst</I>
to a pointer to the internal address within the
<I>ip_address</I>,
and returns the address length (in bytes).
If
<I>dst</I>
is
<B>NULL</B>,
it just returns the address length.
The pointer points to
<B>const</B>
to discourage misuse.
<P>
<I>Initaddr</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
The functions which return
<I>size_t</I>
return
<B>0</B>
for a failure.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
An unknown address family is a fatal error for any of these functions
except
<I>addrtypeof</I>.
An address-size mismatch is a fatal error for
<I>initaddr</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Addrtypeof</I>
should probably have been named
<I>addrfamilyof</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

274
doc/manpage.d/ipsec_addrcmp.3.html Normal file
View File

@ -0,0 +1,274 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 28 Nov 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec sameaddr - are two addresses the same?
<BR>
ipsec addrcmp - ordered comparison of addresses
<BR>
ipsec samesubnet - are two subnets the same?
<BR>
ipsec addrinsubnet - is an address within a subnet?
<BR>
ipsec subnetinsubnet - is a subnet within another subnet?
<BR>
ipsec subnetishost - is a subnet a single host?
<BR>
ipsec samesaid - are two SA IDs the same?
<BR>
ipsec sameaddrtype - are two addresses of the same address family?
<BR>
ipsec samesubnettype - are two subnets of the same address family?
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>int sameaddr(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int addrcmp(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int samesubnet(const ip_subnet *a, const ip_subnet *b);</B>
<BR>
<B>int addrinsubnet(const ip_address *a, const ip_subnet *s);</B>
<BR>
<B>int subnetinsubnet(const ip_subnet *a, const ip_subnet *b);</B>
<BR>
<B>int subnetishost(const ip_subnet *s);</B>
<BR>
<B>int samesaid(const ip_said *a, const ip_said *b);</B>
<BR>
<B>int sameaddrtype(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int samesubnettype(const ip_subnet *a, const ip_subnet *b);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions do various comparisons and tests on the
<I>ip_address</I>
type and
<I>ip_subnet</I>
types.
<P>
<I>Sameaddr</I>
returns
non-zero
if addresses
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
Addresses of different families are never identical.
<P>
<I>Addrcmp</I>
returns
<B>-1</B>,
<B>0</B>,
or
<B>1</B>
respectively
if address
<I>a</I>
is less than, equal to, or greater than
<I>b</I>.
If they are not of the same address family,
they are never equal;
the ordering reported in this case is arbitrary
(and probably not useful) but consistent.
<P>
<I>Samesubnet</I>
returns
non-zero
if subnets
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
Subnets of different address families are never identical.
<P>
<I>Addrinsubnet</I>
returns
non-zero
if address
<I>a</I>
is within subnet
<I>s</I>
and
<B>0</B>
otherwise.
An address is never within a
subnet of a different address family.
<P>
<I>Subnetinsubnet</I>
returns
non-zero
if subnet
<I>a</I>
is a subset of subnet
<I>b</I>
and
<B>0</B>
otherwise.
A subnet is deemed to be a subset of itself.
A subnet is never a subset of another
subnet if their address families differ.
<P>
<I>Subnetishost</I>
returns
non-zero
if subnet
<I>s</I>
is in fact only a single host,
and
<B>0</B>
otherwise.
<P>
<I>Samesaid</I>
returns
non-zero
if SA IDs
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
<P>
<I>Sameaddrtype</I>
returns
non-zero
if addresses
<I>a</I>
and
<I>b</I>
are of the same address family,
and
<B>0</B>
otherwise.
<P>
<I>Samesubnettype</I>
returns
non-zero
if subnets
<I>a</I>
and
<I>b</I>
are of the same address family,
and
<B>0</B>
otherwise.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_initaddr.3.html">ipsec_initaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

274
doc/manpage.d/ipsec_addrinsubnet.3.html Normal file
View File

@ -0,0 +1,274 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 28 Nov 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec sameaddr - are two addresses the same?
<BR>
ipsec addrcmp - ordered comparison of addresses
<BR>
ipsec samesubnet - are two subnets the same?
<BR>
ipsec addrinsubnet - is an address within a subnet?
<BR>
ipsec subnetinsubnet - is a subnet within another subnet?
<BR>
ipsec subnetishost - is a subnet a single host?
<BR>
ipsec samesaid - are two SA IDs the same?
<BR>
ipsec sameaddrtype - are two addresses of the same address family?
<BR>
ipsec samesubnettype - are two subnets of the same address family?
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>int sameaddr(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int addrcmp(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int samesubnet(const ip_subnet *a, const ip_subnet *b);</B>
<BR>
<B>int addrinsubnet(const ip_address *a, const ip_subnet *s);</B>
<BR>
<B>int subnetinsubnet(const ip_subnet *a, const ip_subnet *b);</B>
<BR>
<B>int subnetishost(const ip_subnet *s);</B>
<BR>
<B>int samesaid(const ip_said *a, const ip_said *b);</B>
<BR>
<B>int sameaddrtype(const ip_address *a, const ip_address *b);</B>
<BR>
<B>int samesubnettype(const ip_subnet *a, const ip_subnet *b);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions do various comparisons and tests on the
<I>ip_address</I>
type and
<I>ip_subnet</I>
types.
<P>
<I>Sameaddr</I>
returns
non-zero
if addresses
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
Addresses of different families are never identical.
<P>
<I>Addrcmp</I>
returns
<B>-1</B>,
<B>0</B>,
or
<B>1</B>
respectively
if address
<I>a</I>
is less than, equal to, or greater than
<I>b</I>.
If they are not of the same address family,
they are never equal;
the ordering reported in this case is arbitrary
(and probably not useful) but consistent.
<P>
<I>Samesubnet</I>
returns
non-zero
if subnets
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
Subnets of different address families are never identical.
<P>
<I>Addrinsubnet</I>
returns
non-zero
if address
<I>a</I>
is within subnet
<I>s</I>
and
<B>0</B>
otherwise.
An address is never within a
subnet of a different address family.
<P>
<I>Subnetinsubnet</I>
returns
non-zero
if subnet
<I>a</I>
is a subset of subnet
<I>b</I>
and
<B>0</B>
otherwise.
A subnet is deemed to be a subset of itself.
A subnet is never a subset of another
subnet if their address families differ.
<P>
<I>Subnetishost</I>
returns
non-zero
if subnet
<I>s</I>
is in fact only a single host,
and
<B>0</B>
otherwise.
<P>
<I>Samesaid</I>
returns
non-zero
if SA IDs
<I>a</I>
and
<I>b</I>
are identical,
and
<B>0</B>
otherwise.
<P>
<I>Sameaddrtype</I>
returns
non-zero
if addresses
<I>a</I>
and
<I>b</I>
are of the same address family,
and
<B>0</B>
otherwise.
<P>
<I>Samesubnettype</I>
returns
non-zero
if subnets
<I>a</I>
and
<I>b</I>
are of the same address family,
and
<B>0</B>
otherwise.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_initaddr.3.html">ipsec_initaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

232
doc/manpage.d/ipsec_addrlenof.3.html Normal file
View File

@ -0,0 +1,232 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initaddr - initialize an ip_address
<BR>
ipsec addrtypeof - get address type of an ip_address
<BR>
ipsec addrlenof - get length of address within an ip_address
<BR>
ipsec addrbytesof - get copy of address within an ip_address
<BR>
ipsec addrbytesptr - get pointer to address within an ip_address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *dst);</B>
<BR>
<B>int addrtypeof(const ip_address *src);</B>
<BR>
<B>size_t addrlenof(const ip_address *src);</B>
<BR>
<B>size_t addrbytesof(const ip_address *src,</B>
<BR>
&nbsp;
<B>unsigned char *dst, size_t dstlen);</B>
<BR>
<B>size_t addrbytesptr(const ip_address *src,</B>
<BR>
&nbsp;
<B>const unsigned char **dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_address</I>
to contain one of the (currently two) types of IP address.
These functions provide basic tools for creating and examining this type.
<P>
<I>Initaddr</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_address</I>
from an address
(in network byte order,
indicated by a pointer
<I>src</I>
and a length
<I>srclen</I>)
and an address family
<I>af</I>
(typically
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The length must be consistent with the address family.
<P>
<I>Addrtypeof</I>
returns the address type of an address,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Addrlenof</I>
returns the size (in bytes) of the address within an
<I>ip_address</I>,
to permit storage allocation etc.
<P>
<I>Addrbytesof</I>
copies the address within the
<I>ip_address</I>
<I>src</I>
to the buffer indicated by the pointer
<I>dst</I>
and the length
<I>dstlen</I>,
and returns the address length (in bytes).
If the address will not fit,
as many bytes as will fit are copied;
the returned length is still the full length.
It is the caller's responsibility to check the
returned value to ensure that there was enough room.
<P>
<I>Addrbytesptr</I>
sets
<I>*dst</I>
to a pointer to the internal address within the
<I>ip_address</I>,
and returns the address length (in bytes).
If
<I>dst</I>
is
<B>NULL</B>,
it just returns the address length.
The pointer points to
<B>const</B>
to discourage misuse.
<P>
<I>Initaddr</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
The functions which return
<I>size_t</I>
return
<B>0</B>
for a failure.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
An unknown address family is a fatal error for any of these functions
except
<I>addrtypeof</I>.
An address-size mismatch is a fatal error for
<I>initaddr</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Addrtypeof</I>
should probably have been named
<I>addrfamilyof</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

448
doc/manpage.d/ipsec_addrtoa.3.html Normal file
View File

@ -0,0 +1,448 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atoaddr, addrtoa - convert Internet addresses to and from ASCII
<BR>
ipsec atosubnet, subnettoa - convert subnet/mask ASCII form to and from addresses
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atoaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr);</B>
<BR>
<B>size_t addrtoa(struct in_addr addr, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<P>
<B>const char *atosubnet(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr, struct in_addr *mask);</B>
<BR>
<B>size_t subnettoa(struct in_addr addr, struct in_addr mask,</B>
<BR>
&nbsp;
<B>int format, char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A></I>(3)
for their replacements.
<P>
<I>Atoaddr</I>
converts an ASCII name or dotted-decimal address into a binary address
(in network byte order).
<I>Addrtoa</I>
does the reverse conversion, back to an ASCII dotted-decimal address.
<I>Atosubnet</I>
and
<I>subnettoa</I>
do likewise for the ``address/mask'' ASCII form used to write a
specification of a subnet.
<P>
An address is specified in ASCII as a
dotted-decimal address (e.g.
<B>1.2.3.4</B>),
an eight-digit network-order hexadecimal number with the usual C prefix (e.g.
<B>0x01020304</B>,
which is synonymous with
<B>1.2.3.4</B>),
an eight-digit host-order hexadecimal number with a
<B>0h</B>
prefix (e.g.
<B>0h01020304</B>,
which is synonymous with
<B>1.2.3.4</B>
on a big-endian host and
<B>4.3.2.1</B>
on a little-endian host),
a DNS name to be looked up via
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3),
or an old-style network name to be looked up via
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3).
<P>
A dotted-decimal address may be incomplete, in which case
ASCII-to-binary conversion implicitly appends
as many instances of
<B>.0</B>
as necessary to bring it up to four components.
The components of a dotted-decimal address are always taken as
decimal, and leading zeros are ignored.
For example,
<B>10</B>
is synonymous with
<B>10.0.0.0</B>,
and
<B>128.009.000.032</B>
is synonymous with
<B>128.9.0.32</B>
(the latter example is verbatim from RFC 1166).
The result of
<I>addrtoa</I>
is always complete and does not contain leading zeros.
<P>
The letters in
a hexadecimal address may be uppercase or lowercase or any mixture thereof.
Use of hexadecimal addresses is
<B>strongly</B>
<B>discouraged</B>;
they are included only to save hassles when dealing with
the handful of perverted programs which already print
network addresses in hexadecimal.
<P>
DNS names may be complete (optionally terminated with a ``.'')
or incomplete, and are looked up as specified by local system configuration
(see
<I><A HREF="resolver.5.html">resolver</A></I>(5)).
The
<I>h_addr</I>
value returned by
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
is used,
so with current DNS implementations,
the result when the name corresponds to more than one address is
difficult to predict.
Name lookup resorts to
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3)
only if
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
fails.
<P>
A subnet specification is of the form <I>network</I><B>/</B><I>mask</I>.
The
<I>network</I>
and
<I>mask</I>
can be any form acceptable to
<I>atoaddr</I>.
In addition, the
<I>mask</I>
can be a decimal integer (leading zeros ignored) giving a bit count,
in which case
it stands for a mask with that number of high bits on and all others off
(e.g.,
<B>24</B>
means
<B>255.255.255.0</B>).
In any case, the mask must be contiguous
(a sequence of high bits on and all remaining low bits off).
As a special case, the subnet specification
<B>%default</B>
is a synonym for
<B>0.0.0.0/0</B>.
<P>
<I>Atosubnet</I>
ANDs the mask with the address before returning,
so that any non-network bits in the address are turned off
(e.g.,
<B>10.1.2.3/24</B>
is synonymous with
<B>10.1.2.0/24</B>).
<I>Subnettoa</I>
generates the decimal-integer-bit-count
form of the mask,
with no leading zeros,
unless the mask is non-contiguous.
<P>
The
<I>srclen</I>
parameter of
<I>atoaddr</I>
and
<I>atosubnet</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines constants,
<B>ADDRTOA_BUF</B>
and
<B>SUBNETTOA_BUF</B>,
which are the sizes of buffers just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default,
and is in fact the only format currently available.
This parameter is a hedge against future needs.
<P>
The ASCII-to-binary functions return NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
The binary-to-ASCII functions return
<B>0</B>
for a failure, and otherwise
always return the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atoaddr</I>
are:
empty input;
attempt to allocate temporary storage for a very long name failed;
name lookup failed;
syntax error in dotted-decimal form;
dotted-decimal component too large to fit in 8 bits.
<P>
Fatal errors in
<I>atosubnet</I>
are:
no
<B>/</B>
in
<I>src</I>;
<I>atoaddr</I>
error in conversion of
<I>network</I>
or
<I>mask</I>;
bit-count mask too big;
mask non-contiguous.
<P>
Fatal errors in
<I>addrtoa</I>
and
<I>subnettoa</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The interpretation of incomplete dotted-decimal addresses
(e.g.
<B>10/24</B>
means
<B>10.0.0.0/24</B>)
differs from that of some older conversion
functions, e.g. those of
<I><A HREF="inet.3.html">inet</A></I>(3).
The behavior of the older functions has never been
particularly consistent or particularly useful.
<P>
Ignoring leading zeros in dotted-decimal components and bit counts
is arguably the most useful behavior in this application,
but it might occasionally cause confusion with the historical use of leading
zeros to denote octal numbers.
<P>
It is barely possible that somebody, somewhere,
might have a legitimate use for non-contiguous subnet masks.
<P>
<I><A HREF="Getnetbyname.3.html">Getnetbyname</A></I>(3)
is a historical dreg.
<P>
The restriction of ASCII-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The ASCII-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoaddr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

238
doc/manpage.d/ipsec_addrtosubnet.3.html Normal file
View File

@ -0,0 +1,238 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITSUBNET</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITSUBNET</H1>
Section: C Library Functions (3)<BR>Updated: 12 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initsubnet - initialize an ip_subnet
<BR>
ipsec addrtosubnet - initialize a singleton ip_subnet
<BR>
ipsec subnettypeof - get address type of an ip_subnet
<BR>
ipsec masktocount - convert subnet mask to bit count
<BR>
ipsec networkof - get base address of an ip_subnet
<BR>
ipsec maskof - get subnet mask of an ip_subnet
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initsubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>int maskbits, int clash, ip_subnet *dst);</B>
<BR>
<B>const char *addrtosubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>ip_subnet *dst);</B>
<P>
<B>int subnettypeof(const ip_subnet *src);</B>
<BR>
<B>int masktocount(const ip_address *src);</B>
<BR>
<B>void networkof(const ip_subnet *src, ip_address *dst);</B>
<BR>
<B>void maskof(const ip_subnet *src, ip_address *dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_subnet</I>
to contain a description of an IP subnet
(base address plus mask).
These functions provide basic tools for creating and examining this type.
<P>
<I>Initsubnet</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_subnet</I>
from a base address and
a count of mask bits.
The
<I>clash</I>
parameter specifies what to do if the base address includes
<B>1</B>
bits outside the prefix specified by the mask
(that is, in the ``host number'' part of the address):
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT>'0'<DD>
zero out host-number bits
<DT>'x'<DD>
non-zero host-number bits are an error
</DL>
</DL>
<P>
<I>Initsubnet</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
<I>Addrtosubnet</I>
initializes an
<I>ip_subnet</I>
variable
<I>*dst</I>
to a ``singleton subnet'' containing the single address
<I>*addr</I>.
It returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure.
<P>
<I>Subnettypeof</I>
returns the address type of a subnet,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Masktocount</I>
converts a subnet mask, expressed as an address, to a bit count
suitable for use with
<I>initsubnet</I>.
It returns
<B>-1</B>
for error; see DIAGNOSTICS.
<P>
<I>Networkof</I>
fills in
<I>*dst</I>
with the base address of subnet
<I>src</I>.
<P>
<I>Maskof</I>
fills in
<I>*dst</I>
with the subnet mask of subnet
<I>src</I>,
expressed as an address.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttosubnet.3.html">ipsec_ttosubnet</A>(3), <A HREF="ipsec_rangetosubnet.3.html">ipsec_rangetosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>initsubnet</I>
are:
unknown address family;
unknown
<I>clash</I>
value;
impossible mask bit count;
non-zero host-number bits and
<I>clash</I>
is
<B>'x'</B>.
Fatal errors in
<I>addrtosubnet</I>
are:
unknown address family.
Fatal errors in
<I>masktocount</I>
are:
unknown address family;
mask bits not contiguous.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

569
doc/manpage.d/ipsec_addrtot.3.html Normal file
View File

@ -0,0 +1,569 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_TTOADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_TTOADDR</H1>
Section: C Library Functions (3)<BR>Updated: 28 Sept 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec ttoaddr, tnatoaddr, addrtot - convert Internet addresses to and from text
<BR>
ipsec ttosubnet, subnettot - convert subnet/mask text form to and from addresses
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *ttoaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *addr);</B>
<BR>
<B>const char *tnatoaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *addr);</B>
<BR>
<B>size_t addrtot(const ip_address *addr, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<P>
<B>const char *ttosubnet(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_subnet *dst);</B>
<BR>
<B>size_t subnettot(const ip_subnet *sub, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Ttoaddr</I>
converts a text-string name or numeric address into a binary address
(in network byte order).
<I>Tnatoaddr</I>
does the same conversion,
but the only text forms it accepts are
the ``official'' forms of
numeric address (dotted-decimal for IPv4, colon-hex for IPv6).
<I>Addrtot</I>
does the reverse conversion, from binary address back to a text form.
<I>Ttosubnet</I>
and
<I>subnettot</I>
do likewise for the ``address/mask'' form used to write a
specification of a subnet.
<P>
An IPv4 address is specified in text as a
dotted-decimal address (e.g.
<B>1.2.3.4</B>),
an eight-digit network-order hexadecimal number with the usual C prefix (e.g.
<B>0x01020304</B>,
which is synonymous with
<B>1.2.3.4</B>),
an eight-digit host-order hexadecimal number with a
<B>0h</B>
prefix (e.g.
<B>0h01020304</B>,
which is synonymous with
<B>1.2.3.4</B>
on a big-endian host and
<B>4.3.2.1</B>
on a little-endian host),
a DNS name to be looked up via
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3),
or an old-style network name to be looked up via
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3).
<P>
A dotted-decimal address may be incomplete, in which case
text-to-binary conversion implicitly appends
as many instances of
<B>.0</B>
as necessary to bring it up to four components.
The components of a dotted-decimal address are always taken as
decimal, and leading zeros are ignored.
For example,
<B>10</B>
is synonymous with
<B>10.0.0.0</B>,
and
<B>128.009.000.032</B>
is synonymous with
<B>128.9.0.32</B>
(the latter example is verbatim from RFC 1166).
The result of applying
<I>addrtot</I>
to an IPv4 address is always complete and does not contain leading zeros.
<P>
Use of hexadecimal addresses is
<B>strongly</B>
<B>discouraged</B>;
they are included only to save hassles when dealing with
the handful of perverted programs which already print
network addresses in hexadecimal.
<P>
An IPv6 address is specified in text with
colon-hex notation (e.g.
<B>0:56:78ab:22:33:44:55:66</B>),
colon-hex with
<B>::</B>
abbreviating at most one subsequence of multiple zeros (e.g.
<B>99:ab::54:068</B>,
which is synonymous with
<B>99:ab:0:0:0:0:54:68</B>),
or a DNS name to be looked up via
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3).
The result of applying
<I>addrtot</I>
to an IPv6 address will use
<B>::</B>
abbreviation if possible,
and will not contain leading zeros.
<P>
The letters in hexadecimal
may be uppercase or lowercase or any mixture thereof.
<P>
DNS names may be complete (optionally terminated with a ``.'')
or incomplete, and are looked up as specified by local system configuration
(see
<I><A HREF="resolver.5.html">resolver</A></I>(5)).
The
<I>h_addr</I>
value returned by
<I><A HREF="gethostbyname2.3.html">gethostbyname2</A></I>(3)
is used,
so with current DNS implementations,
the result when the name corresponds to more than one address is
difficult to predict.
IPv4 name lookup resorts to
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3)
only if
<I><A HREF="gethostbyname2.3.html">gethostbyname2</A></I>(3)
fails.
<P>
A subnet specification is of the form <I>network</I><B>/</B><I>mask</I>.
The
<I>network</I>
and
<I>mask</I>
can be any form acceptable to
<I>ttoaddr</I>.
In addition, and preferably, the
<I>mask</I>
can be a decimal integer (leading zeros ignored) giving a bit count,
in which case
it stands for a mask with that number of high bits on and all others off
(e.g.,
<B>24</B>
in IPv4 means
<B>255.255.255.0</B>).
In any case, the mask must be contiguous
(a sequence of high bits on and all remaining low bits off).
As a special case, the subnet specification
<B>%default</B>
is a synonym for
<B>0.0.0.0/0</B>
or
<B>::/0</B>
in IPv4 or IPv6 respectively.
<P>
<I>Ttosubnet</I>
ANDs the mask with the address before returning,
so that any non-network bits in the address are turned off
(e.g.,
<B>10.1.2.3/24</B>
is synonymous with
<B>10.1.2.0/24</B>).
<I>Subnettot</I>
always generates the decimal-integer-bit-count
form of the mask,
with no leading zeros.
<P>
The
<I>srclen</I>
parameter of
<I>ttoaddr</I>
and
<I>ttosubnet</I>
specifies the length of the text string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>af</I>
parameter of
<I>ttoaddr</I>
and
<I>ttosubnet</I>
specifies the address family of interest.
It should be either
<B>AF_INET</B>
or
<B>AF_INET6</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>addrtot</I>
and
<I>subnettot</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines constants,
<B>ADDRTOT_BUF</B>
and
<B>SUBNETTOT_BUF</B>,
which are the sizes of buffers just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>addrtot</I>
and
<I>subnettot</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the character
<B>'0'</B>,
but a zero value)
specifies a reasonable default,
and is in fact the only format currently available in
<I>subnettot</I>.
<I>Addrtot</I>
also accepts format values
<B>'r'</B>
(signifying a text form suitable for DNS reverse lookups,
e.g.
<B>4.3.2.1.IN-ADDR.ARPA.</B>
for IPv4 and
RFC 2874 format for IPv6),
and
<B>'R'</B>
(signifying an alternate reverse-lookup form,
an error for IPv4 and RFC 1886 format for IPv6).
Reverse-lookup names always end with a ``.''.
<P>
The text-to-binary functions return NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
The binary-to-text functions return
<B>0</B>
for a failure, and otherwise
always return the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>ttoaddr</I>
are:
empty input;
unknown address family;
attempt to allocate temporary storage for a very long name failed;
name lookup failed;
syntax error in dotted-decimal or colon-hex form;
dotted-decimal or colon-hex component too large.
<P>
Fatal errors in
<I>ttosubnet</I>
are:
no
<B>/</B>
in
<I>src</I>;
<I>ttoaddr</I>
error in conversion of
<I>network</I>
or
<I>mask</I>;
bit-count mask too big;
mask non-contiguous.
<P>
Fatal errors in
<I>addrtot</I>
and
<I>subnettot</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The interpretation of incomplete dotted-decimal addresses
(e.g.
<B>10/24</B>
means
<B>10.0.0.0/24</B>)
differs from that of some older conversion
functions, e.g. those of
<I><A HREF="inet.3.html">inet</A></I>(3).
The behavior of the older functions has never been
particularly consistent or particularly useful.
<P>
Ignoring leading zeros in dotted-decimal components and bit counts
is arguably the most useful behavior in this application,
but it might occasionally cause confusion with the historical use of leading
zeros to denote octal numbers.
<P>
<I>Ttoaddr</I>
does not support the mixed colon-hex-dotted-decimal
convention used to embed an IPv4 address in an IPv6 address.
<P>
<I>Addrtot</I>
always uses the
<B>::</B>
abbreviation (which can appear only once in an address) for the
<I>first</I>
sequence of multiple zeros in an IPv6 address.
One can construct addresses (unlikely ones) in which this is suboptimal.
<P>
<I>Addrtot</I>
<B>'r'</B>
conversion of an IPv6 address uses lowercase hexadecimal,
not the uppercase used in RFC 2874's examples.
It takes careful reading of RFCs 2874, 2673, and 2234 to realize
that lowercase is technically legitimate here,
and there may be software which botches this
and hence would have trouble with lowercase hex.
<P>
Possibly
<I>subnettot</I>
ought to recognize the
<B>%default</B>
case and generate that string as its output.
Currently it doesn't.
<P>
It is barely possible that somebody, somewhere,
might have a legitimate use for non-contiguous subnet masks.
<P>
<I><A HREF="Getnetbyname.3.html">Getnetbyname</A></I>(3)
is a historical dreg.
<P>
<I>Tnatoaddr</I>
probably should enforce completeness of dotted-decimal addresses.
<P>
The restriction of text-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The text-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = ttoaddr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

232
doc/manpage.d/ipsec_addrtypeof.3.html Normal file
View File

@ -0,0 +1,232 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initaddr - initialize an ip_address
<BR>
ipsec addrtypeof - get address type of an ip_address
<BR>
ipsec addrlenof - get length of address within an ip_address
<BR>
ipsec addrbytesof - get copy of address within an ip_address
<BR>
ipsec addrbytesptr - get pointer to address within an ip_address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *dst);</B>
<BR>
<B>int addrtypeof(const ip_address *src);</B>
<BR>
<B>size_t addrlenof(const ip_address *src);</B>
<BR>
<B>size_t addrbytesof(const ip_address *src,</B>
<BR>
&nbsp;
<B>unsigned char *dst, size_t dstlen);</B>
<BR>
<B>size_t addrbytesptr(const ip_address *src,</B>
<BR>
&nbsp;
<B>const unsigned char **dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_address</I>
to contain one of the (currently two) types of IP address.
These functions provide basic tools for creating and examining this type.
<P>
<I>Initaddr</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_address</I>
from an address
(in network byte order,
indicated by a pointer
<I>src</I>
and a length
<I>srclen</I>)
and an address family
<I>af</I>
(typically
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The length must be consistent with the address family.
<P>
<I>Addrtypeof</I>
returns the address type of an address,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Addrlenof</I>
returns the size (in bytes) of the address within an
<I>ip_address</I>,
to permit storage allocation etc.
<P>
<I>Addrbytesof</I>
copies the address within the
<I>ip_address</I>
<I>src</I>
to the buffer indicated by the pointer
<I>dst</I>
and the length
<I>dstlen</I>,
and returns the address length (in bytes).
If the address will not fit,
as many bytes as will fit are copied;
the returned length is still the full length.
It is the caller's responsibility to check the
returned value to ensure that there was enough room.
<P>
<I>Addrbytesptr</I>
sets
<I>*dst</I>
to a pointer to the internal address within the
<I>ip_address</I>,
and returns the address length (in bytes).
If
<I>dst</I>
is
<B>NULL</B>,
it just returns the address length.
The pointer points to
<B>const</B>
to discourage misuse.
<P>
<I>Initaddr</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
The functions which return
<I>size_t</I>
return
<B>0</B>
for a failure.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
An unknown address family is a fatal error for any of these functions
except
<I>addrtypeof</I>.
An address-size mismatch is a fatal error for
<I>initaddr</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Addrtypeof</I>
should probably have been named
<I>addrfamilyof</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

166
doc/manpage.d/ipsec_anyaddr.3.html Normal file
View File

@ -0,0 +1,166 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 8 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec anyaddr - get &quot;any&quot; address
<BR>
ipsec isanyaddr - test address for equality to &quot;any&quot; address
<BR>
ipsec unspecaddr - get &quot;unspecified&quot; address
<BR>
ipsec isunspecaddr - test address for equality to &quot;unspecified&quot; address
<BR>
ipsec loopbackaddr - get loopback address
<BR>
ipsec isloopbackaddr - test address for equality to loopback address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *anyaddr(int af, ip_address *dst);</B>
<BR>
<B>int isanyaddr(const ip_address *src);</B>
<BR>
<B>const char *unspecaddr(int af, ip_address *dst);</B>
<BR>
<B>int isunspecaddr(const ip_address *src);</B>
<BR>
<B>const char *loopbackaddr(int af, ip_address *dst);</B>
<BR>
<B>int isloopbackaddr(const ip_address *src);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions fill in, and test for, special values of the
<I>ip_address</I>
type.
<P>
<I>Anyaddr</I>
fills in the destination
<I>*dst</I>
with the ``any'' address of address family
<I>af</I>
(normally
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The IPv4 ``any'' address is the one embodied in the old
<B>INADDR_ANY</B>
macro.
<P>
<I>Isanyaddr</I>
returns
<B>1</B>
if the
<I>src</I>
address equals the ``any'' address,
and
<B>0</B>
otherwise.
<P>
Similarly,
<I>unspecaddr</I>
supplies, and
<I>isunspecaddr</I>
tests for,
the ``unspecified'' address,
which may be the same as the ``any'' address.
<P>
Similarly,
<I>loopbackaddr</I>
supplies, and
<I>islookbackaddr</I>
tests for,
the loopback address.
<P>
<I>Anyaddr</I>,
<I>unspecaddr</I>,
and
<I>loopbackaddr</I>
return
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_addrtot.3.html">ipsec_addrtot</A>(3), <A HREF="ipsec_sameaddr.3.html">ipsec_sameaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in the address-supplying functions are:
unknown address family.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

448
doc/manpage.d/ipsec_atoaddr.3.html Normal file
View File

@ -0,0 +1,448 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atoaddr, addrtoa - convert Internet addresses to and from ASCII
<BR>
ipsec atosubnet, subnettoa - convert subnet/mask ASCII form to and from addresses
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atoaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr);</B>
<BR>
<B>size_t addrtoa(struct in_addr addr, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<P>
<B>const char *atosubnet(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr, struct in_addr *mask);</B>
<BR>
<B>size_t subnettoa(struct in_addr addr, struct in_addr mask,</B>
<BR>
&nbsp;
<B>int format, char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A></I>(3)
for their replacements.
<P>
<I>Atoaddr</I>
converts an ASCII name or dotted-decimal address into a binary address
(in network byte order).
<I>Addrtoa</I>
does the reverse conversion, back to an ASCII dotted-decimal address.
<I>Atosubnet</I>
and
<I>subnettoa</I>
do likewise for the ``address/mask'' ASCII form used to write a
specification of a subnet.
<P>
An address is specified in ASCII as a
dotted-decimal address (e.g.
<B>1.2.3.4</B>),
an eight-digit network-order hexadecimal number with the usual C prefix (e.g.
<B>0x01020304</B>,
which is synonymous with
<B>1.2.3.4</B>),
an eight-digit host-order hexadecimal number with a
<B>0h</B>
prefix (e.g.
<B>0h01020304</B>,
which is synonymous with
<B>1.2.3.4</B>
on a big-endian host and
<B>4.3.2.1</B>
on a little-endian host),
a DNS name to be looked up via
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3),
or an old-style network name to be looked up via
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3).
<P>
A dotted-decimal address may be incomplete, in which case
ASCII-to-binary conversion implicitly appends
as many instances of
<B>.0</B>
as necessary to bring it up to four components.
The components of a dotted-decimal address are always taken as
decimal, and leading zeros are ignored.
For example,
<B>10</B>
is synonymous with
<B>10.0.0.0</B>,
and
<B>128.009.000.032</B>
is synonymous with
<B>128.9.0.32</B>
(the latter example is verbatim from RFC 1166).
The result of
<I>addrtoa</I>
is always complete and does not contain leading zeros.
<P>
The letters in
a hexadecimal address may be uppercase or lowercase or any mixture thereof.
Use of hexadecimal addresses is
<B>strongly</B>
<B>discouraged</B>;
they are included only to save hassles when dealing with
the handful of perverted programs which already print
network addresses in hexadecimal.
<P>
DNS names may be complete (optionally terminated with a ``.'')
or incomplete, and are looked up as specified by local system configuration
(see
<I><A HREF="resolver.5.html">resolver</A></I>(5)).
The
<I>h_addr</I>
value returned by
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
is used,
so with current DNS implementations,
the result when the name corresponds to more than one address is
difficult to predict.
Name lookup resorts to
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3)
only if
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
fails.
<P>
A subnet specification is of the form <I>network</I><B>/</B><I>mask</I>.
The
<I>network</I>
and
<I>mask</I>
can be any form acceptable to
<I>atoaddr</I>.
In addition, the
<I>mask</I>
can be a decimal integer (leading zeros ignored) giving a bit count,
in which case
it stands for a mask with that number of high bits on and all others off
(e.g.,
<B>24</B>
means
<B>255.255.255.0</B>).
In any case, the mask must be contiguous
(a sequence of high bits on and all remaining low bits off).
As a special case, the subnet specification
<B>%default</B>
is a synonym for
<B>0.0.0.0/0</B>.
<P>
<I>Atosubnet</I>
ANDs the mask with the address before returning,
so that any non-network bits in the address are turned off
(e.g.,
<B>10.1.2.3/24</B>
is synonymous with
<B>10.1.2.0/24</B>).
<I>Subnettoa</I>
generates the decimal-integer-bit-count
form of the mask,
with no leading zeros,
unless the mask is non-contiguous.
<P>
The
<I>srclen</I>
parameter of
<I>atoaddr</I>
and
<I>atosubnet</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines constants,
<B>ADDRTOA_BUF</B>
and
<B>SUBNETTOA_BUF</B>,
which are the sizes of buffers just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default,
and is in fact the only format currently available.
This parameter is a hedge against future needs.
<P>
The ASCII-to-binary functions return NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
The binary-to-ASCII functions return
<B>0</B>
for a failure, and otherwise
always return the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atoaddr</I>
are:
empty input;
attempt to allocate temporary storage for a very long name failed;
name lookup failed;
syntax error in dotted-decimal form;
dotted-decimal component too large to fit in 8 bits.
<P>
Fatal errors in
<I>atosubnet</I>
are:
no
<B>/</B>
in
<I>src</I>;
<I>atoaddr</I>
error in conversion of
<I>network</I>
or
<I>mask</I>;
bit-count mask too big;
mask non-contiguous.
<P>
Fatal errors in
<I>addrtoa</I>
and
<I>subnettoa</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The interpretation of incomplete dotted-decimal addresses
(e.g.
<B>10/24</B>
means
<B>10.0.0.0/24</B>)
differs from that of some older conversion
functions, e.g. those of
<I><A HREF="inet.3.html">inet</A></I>(3).
The behavior of the older functions has never been
particularly consistent or particularly useful.
<P>
Ignoring leading zeros in dotted-decimal components and bit counts
is arguably the most useful behavior in this application,
but it might occasionally cause confusion with the historical use of leading
zeros to denote octal numbers.
<P>
It is barely possible that somebody, somewhere,
might have a legitimate use for non-contiguous subnet masks.
<P>
<I><A HREF="Getnetbyname.3.html">Getnetbyname</A></I>(3)
is a historical dreg.
<P>
The restriction of ASCII-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The ASCII-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoaddr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

294
doc/manpage.d/ipsec_atoasr.3.html Normal file
View File

@ -0,0 +1,294 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOASR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOASR</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atoasr - convert ASCII to Internet address, subnet, or range
<BR>
ipsec rangetoa - convert Internet address range to ASCII
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atoasr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>char *type, struct in_addr *addrs);</B>
<BR>
<B>size_t rangetoa(struct in_addr *addrs, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete;
there is no current equivalent,
because so far they have not proved useful.
<P>
<I>Atoasr</I>
converts an ASCII address, subnet, or address range
into a suitable combination of binary addresses
(in network byte order).
<I>Rangetoa</I>
converts an address range back into ASCII,
using dotted-decimal form for the addresses
(the other reverse conversions are handled by
<I><A HREF="ipsec_addrtoa.3.html">ipsec_addrtoa</A></I>(3)
and
<I><A HREF="ipsec_subnettoa.3.html">ipsec_subnettoa</A></I>(3)).
<P>
A single address can be any form acceptable to
<I><A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A></I>(3):
dotted decimal, DNS name, or hexadecimal number.
A subnet
specification uses the form <I>network</I><B>/</B><I>mask</I>
interpreted by
<I><A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A></I>(3).
<P>
An address range is two
<I><A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A></I>(3)
addresses separated by a
<B>...</B>
delimiter.
If there are four dots rather than three, the first is taken as
part of the begin address,
e.g. for a complete DNS name which ends with
<B>.</B>
to suppress completion attempts.
The begin address of a range must be
less than or equal to the end address.
<P>
The
<I>srclen</I>
parameter of
<I>atoasr</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>type</I>
parameter of
<I>atoasr</I>
must point to a
<B>char</B>
variable used to record which form was found.
The
<I>addrs</I>
parameter must point to a two-element array of
<B>struct in_addr</B>
which receives the results.
The values stored into
<B>*type</B>,
and the corresponding values in the array, are:
<P>
<TT>&nbsp;&nbsp;&nbsp;</TT>*typeaddrs[0]addrs[1]<BR>
<P>
address<B>'a'</B>address-<BR>
<BR>
subnet<TT>&nbsp;</TT><B>'s'</B>networkmask<BR>
<BR>
range<TT>&nbsp;&nbsp;</TT><B>'r'</B>beginend<BR>
<P>
The
<I>dstlen</I>
parameter of
<I>rangetoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines a constant,
<B>RANGETOA_BUF</B>,
which is the size of a buffer just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>rangetoa</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default,
and is in fact the only format currently available.
This parameter is a hedge against future needs.
<P>
<I>Atoasr</I>
returns NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<I>Rangetoa</I>
returns
<B>0</B>
for a failure, and otherwise
always returns the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atoasr</I>
are:
empty input;
error in
<I><A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A></I>(3)
or
<I><A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A></I>(3)
during conversion;
begin address of range exceeds end address.
<P>
Fatal errors in
<I>rangetoa</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The restriction of error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoasr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

347
doc/manpage.d/ipsec_atosa.3.html Normal file
View File

@ -0,0 +1,347 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOSA</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOSA</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atosa, satoa - convert IPsec Security Association IDs to and from ASCII
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atosa(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct sa_id *sa);</B>
<BR>
<B>size_t satoa(struct sa_id sa, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<P>
<B>struct sa_id {</B>
<BR>
&nbsp;
<B>struct in_addr dst;</B>
<BR>
&nbsp;
<B>ipsec_spi_t spi;</B>
<BR>
&nbsp;
<B>int proto;</B>
<BR>
<B>};</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_ttosa.3.html">ipsec_ttosa</A></I>(3)
for their replacements.
<P>
<I>Atosa</I>
converts an ASCII Security Association (SA) specifier into an
<B>sa_id</B>
structure (containing
a destination-host address
in network byte order,
an SPI number in network byte order, and
a protocol code).
<I>Satoa</I>
does the reverse conversion, back to an ASCII SA specifier.
<P>
An SA is specified in ASCII with a mail-like syntax, e.g.
<B><A HREF="mailto:esp507@1.2.3.4">esp507@1.2.3.4</A></B>.
An SA specifier contains
a protocol prefix (currently
<B>ah</B>,
<B>esp</B>,
or
<B>tun</B>),
an unsigned integer SPI number,
and an IP address.
The SPI number can be decimal or hexadecimal
(with
<B>0x</B>
prefix), as accepted by
<I><A HREF="ipsec_atoul.3.html">ipsec_atoul</A></I>(3).
The IP address can be any form accepted by
<I><A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A></I>(3),
e.g. dotted-decimal address or DNS name.
<P>
As a special case, the SA specifier
<B>%passthrough</B>
signifies the special SA used to indicate that packets should be
passed through unaltered.
(At present, this is a synonym for
<B><A HREF="mailto:tun0x0@0.0.0.0">tun0x0@0.0.0.0</A></B>,
but that is subject to change without notice.)
This form is known to both
<I>atosa</I>
and
<I>satoa</I>,
so the internal form of
<B>%passthrough</B>
is never visible.
<P>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file supplies the
<B>sa_id</B>
structure, as well as a data type
<B>ipsec_spi_t</B>
which is an unsigned 32-bit integer.
(There is no consistency between kernel and user on what such a type
is called, hence the header hides the differences.)
<P>
The protocol code uses the same numbers that IP does.
For user convenience, given the difficulty in acquiring the exact set of
protocol names used by the kernel,
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
defines the names
<B>SA_ESP</B>,
<B>SA_AH</B>,
and
<B>SA_IPIP</B>
to have the same values as the kernel names
<B>IPPROTO_ESP</B>,
<B>IPPROTO_AH</B>,
and
<B>IPPROTO_IPIP</B>.
<P>
The
<I>srclen</I>
parameter of
<I>atosa</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>satoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines a constant,
<B>SATOA_BUF</B>,
which is the size of a buffer just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>satoa</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default
(currently
lowercase protocol prefix, lowercase hexadecimal SPI, dotted-decimal address).
The value
<B>d</B>
causes the SPI to be generated in decimal instead.
<P>
<I>Atosa</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<I>Satoa</I>
returns
<B>0</B>
for a failure, and otherwise
always returns the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec_atoul.3.html">ipsec_atoul</A>(3), <A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A>(3), <A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atosa</I>
are:
empty input;
input too small to be a legal SA specifier;
no
<B>@</B>
in input;
unknown protocol prefix;
conversion error in
<I>atoul</I>
or
<I>atoaddr</I>.
<P>
Fatal errors in
<I>satoa</I>
are:
unknown format; unknown protocol code.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The
<B>tun</B>
protocol code is a FreeS/WANism which may eventually disappear.
<P>
The restriction of ASCII-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The ASCII-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoaddr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

448
doc/manpage.d/ipsec_atosubnet.3.html Normal file
View File

@ -0,0 +1,448 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atoaddr, addrtoa - convert Internet addresses to and from ASCII
<BR>
ipsec atosubnet, subnettoa - convert subnet/mask ASCII form to and from addresses
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atoaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr);</B>
<BR>
<B>size_t addrtoa(struct in_addr addr, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<P>
<B>const char *atosubnet(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>struct in_addr *addr, struct in_addr *mask);</B>
<BR>
<B>size_t subnettoa(struct in_addr addr, struct in_addr mask,</B>
<BR>
&nbsp;
<B>int format, char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A></I>(3)
for their replacements.
<P>
<I>Atoaddr</I>
converts an ASCII name or dotted-decimal address into a binary address
(in network byte order).
<I>Addrtoa</I>
does the reverse conversion, back to an ASCII dotted-decimal address.
<I>Atosubnet</I>
and
<I>subnettoa</I>
do likewise for the ``address/mask'' ASCII form used to write a
specification of a subnet.
<P>
An address is specified in ASCII as a
dotted-decimal address (e.g.
<B>1.2.3.4</B>),
an eight-digit network-order hexadecimal number with the usual C prefix (e.g.
<B>0x01020304</B>,
which is synonymous with
<B>1.2.3.4</B>),
an eight-digit host-order hexadecimal number with a
<B>0h</B>
prefix (e.g.
<B>0h01020304</B>,
which is synonymous with
<B>1.2.3.4</B>
on a big-endian host and
<B>4.3.2.1</B>
on a little-endian host),
a DNS name to be looked up via
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3),
or an old-style network name to be looked up via
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3).
<P>
A dotted-decimal address may be incomplete, in which case
ASCII-to-binary conversion implicitly appends
as many instances of
<B>.0</B>
as necessary to bring it up to four components.
The components of a dotted-decimal address are always taken as
decimal, and leading zeros are ignored.
For example,
<B>10</B>
is synonymous with
<B>10.0.0.0</B>,
and
<B>128.009.000.032</B>
is synonymous with
<B>128.9.0.32</B>
(the latter example is verbatim from RFC 1166).
The result of
<I>addrtoa</I>
is always complete and does not contain leading zeros.
<P>
The letters in
a hexadecimal address may be uppercase or lowercase or any mixture thereof.
Use of hexadecimal addresses is
<B>strongly</B>
<B>discouraged</B>;
they are included only to save hassles when dealing with
the handful of perverted programs which already print
network addresses in hexadecimal.
<P>
DNS names may be complete (optionally terminated with a ``.'')
or incomplete, and are looked up as specified by local system configuration
(see
<I><A HREF="resolver.5.html">resolver</A></I>(5)).
The
<I>h_addr</I>
value returned by
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
is used,
so with current DNS implementations,
the result when the name corresponds to more than one address is
difficult to predict.
Name lookup resorts to
<I><A HREF="getnetbyname.3.html">getnetbyname</A></I>(3)
only if
<I><A HREF="gethostbyname.3.html">gethostbyname</A></I>(3)
fails.
<P>
A subnet specification is of the form <I>network</I><B>/</B><I>mask</I>.
The
<I>network</I>
and
<I>mask</I>
can be any form acceptable to
<I>atoaddr</I>.
In addition, the
<I>mask</I>
can be a decimal integer (leading zeros ignored) giving a bit count,
in which case
it stands for a mask with that number of high bits on and all others off
(e.g.,
<B>24</B>
means
<B>255.255.255.0</B>).
In any case, the mask must be contiguous
(a sequence of high bits on and all remaining low bits off).
As a special case, the subnet specification
<B>%default</B>
is a synonym for
<B>0.0.0.0/0</B>.
<P>
<I>Atosubnet</I>
ANDs the mask with the address before returning,
so that any non-network bits in the address are turned off
(e.g.,
<B>10.1.2.3/24</B>
is synonymous with
<B>10.1.2.0/24</B>).
<I>Subnettoa</I>
generates the decimal-integer-bit-count
form of the mask,
with no leading zeros,
unless the mask is non-contiguous.
<P>
The
<I>srclen</I>
parameter of
<I>atoaddr</I>
and
<I>atosubnet</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines constants,
<B>ADDRTOA_BUF</B>
and
<B>SUBNETTOA_BUF</B>,
which are the sizes of buffers just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>addrtoa</I>
and
<I>subnettoa</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default,
and is in fact the only format currently available.
This parameter is a hedge against future needs.
<P>
The ASCII-to-binary functions return NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
The binary-to-ASCII functions return
<B>0</B>
for a failure, and otherwise
always return the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atoaddr</I>
are:
empty input;
attempt to allocate temporary storage for a very long name failed;
name lookup failed;
syntax error in dotted-decimal form;
dotted-decimal component too large to fit in 8 bits.
<P>
Fatal errors in
<I>atosubnet</I>
are:
no
<B>/</B>
in
<I>src</I>;
<I>atoaddr</I>
error in conversion of
<I>network</I>
or
<I>mask</I>;
bit-count mask too big;
mask non-contiguous.
<P>
Fatal errors in
<I>addrtoa</I>
and
<I>subnettoa</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The interpretation of incomplete dotted-decimal addresses
(e.g.
<B>10/24</B>
means
<B>10.0.0.0/24</B>)
differs from that of some older conversion
functions, e.g. those of
<I><A HREF="inet.3.html">inet</A></I>(3).
The behavior of the older functions has never been
particularly consistent or particularly useful.
<P>
Ignoring leading zeros in dotted-decimal components and bit counts
is arguably the most useful behavior in this application,
but it might occasionally cause confusion with the historical use of leading
zeros to denote octal numbers.
<P>
It is barely possible that somebody, somewhere,
might have a legitimate use for non-contiguous subnet masks.
<P>
<I><A HREF="Getnetbyname.3.html">Getnetbyname</A></I>(3)
is a historical dreg.
<P>
The restriction of ASCII-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The ASCII-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoaddr( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

266
doc/manpage.d/ipsec_atoul.3.html Normal file
View File

@ -0,0 +1,266 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ATOUL</TITLE>
</HEAD><BODY>
<H1>IPSEC_ATOUL</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec atoul, ultoa - convert unsigned-long numbers to and from ASCII
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *atoul(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int base, unsigned long *n);</B>
<BR>
<B>size_t ultoa(unsigned long n, int base, char *dst,</B>
<BR>
&nbsp;
<B>size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_ttoul.3.html">ipsec_ttoul</A></I>(3)
for their replacements.
<P>
<I>Atoul</I>
converts an ASCII number into a binary
<B>unsigned long</B>
value.
<I>Ultoa</I>
does the reverse conversion, back to an ASCII version.
<P>
Numbers are specified in ASCII as
decimal (e.g.
<B>123</B>),
octal with a leading zero (e.g.
<B>012</B>,
which has value 10),
or hexadecimal with a leading
<B>0x</B>
(e.g.
<B>0x1f</B>,
which has value 31)
in either upper or lower case.
<P>
The
<I>srclen</I>
parameter of
<I>atoul</I>
specifies the length of the ASCII string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>base</I>
parameter of
<I>atoul</I>
can be
<B>8</B>,
<B>10</B>,
or
<B>16</B>,
in which case the number supplied is assumed to be of that form
(and in the case of
<B>16</B>,
to lack any
<B>0x</B>
prefix).
It can also be
<B>0</B>,
in which case the number is examined for a leading zero
or a leading
<B>0x</B>
to determine its base,
or
<B>13</B>
(halfway between 10 and 16),
which has the same effect as
<B>0</B>
except that a non-hexadecimal
number is considered decimal regardless of any leading zero.
<P>
The
<I>dstlen</I>
parameter of
<I>ultoa</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
<P>
The
<I>base</I>
parameter of
<I>ultoa</I>
must be
<B>8</B>,
<B>10</B>,
or
<B>16</B>.
<P>
<I>Atoul</I>
returns NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<I>Ultoa</I>
returns the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="atol.3.html">atol</A>(3), <A HREF="strtoul.3.html">strtoul</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>atoul</I>
are:
empty input;
unknown
<I>base</I>;
non-digit character found;
number too large for an
<B>unsigned long</B>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
There is no provision for reporting an invalid
<I>base</I>
parameter given to
<I>ultoa</I>.
<P>
The restriction of error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The error-reporting convention lends itself to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = atoul( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

416
doc/manpage.d/ipsec_auto.8.html Normal file
View File

@ -0,0 +1,416 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_AUTO</TITLE>
</HEAD><BODY>
<H1>IPSEC_AUTO</H1>
Section: Maintenance Commands (8)<BR>Updated: 31 Jan 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec auto - control automatically-keyed IPsec connections
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>auto</B>
[
<B>--show</B>
] [
<B>--showonly</B>
] [
<B>--asynchronous</B>
]
<BR>
&nbsp;&nbsp;&nbsp;[
<B>--config</B>
configfile
] [
<B>--verbose</B>
]
<BR>
&nbsp;&nbsp;&nbsp;operation
connection
<P>
<B>ipsec</B>
<B>auto</B>
[
<B>--show</B>
] [
<B>--showonly</B>
] operation
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Auto</I>
manipulates automatically-keyed FreeS/WAN IPsec connections,
setting them up and shutting them down
based on the information in the IPsec configuration file.
In the normal usage,
<I>connection</I>
is the name of a connection specification in the configuration file;
<I>operation</I>
is
<B>--add</B>,
<B>--delete</B>,
<B>--replace</B>,
<B>--up</B>,
<B>--down</B>,
<B>--route</B>,
or
<B>--unroute</B>.
The
<B>--ready</B>,
<B>--rereadsecrets</B>,
<B>--rereadgroups</B>,
and
<B>--status</B>
<I>operations</I>
do not take a connection name.
<I>Auto</I>
generates suitable
commands and feeds them to a shell for execution.
<P>
The
<B>--add</B>
operation adds a connection specification to the internal database
within
<I>pluto</I>;
it will fail if
<I>pluto</I>
already has a specification by that name.
The
<B>--delete</B>
operation deletes a connection specification from
<I>pluto</I>'s
internal database (also tearing down any connections based on it);
it will fail if the specification does not exist.
The
<B>--replace</B>
operation is equivalent to
<B>--delete</B>
(if there is already a specification by the given name)
followed by
<B>--add</B>,
and is a convenience for updating
<I>pluto</I>'s
internal specification to match an external one.
(Note that a
<B>--rereadsecrets</B>
may also be needed.)
The
<B>--rereadgroups</B>
operation causes any changes to the policy group files to take effect
(this is currently a synonym for
<B>--ready</B>,
but that may change).
None of the other operations alters the internal database.
<P>
The
<B>--up</B>
operation asks
<I>pluto</I>
to establish a connection based on an entry in its internal database.
The
<B>--down</B>
operation tells
<I>pluto</I>
to tear down such a connection.
<P>
Normally,
<I>pluto</I>
establishes a route to the destination specified for a connection as
part of the
<B>--up</B>
operation.
However, the route and only the route can be established with the
<B>--route</B>
operation.
Until and unless an actual connection is established,
this discards any packets sent there,
which may be preferable to having them sent elsewhere based on a more
general route (e.g., a default route).
<P>
Normally,
<I>pluto</I>'s
route to a destination remains in place when a
<B>--down</B>
operation is used to take the connection down
(or if connection setup, or later automatic rekeying, fails).
This permits establishing a new connection (perhaps using a
different specification; the route is altered as necessary)
without having a ``window'' in which packets might go elsewhere
based on a more general route.
Such a route can be removed using the
<B>--unroute</B>
operation
(and is implicitly removed by
<B>--delete</B>).
<P>
The
<B>--ready</B>
operation tells
<I>pluto</I>
to listen for connection-setup requests from other hosts.
Doing an
<B>--up</B>
operation before doing
<B>--ready</B>
on both ends is futile and will not work,
although this is now automated as part of IPsec startup and
should not normally be an issue.
<P>
The
<B>--status</B>
operation asks
<I>pluto</I>
for current connection status.
The output format is ad-hoc and likely to change.
<P>
The
<B>--rereadsecrets</B>
operation tells
<I>pluto</I>
to re-read the
<I>/etc/ipsec.secrets</I>
secret-keys file,
which it normally reads only at startup time.
(This is currently a synonym for
<B>--ready</B>,
but that may change.)
<P>
The
<B>--show</B>
option turns on the
<B>-x</B>
option of the shell used to execute the commands,
so each command is shown as it is executed.
<P>
The
<B>--showonly</B>
option causes
<I>auto</I>
to show the commands it would run, on standard output,
and not run them.
<P>
The
<B>--asynchronous</B>
option, applicable only to the
<B>up</B>
operation,
tells
<I>pluto</I>
to attempt to establish the connection,
but does not delay to report results.
This is especially useful to start multiple connections in parallel
when network links are slow.
<P>
The
<B>--verbose</B>
option instructs
<I>auto</I>
to pass through all output from
<I><A HREF="ipsec_whack.8.html">ipsec_whack</A></I>(8),
including log output that is normally filtered out as uninteresting.
<P>
The
<B>--config</B>
option specifies a non-standard location for the IPsec
configuration file (default
<I>/etc/ipsec.conf</I>).
<P>
See
<I><A HREF="ipsec.conf.5.html">ipsec.conf</A></I>(5)
for details of the configuration file.
Apart from the basic parameters which specify the endpoints and routing
of a connection (<B>left</B>
and
<B>right</B>,
plus possibly
<B>leftsubnet</B>,
<B>leftnexthop</B>,
<B>leftfirewall</B>,
their
<B>right</B>
equivalents,
and perhaps
<B>type</B>),
an
<I>auto</I>
connection almost certainly needs a
<B>keyingtries</B>
parameter (since the
<B>keyingtries</B>
default is poorly chosen).
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
/etc/ipsec.conf<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>default IPSEC configuration file<BR>
<BR>
/var/run/ipsec.info<TT>&nbsp;&nbsp;&nbsp;</TT><B>%defaultroute</B> information<BR>
<A NAME="lbAF">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.conf.5.html">ipsec.conf</A>(5), <A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_pluto.8.html">ipsec_pluto</A>(8), <A HREF="ipsec_whack.8.html">ipsec_whack</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8)
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
Although an
<B>--up</B>
operation does connection setup on both ends,
<B>--down</B>
tears only one end of the connection down
(although the orphaned end will eventually time out).
<P>
There is no support for
<B>passthrough</B>
connections.
<P>
A connection description which uses
<B>%defaultroute</B>
for one of its
<B>nexthop</B>
parameters but not the other may be falsely
rejected as erroneous in some circumstances.
<P>
The exit status of
<B>--showonly</B>
does not always reflect errors discovered during processing of the request.
(This is fine for human inspection, but not so good for use in scripts.)
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">SEE ALSO</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

150
doc/manpage.d/ipsec_barf.8.html Normal file
View File

@ -0,0 +1,150 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_BARF</TITLE>
</HEAD><BODY>
<H1>IPSEC_BARF</H1>
Section: Maintenance Commands (8)<BR>Updated: 17 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec barf - spew out collected IPsec debugging information
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>barf</B>
[
<B>--short</B>
]
<P>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Barf</I>
outputs (on standard output) a collection of debugging information
(contents of files, selections from logs, etc.)
related to the IPsec encryption/authentication system.
It is primarily a convenience for remote debugging,
a single command which packages up (and labels) all information
that might be relevant to diagnosing a problem in IPsec.
<P>
<P>
The
<B>--short</B>
option limits the length of
the log portion of
<I>barf</I>'s
output, which can otherwise be extremely voluminous
if debug logging is turned on.
<P>
<I>Barf</I>
censors its output,
replacing keys
and secrets with brief checksums to avoid revealing sensitive information.
<P>
Beware that the output of both commands is aimed at humans,
not programs,
and the output format is subject to change without warning.
<P>
<I>Barf</I>
has to figure out which files in
<I>/var/log</I>
contain the IPsec log messages.
It looks for KLIPS and general log messages first in
<I>messages</I>
and
<I>syslog</I>,
and for Pluto messages first in
<I>secure</I>,
<I>auth.log</I>,
and
<I>debug</I>.
In both cases,
if it does not find what it is looking for in one of those ``likely'' places,
it will resort to a brute-force search of most (non-compressed) files in
<I>/var/log</I>.
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
<PRE>
/proc/net/*
/var/log/*
/etc/ipsec.conf
/etc/ipsec.secrets
</PRE>
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Henry Spencer.
<A NAME="lbAG">&nbsp;</A>
<H2>BUGS</H2>
<I>Barf</I>
uses heuristics to try to pick relevant material out of the logs,
and relevant messages
which are not labelled with any of the tags that
<I>barf</I>
looks for will be lost.
We think we've eliminated the last such case, but one never knows...
<P>
Finding
<I>updown</I>
scripts (so they can be included in output) is, in general, difficult.
<I>Barf</I>
uses a very simple heuristic that is easily fooled.
<P>
The brute-force search for the right log files can get expensive on
systems with a lot of clutter in
<I>/var/log</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
<DT><A HREF="#lbAG">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

122
doc/manpage.d/ipsec_bitstomask.3.html Normal file
View File

@ -0,0 +1,122 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_GOODMASK</TITLE>
</HEAD><BODY>
<H1>IPSEC_GOODMASK</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec goodmask - is this Internet subnet mask a valid one?
<BR>
ipsec masktobits - convert Internet subnet mask to bit count
<BR>
ipsec bitstomask - convert bit count to Internet subnet mask
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>int goodmask(struct in_addr mask);</B>
<BR>
<B>int masktobits(struct in_addr mask);</B>
<BR>
<B>struct in_addr bitstomask(int n);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete;
see
<I><A HREF="ipsec_masktocount.3.html">ipsec_masktocount</A></I>(3)
for a partial replacement.
<P>
<I>Goodmask</I>
reports whether the subnet
<I>mask</I>
is a valid one,
i.e. consists of a (possibly empty) sequence of
<B>1</B>s
followed by a (possibly empty) sequence of
<B>0</B>s.
<I>Masktobits</I>
takes a (valid) subnet mask and returns the number of
<B>1</B>
bits in it.
<I>Bitstomask</I>
reverses this,
returning the subnet mask corresponding to bit count
<I>n</I>.
<P>
All masks are in network byte order.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
<I>Masktobits</I>
returns
<B>-1</B>
for an invalid mask.
<I>Bitstomask</I>
returns an all-zeros mask for a negative or out-of-range
<I>n</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The error-reporting convention of
<I>bitstomask</I>
is less than ideal;
zero is sometimes a legitimate mask.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

107
doc/manpage.d/ipsec_broadcastof.3.html Normal file
View File

@ -0,0 +1,107 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_SUBNETOF</TITLE>
</HEAD><BODY>
<H1>IPSEC_SUBNETOF</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec subnetof - given Internet address and subnet mask, return subnet number
<BR>
ipsec hostof - given Internet address and subnet mask, return host part
<BR>
ipsec broadcastof - given Internet address and subnet mask, return broadcast address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>struct in_addr subnetof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<BR>
<B>struct in_addr hostof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<BR>
<B>struct in_addr broadcastof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_networkof.3.html">ipsec_networkof</A></I>(3)
for their replacements.
<P>
<I>Subnetof</I>
takes an Internet
<I>address</I>
and a subnet
<I>mask</I>
and returns the network part of the address
(all in network byte order).
<I>Hostof</I>
similarly returns the host part, and
<I>broadcastof</I>
returns the broadcast address (all-1s convention) for the network.
<P>
These functions are provided to hide the Internet bit-munging inside
an API, in hopes of easing the eventual transition to IPv6.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAG">&nbsp;</A>
<H2>BUGS</H2>
Calling functions for this is more costly than doing it yourself.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
<DT><A HREF="#lbAG">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

78
doc/manpage.d/ipsec_calcgoo.8.html Normal file
View File

@ -0,0 +1,78 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_CALCGOO</TITLE>
</HEAD><BODY>
<H1>IPSEC_CALCGOO</H1>
Section: Maintenance Commands (8)<BR>Updated: 8 June 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec calcgoo - calculate hex value for matching modules and kernels
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>calcgoo</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>calcgoo</I>
accepts the output of
<B>nm -ao</B>
or
<B>/proc/ksyms</B>
and extracts a release dependant list of symbols from it. The symbols
are processed to extract the values assigned during the MODVERSIONS
process. This process makes sure that Linux modules are only loaded
on matching kernels.
This routine is used to find an appropriate module to match the currently
running kernel by _startklips.
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
<PRE>
/proc/ksyms
</PRE>
<A NAME="lbAF">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec__startklips.8.html">ipsec__startklips</A>(8), <A HREF="genksyms.8.html">genksyms</A>(8)
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Michael Richardson.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">SEE ALSO</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

94
doc/manpage.d/ipsec_copyright_notice.3.html Normal file
View File

@ -0,0 +1,94 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_VERSION</TITLE>
</HEAD><BODY>
<H1>IPSEC_VERSION</H1>
Section: C Library Functions (3)<BR>Updated: 21 Nov 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec ipsec_version_code - get IPsec version code
<BR>
ipsec ipsec_version_string - get full IPsec version string
<BR>
ipsec ipsec_copyright_notice - get IPsec copyright notice
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *ipsec_version_code(void);</B>
<BR>
<B>const char *ipsec_version_string(void);</B>
<BR>
<B>const char **ipsec_copyright_notice(void);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions provide information on version numbering and copyright
of the Linux FreeS/WAN IPsec implementation.
<P>
<I>Ipsec_version_code</I>
returns a pointer to a string constant
containing the current IPsec version code,
such as ``1.92'' or ``snap2001Nov19b''.
<P>
<I>Ipsec_version_string</I>
returns a pointer to a string constant giving a full version identification,
consisting of the version code preceded by a prefix identifying the software,
e.g. ``Linux FreeS/WAN 1.92''.
<P>
<I>Ipsec_copyright_notice</I>
returns a pointer to a vector of pointers,
terminated by a
<B>NULL</B>,
which is the text of a suitable copyright notice.
Each pointer points to a string constant (possibly empty) which is one line
of the somewhat-verbose copyright notice.
The strings are NUL-terminated and do not contain a newline;
supplying suitable line termination for the output device is
the caller's responsibility.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

439
doc/manpage.d/ipsec_datatot.3.html Normal file
View File

@ -0,0 +1,439 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_TTODATA</TITLE>
</HEAD><BODY>
<H1>IPSEC_TTODATA</H1>
Section: C Library Functions (3)<BR>Updated: 16 August 2003<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec ttodata, datatot - convert binary data bytes from and to text formats
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *ttodata(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int base, char *dst, size_t dstlen, size_t *lenp);</B>
<BR>
<B>const char *ttodatav(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int base, char *dst, size_t dstlen, size_t *lenp,</B>
<BR>
&nbsp;
<B>char *errp, size_t errlen, int flags);</B>
<BR>
<B>size_t datatot(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int format, char *dst, size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Ttodata</I>,
<I>ttodatav</I>,
and
<I>datatot</I>
convert arbitrary binary data (e.g. encryption or authentication keys)
from and to more-or-less human-readable text formats.
<P>
Currently supported formats are hexadecimal, base64, and characters.
<P>
A hexadecimal text value begins with a
<B>0x</B>
(or
<B>0X</B>)
prefix and continues with two-digit groups
of hexadecimal digits (0-9, and a-f or A-F),
each group encoding the value of one binary byte, high-order digit first.
A single
<B>_</B>
(underscore)
between consecutive groups is ignored, permitting punctuation to improve
readability; doing this every eight digits seems about right.
<P>
A base64 text value begins with a
<B>0s</B>
(or
<B>0S</B>)
prefix
and continues with four-digit groups of base64 digits (A-Z, a-z, 0-9, +, and /),
each group encoding the value of three binary bytes as described in
section 6.8 of RFC 2045.
If
<B>flags</B>
has the
<B>TTODATAV_IGNORESPACE</B>
bit on, blanks are ignore (after the prefix).
Note that the last one or two digits of a base64 group can be
<B>=</B>
to indicate that fewer than three binary bytes are encoded.
<P>
A character text value begins with a
<B>0t</B>
(or
<B>0T</B>)
prefix
and continues with text characters, each being the value of one binary byte.
<P>
All these functions basically copy data from
<I>src</I>
(whose size is specified by
<I>srclen</I>)
to
<I>dst</I>
(whose size is specified by
<I>dstlen</I>),
doing the conversion en route.
If the result will not fit in
<I>dst</I>,
it is truncated;
under no circumstances are more than
<I>dstlen</I>
bytes of result written to
<I>dst</I>.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result bytes are written at all.
<P>
The
<I>base</I>
parameter of
<I>ttodata</I>
and
<I>ttodatav</I>
specifies what format the input is in;
normally it should be
<B>0</B>
to signify that this gets figured out from the prefix.
Values of
<B>16</B>,
<B>64</B>,
and
<B>256</B>
respectively signify hexadecimal, base64, and character-text formats
without prefixes.
<P>
The
<I>format</I>
parameter of
<I>datatot</I>,
a single character used as a type code,
specifies which text format is wanted.
The value
<B>0</B>
(not ASCII
<B>'0'</B>,
but a zero value) specifies a reasonable default.
Other currently-supported values are:
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT><B>'x'</B>
<DD>
continuous lower-case hexadecimal with a
<B>0x</B>
prefix
<DT><B>'h'</B>
<DD>
lower-case hexadecimal with a
<B>0x</B>
prefix and a
<B>_</B>
every eight digits
<DT><B>':'</B>
<DD>
lower-case hexadecimal with no prefix and a
<B>:</B>
(colon) every two digits
<DT><B>16</B>
<DD>
lower-case hexadecimal with no prefix or
<B>_</B>
<DT><B>'s'</B>
<DD>
continuous base64 with a
<B>0s</B>
prefix
<DT><B>64</B>
<DD>
continuous base64 with no prefix
</DL>
</DL>
<P>
The default format is currently
<B>'h'</B>.
<P>
<I>Ttodata</I>
returns NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
On success,
if and only if
<I>lenp</I>
is non-NULL,
<B>*lenp</B>
is set to the number of bytes required to contain the full untruncated result.
It is the caller's responsibility to check this against
<I>dstlen</I>
to determine whether he has obtained a complete result.
The
<B>*lenp</B>
value is correct even if
<I>dstlen</I>
is zero, which offers a way to determine how much space would be needed
before having to allocate any.
<P>
<I>Ttodatav</I>
is just like
<I>ttodata</I>
except that in certain cases,
if
<I>errp</I>
is non-NULL,
the buffer pointed to by
<I>errp</I>
(whose length is given by
<I>errlen</I>)
is used to hold a more detailed error message.
The return value is NULL for success,
and is either
<I>errp</I>
or a pointer to a string literal for failure.
If the size of the error-message buffer is
inadequate for the desired message,
<I>ttodatav</I>
will fall back on returning a pointer to a literal string instead.
The
<I>freeswan.h</I>
header file defines a constant
<B>TTODATAV_BUF</B>
which is the size of a buffer large enough for worst-case results.
<P>
The normal return value of
<I>datatot</I>
is the number of bytes required
to contain the full untruncated result.
It is the caller's responsibility to check this against
<I>dstlen</I>
to determine whether he has obtained a complete result.
The return value is correct even if
<I>dstlen</I>
is zero, which offers a way to determine how much space would be needed
before having to allocate any.
A return value of
<B>0</B>
signals a fatal error of some kind
(see DIAGNOSTICS).
<P>
A zero value for
<I>srclen</I>
in
<I>ttodata</I>
(but not
<I>datatot</I>!)
is synonymous with
<B>strlen(src)</B>.
A non-zero
<I>srclen</I>
in
<I>ttodata</I>
must not include the terminating NUL.
<P>
Unless
<I>dstlen</I>
is zero,
the result supplied by
<I>datatot</I>
is always NUL-terminated,
and its needed-size return value includes space for the terminating NUL.
<P>
Several obsolete variants of these functions
(<I>atodata</I>,
<I>datatoa</I>,
<I>atobytes</I>,
and
<I>bytestoa</I>)
are temporarily also supported.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="sprintf.3.html">sprintf</A>(3), <A HREF="ipsec_atoaddr.3.html">ipsec_atoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>ttodata</I>
and
<I>ttodatav</I>
are:
unknown characters in the input;
unknown or missing prefix;
unknown base;
incomplete digit group;
non-zero padding in a base64 less-than-three-bytes digit group;
zero-length input.
<P>
Fatal errors in
<I>datatot</I>
are:
unknown format code;
zero-length input.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Datatot</I>
should have a format code to produce character-text output.
<P>
The
<B>0s</B>
and
<B>0t</B>
prefixes are the author's inventions and are not a standard
of any kind.
They have been chosen to avoid collisions with existing practice
(some C implementations use
<B>0b</B>
for binary)
and possible confusion with unprefixed hexadecimal.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

370
doc/manpage.d/ipsec_eroute.5.html Normal file
View File

@ -0,0 +1,370 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_EROUTE</TITLE>
</HEAD><BODY>
<H1>IPSEC_EROUTE</H1>
Section: File Formats (5)<BR>Updated: 20 Sep 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec_eroute - list of existing eroutes
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>eroute</B>
<P>
<B>cat</B>
<B>/proc/net/ipsec_eroute</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>/proc/net/ipsec_eroute</I>
lists the IPSEC extended routing tables,
which control what (if any) processing is applied
to non-encrypted packets arriving for IPSEC processing and forwarding.
At this point it is a read-only file.
<P>
A table entry consists of:
<DL COMPACT>
<DT>+<DD>
packet count,
<DT>+<DD>
source address with mask,
<DT>+<DD>
a '-&gt;' separator for visual and automated parsing between src and dst
<DT>+<DD>
destination address with mask
<DT>+<DD>
a '=&gt;' separator for visual and automated parsing between selection
criteria and SAID to use
<DT>+<DD>
SAID (Security Association IDentifier), comprised of:
<DT>+<DD>
protocol
(<I>proto</I>),
<DT>+<DD>
address family
(<I>af</I>),
where '.' stands for IPv4 and ':' for IPv6
<DT>+<DD>
Security Parameters Index
(<I>SPI</I>),
<DT>+<DD>
effective destination
(<I>edst</I>),
where the packet should be forwarded after processing
(normally the other security gateway)
together indicate which Security Association should be used to process
the packet,
<DT>+<DD>
source identity text string with no whitespace, in parens,
<DT>+<DD>
destination identity text string with no whitespace, in parens
</DL>
<P>
Addresses are written as IPv4 dotted quads or IPv6 coloned hex,
protocol is one of &quot;ah&quot;, &quot;esp&quot;, &quot;comp&quot; or &quot;tun&quot;
and
SPIs are prefixed hexadecimal numbers where the prefix '.' is for IPv4 and the prefix ':' is for IPv6
<P>
SAIDs are written as &quot;<A HREF="mailto:protoafSPI@edst">protoafSPI@edst</A>&quot;. There are also 5
&quot;magic&quot; SAIDs which have special meaning:
<DL COMPACT>
<DT>+<DD>
<B>%drop</B>
means that matches are to be dropped
<DT>+<DD>
<B>%reject</B>
means that matches are to be dropped and an ICMP returned, if
possible to inform
<DT>+<DD>
<B>%trap</B>
means that matches are to trigger an ACQUIRE message to the Key
Management daemon(s) and a hold eroute will be put in place to
prevent subsequent packets also triggering ACQUIRE messages.
<DT>+<DD>
<B>%hold</B>
means that matches are to stored until the eroute is replaced or
until that eroute gets reaped
<DT>+<DD>
<B>%pass</B>
means that matches are to allowed to pass without IPSEC processing
<BR>
</DL>
<A NAME="lbAE">&nbsp;</A>
<H2>EXAMPLES</H2>
<P>
<B>1867 172.31.252.0/24 -&gt; 0.0.0.0/0 =&gt; <A HREF="mailto:tun.130@192.168.43.1">tun.130@192.168.43.1</A> </B>
<BR>
<B> ()<TT>&nbsp;&nbsp;&nbsp;&nbsp;</TT>()</B>
<P>
means that 1,867 packets have been sent to an<BR>
<B>eroute</B>
that has been set up to protect traffic between the subnet
<B>172.31.252.0</B>
with a subnet mask of
<B>24</B>
bits and the default address/mask represented by an address of
<B>0.0.0.0</B>
with a subnet mask of
<B>0</B>
bits using the local machine as a security gateway on this end of the
tunnel and the machine
<B>192.168.43.1</B>
on the other end of the tunnel with a Security Association IDentifier of
<B><A HREF="mailto:tun0x130@192.168.43.1">tun0x130@192.168.43.1</A></B>
which means that it is a tunnel mode connection (4, IPPROTO_IPIP) with a
Security Parameters Index of
<B>130</B>
in hexadecimal with no identies defined for either end.
<P>
<B>125 3049:1::/64 -&gt; 0:0/0 =&gt; tun:<A HREF="mailto:130@3058">130@3058</A>:4::5<TT>&nbsp;</TT>()<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>()</B>
<P>
means that 125 packets have been sent to an<BR>
<B>eroute</B>
that has been set up to protect traffic between the subnet
<B>3049:1::</B>
with a subnet mask of
<B>64</B>
bits and the default address/mask represented by an address of
<B>0:0</B>
with a subnet mask of
<B>0</B>
bits using the local machine as a security gateway on this end of the
tunnel and the machine
<B>3058:4::5</B>
on the other end of the tunnel with a Security Association IDentifier of
<B>tun:<A HREF="mailto:130@3058">130@3058</A>:4::5</B>
which means that it is a tunnel mode connection with a
Security Parameters Index of
<B>130</B>
in hexadecimal with no identies defined for either end.
<P>
<B>42 192.168.6.0/24 -&gt; 192.168.7.0/24 =&gt; %passthrough</B>
<P>
means that 42 packets have been sent to an
<B>eroute</B>
that has been set up to pass the traffic from the subnet
<B>192.168.6.0</B>
with a subnet mask of
<B>24</B>
bits and to subnet
<B>192.168.7.0</B>
with a subnet mask of
<B>24</B>
bits without any IPSEC processing with no identies defined for either end.
<P>
<B>2112 192.168.8.55/32 -&gt; 192.168.9.47/24 =&gt; %hold<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>(east)<TT>&nbsp;&nbsp;</TT>()</B>
<P>
means that 2112 packets have been sent to an<BR>
<B>eroute</B>
that has been set up to hold the traffic from the host
<B>192.168.8.55</B>
and to host
<B>192.168.9.47</B>
until a key exchange from a Key Management daemon
succeeds and puts in an SA or fails and puts in a pass
or drop eroute depending on the default configuration with the local client
defined as &quot;east&quot; and no identy defined for the remote end.
<P>
<B>2001 192.168.2.110/32 -&gt; 192.168.2.120/32 =&gt; </B>
<BR>
<B> <A HREF="mailto:esp.e6de@192.168.2.120">esp.e6de@192.168.2.120</A><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>()<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>()</B>
<P>
means that 2001 packets have been sent to an<BR>
<B>eroute</B>
that has been set up to protect traffic between the host
<B>192.168.2.110</B>
and the host
<B>192.168.2.120</B>
using
<B>192.168.2.110</B>
as a security gateway on this end of the
connection and the machine
<B>192.168.2.120</B>
on the other end of the connection with a Security Association IDentifier of
<B><A HREF="mailto:esp.e6de@192.168.2.120">esp.e6de@192.168.2.120</A></B>
which means that it is a transport mode connection with a Security
Parameters Index of
<B>e6de</B>
in hexadecimal using Encapsuation Security Payload protocol (50,
IPPROTO_ESP) with no identies defined for either end.
<P>
<B>1984 3049:1::110/128 -&gt; 3049:1::120/128 =&gt; </B>
<BR>
<B> ah:<A HREF="mailto:f5ed@3049">f5ed@3049</A>:1::120<TT>&nbsp;&nbsp;&nbsp;</TT>()<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>()</B>
<P>
means that 1984 packets have been sent to an<BR>
<B>eroute</B>
that has been set up to authenticate traffic between the host
<B>3049:1::110</B>
and the host
<B>3049:1::120</B>
using
<B>3049:1::110</B>
as a security gateway on this end of the
connection and the machine
<B>3049:1::120</B>
on the other end of the connection with a Security Association IDentifier of
<B>ah:<A HREF="mailto:f5ed@3049">f5ed@3049</A>:1::120</B>
which means that it is a transport mode connection with a Security
Parameters Index of
<B>f5ed</B>
in hexadecimal using Authentication Header protocol (51,
IPPROTO_AH) with no identies defined for either end.
<A NAME="lbAF">&nbsp;</A>
<H2>FILES</H2>
/proc/net/ipsec_eroute, /usr/local/bin/ipsec
<A NAME="lbAG">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8), <A HREF="ipsec_tncfg.5.html">ipsec_tncfg</A>(5), <A HREF="ipsec_spi.5.html">ipsec_spi</A>(5),
<A HREF="ipsec_spigrp.5.html">ipsec_spigrp</A>(5), <A HREF="ipsec_klipsdebug.5.html">ipsec_klipsdebug</A>(5), <A HREF="ipsec_eroute.8.html">ipsec_eroute</A>(8), <A HREF="ipsec_version.5.html">ipsec_version</A>(5),
<A HREF="ipsec_pf_key.5.html">ipsec_pf_key</A>(5)
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Richard Guy Briggs.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">EXAMPLES</A><DD>
<DT><A HREF="#lbAF">FILES</A><DD>
<DT><A HREF="#lbAG">SEE ALSO</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

421
doc/manpage.d/ipsec_eroute.8.html Normal file
View File

@ -0,0 +1,421 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_EROUTE</TITLE>
</HEAD><BODY>
<H1>IPSEC_EROUTE</H1>
Section: Maintenance Commands (8)<BR>Updated: 21 Jun 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec eroute - manipulate IPSEC extended routing tables
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>eroute</B>
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--add</B>
<B>--eraf (inet | inet6)</B>
<B>--src</B>
src/srcmaskbits|srcmask
<B>--dst</B>
dst/dstmaskbits|dstmask
&lt;SAID&gt;
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--replace</B>
<B>--eraf (inet | inet6)</B>
<B>--src</B>
src/srcmaskbits|srcmask
<B>--dst</B>
dst/dstmaskbits|dstmask
&lt;SAID&gt;
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--del</B>
<B>--eraf (inet | inet6)</B>
<B>--src</B>
src/srcmaskbits|srcmask
<B>--dst</B>
dst/dstmaskbits|dstmask
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--clear</B>
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--help</B>
<P>
<B>ipsec</B>
<B>eroute</B>
<B>--version</B>
<P>
Where &lt;SAID&gt; is
<B>--af</B>
(inet | inet6)
<B>--edst</B>
edst
<B>--spi</B>
spi
<B>--proto</B>
proto
OR
<B>--said</B>
said
OR
<B>--said</B>
<B>(%passthrough | %passthrough4 | %passthrough6)</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Eroute</I>
manages the IPSEC extended routing tables,
which control what (if any) processing is applied
to non-encrypted packets arriving for IPSEC processing and forwarding.
The form with no additional arguments lists the contents of
/proc/net/ipsec_eroute.
The
<B>--add</B>
form adds a table entry, the
<B>--replace</B>
form replaces a table entry, while the
<B>--del</B>
form deletes one. The
<B>--clear</B>
form deletes the entire table.
<P>
A table entry consists of:
<DL COMPACT>
<DT>+<DD>
source and destination addresses,
with masks,
for selection of packets
<DT>+<DD>
Security Association IDentifier, comprised of:
<DT>+<DD>
protocol
(<I>proto</I>), indicating (together with the
effective destination and the security parameters index)
which Security Association should be used to process the packet
<DT>+<DD>
address family
(<I>af</I>),
<DT>+<DD>
Security Parameters Index
(<I>spi</I>), indicating (together with the
effective destination and protocol)
which Security Association should be used to process the packet
(must be larger than or equal to 0x100)
<DT>+<DD>
effective destination
(<I>edst</I>),
where the packet should be forwarded after processing
(normally the other security gateway)
<DT>+<DD>
OR
<DT>+<DD>
SAID
(<I>said</I>), indicating
which Security Association should be used to process the packet
</DL>
<P>
Addresses are written as IPv4 dotted quads or IPv6 coloned hex,
protocol is one of &quot;ah&quot;, &quot;esp&quot;, &quot;comp&quot; or &quot;tun&quot; and SPIs are
prefixed hexadecimal numbers where '.' represents IPv4 and ':'
stands for IPv6.
<P>
SAIDs are written as &quot;<A HREF="mailto:protoafSPI@address">protoafSPI@address</A>&quot;. There are also 5
&quot;magic&quot; SAIDs which have special meaning:
<DL COMPACT>
<DT>+<DD>
<B>%drop</B>
means that matches are to be dropped
<DT>+<DD>
<B>%reject</B>
means that matches are to be dropped and an ICMP returned, if
possible to inform
<DT>+<DD>
<B>%trap</B>
means that matches are to trigger an ACQUIRE message to the Key
Management daemon(s) and a hold eroute will be put in place to
prevent subsequent packets also triggering ACQUIRE messages.
<DT>+<DD>
<B>%hold</B>
means that matches are to stored until the eroute is replaced or
until that eroute gets reaped
<DT>+<DD>
<B>%pass</B>
means that matches are to allowed to pass without IPSEC processing
</DL>
<P>
The format of /proc/net/ipsec_eroute is listed in <A HREF="ipsec_eroute.5.html">ipsec_eroute</A>(5).
<BR>
<A NAME="lbAE">&nbsp;</A>
<H2>EXAMPLES</H2>
<P>
<B>ipsec eroute --add --eraf inet --src 192.168.0.1/32 \</B>
<BR>
<B> --dst 192.168.2.0/24 --af inet --edst 192.168.0.2 \</B>
<BR>
<B> --spi 0x135 --proto tun</B>
<P>
sets up an
<B>eroute</B>
on a Security Gateway to protect traffic between the host
<B>192.168.0.1</B>
and the subnet
<B>192.168.2.0</B>
with
<B>24</B>
bits of subnet mask via Security Gateway
<B>192.168.0.2</B>
using the Security Association with address
<B>192.168.0.2</B>,
Security Parameters Index
<B>0x135</B>
and protocol
<B>tun</B>
(50, IPPROTO_ESP).
<P>
<B>ipsec eroute --add --eraf inet6 --src 3049:1::1/128 \</B>
<BR>
<B> --dst 3049:2::/64 --af inet6 --edst 3049:1::2 \</B>
<BR>
<B> --spi 0x145 --proto tun</B>
<P>
sets up an
<B>eroute</B>
on a Security Gateway to protect traffic between the host
<B>3049:1::1</B>
and the subnet
<B>3049:2::</B>
with
<B>64</B>
bits of subnet mask via Security Gateway
<B>3049:1::2</B>
using the Security Association with address
<B>3049:1::2</B>,
Security Parameters Index
<B>0x145</B>
and protocol
<B>tun</B>
(50, IPPROTO_ESP).
<P>
<B>ipsec eroute --replace --eraf inet --src company.com/24 \</B>
<BR>
<B> --dst <A HREF="ftp://ftp.ngo.org">ftp.ngo.org</A>/32 --said <A HREF="mailto:tun.135@gw.ngo.org">tun.135@gw.ngo.org</A></B>
<P>
replaces an
<B>eroute</B>
on a Security Gateway to protect traffic between the subnet
<B>company.com</B>
with
<B>24</B>
bits of subnet mask and the host
<B><A HREF="ftp://ftp.ngo.org">ftp.ngo.org</A></B>
via Security Gateway
<B>gw.ngo.org</B>
using the Security Association with Security Association ID
<B><A HREF="mailto:tun0x135@gw.ngo.org">tun0x135@gw.ngo.org</A></B>
<P>
<B>ipsec eroute --del --eraf inet --src company.com/24 \</B>
<BR>
<B> --dst <A HREF="http://www.ietf.org">www.ietf.org</A>/32 --said %passthrough4</B>
<P>
deletes an
<B>eroute</B>
on a Security Gateway that allowed traffic between the subnet
<B>company.com</B>
with
<B>24</B>
bits of subnet mask and the host
<B><A HREF="http://www.ietf.org">www.ietf.org</A></B>
to pass in the clear, unprocessed.
<A NAME="lbAF">&nbsp;</A>
<H2>FILES</H2>
/proc/net/ipsec_eroute, /usr/local/bin/ipsec
<A NAME="lbAG">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8), <A HREF="ipsec_tncfg.8.html">ipsec_tncfg</A>(8), <A HREF="ipsec_spi.8.html">ipsec_spi</A>(8),
<A HREF="ipsec_spigrp.8.html">ipsec_spigrp</A>(8), <A HREF="ipsec_klipsdebug.8.html">ipsec_klipsdebug</A>(8), <A HREF="ipsec_eroute.5.html">ipsec_eroute</A>(5)
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Richard Guy Briggs.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">EXAMPLES</A><DD>
<DT><A HREF="#lbAF">FILES</A><DD>
<DT><A HREF="#lbAG">SEE ALSO</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

122
doc/manpage.d/ipsec_goodmask.3.html Normal file
View File

@ -0,0 +1,122 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_GOODMASK</TITLE>
</HEAD><BODY>
<H1>IPSEC_GOODMASK</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec goodmask - is this Internet subnet mask a valid one?
<BR>
ipsec masktobits - convert Internet subnet mask to bit count
<BR>
ipsec bitstomask - convert bit count to Internet subnet mask
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>int goodmask(struct in_addr mask);</B>
<BR>
<B>int masktobits(struct in_addr mask);</B>
<BR>
<B>struct in_addr bitstomask(int n);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete;
see
<I><A HREF="ipsec_masktocount.3.html">ipsec_masktocount</A></I>(3)
for a partial replacement.
<P>
<I>Goodmask</I>
reports whether the subnet
<I>mask</I>
is a valid one,
i.e. consists of a (possibly empty) sequence of
<B>1</B>s
followed by a (possibly empty) sequence of
<B>0</B>s.
<I>Masktobits</I>
takes a (valid) subnet mask and returns the number of
<B>1</B>
bits in it.
<I>Bitstomask</I>
reverses this,
returning the subnet mask corresponding to bit count
<I>n</I>.
<P>
All masks are in network byte order.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
<I>Masktobits</I>
returns
<B>-1</B>
for an invalid mask.
<I>Bitstomask</I>
returns an all-zeros mask for a negative or out-of-range
<I>n</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The error-reporting convention of
<I>bitstomask</I>
is less than ideal;
zero is sometimes a legitimate mask.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

107
doc/manpage.d/ipsec_hostof.3.html Normal file
View File

@ -0,0 +1,107 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_SUBNETOF</TITLE>
</HEAD><BODY>
<H1>IPSEC_SUBNETOF</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec subnetof - given Internet address and subnet mask, return subnet number
<BR>
ipsec hostof - given Internet address and subnet mask, return host part
<BR>
ipsec broadcastof - given Internet address and subnet mask, return broadcast address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>struct in_addr subnetof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<BR>
<B>struct in_addr hostof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<BR>
<B>struct in_addr broadcastof(struct in_addr addr,</B>
<BR>
&nbsp;
<B>struct in_addr mask);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete; see
<I><A HREF="ipsec_networkof.3.html">ipsec_networkof</A></I>(3)
for their replacements.
<P>
<I>Subnetof</I>
takes an Internet
<I>address</I>
and a subnet
<I>mask</I>
and returns the network part of the address
(all in network byte order).
<I>Hostof</I>
similarly returns the host part, and
<I>broadcastof</I>
returns the broadcast address (all-1s convention) for the network.
<P>
These functions are provided to hide the Internet bit-munging inside
an API, in hopes of easing the eventual transition to IPv6.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAG">&nbsp;</A>
<H2>BUGS</H2>
Calling functions for this is more costly than doing it yourself.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
<DT><A HREF="#lbAG">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

137
doc/manpage.d/ipsec_ikeping.8.html Normal file
View File

@ -0,0 +1,137 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_IKEPING</TITLE>
</HEAD><BODY>
<H1>IPSEC_IKEPING</H1>
Section: Maintenance Commands (8)<BR>Updated: 23 Feb 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec ikeping - send/receive ISAKMP/IKE echo requests/replies
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>ikeping</B>
[
<B>--listen</B>
] [
<B>--verbose</B>
] [
<B>--wait </B>
time ] [
<B>--exchangenum </B>
num ] [
<B>--ikeport </B>
localport ] [
<B>--ikeaddress </B>
address ] [
<B>--inet</B>
] [
<B>--inet6</B>
] destaddr[/dstport] ...
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Ikeping</I>
sends and receives ISAKMP/IKE echo request and echo reply packets. These
packets are intended for diagnostics purposes, in a manner similar to
<I><A HREF="ping.8.html">ping</A></I>(8)
does for ICMP echo request/reply packets.
<P>
At the time of this writing, the ISAKMP echo request/reply exchange is still
an internet-draft, and is therefore completely non-standard.
<P>
<I>Ikeping</I>
will bind to the local address given by
<B>--ikeaddress</B>
and the port number given by
<B>--ikeport</B>
defaulting to the wildcard address and the ISAKMP port 500. An ISAKMP
exchange of type 244 (a private use number) is sent to each of the
address/ports listed on the command line. The exchange number may be
overridden by the
<B>--exchangenum </B>
option.
<P>
<I>Ikeping</I>
then listens for replies, printing them as they are received. Replies
are of exchange type 245 or the specified exchange number plus 1.
<I>Ikeping </I>
will keep listening until it either receives as many echo responses as it sent,
or until the timeout period (10 seconds) has been reached. Receipt of a
packet will reset the timer. The
<B>--wait</B>
option can be used to specify a different timeout period.
<P>
If the
<B>--listen</B>
option is given, then
<I>ikeping</I>
will not send any packets. Instead, it will listen for them and reply to
each request received.
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
no external files
<A NAME="lbAF">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ping.8.html">ping</A>(8), <A HREF="ipsec_pluto.8.html">ipsec_pluto</A>(8)
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Michael Richardson.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">SEE ALSO</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

232
doc/manpage.d/ipsec_initaddr.3.html Normal file
View File

@ -0,0 +1,232 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITADDR</H1>
Section: C Library Functions (3)<BR>Updated: 11 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initaddr - initialize an ip_address
<BR>
ipsec addrtypeof - get address type of an ip_address
<BR>
ipsec addrlenof - get length of address within an ip_address
<BR>
ipsec addrbytesof - get copy of address within an ip_address
<BR>
ipsec addrbytesptr - get pointer to address within an ip_address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initaddr(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>int af, ip_address *dst);</B>
<BR>
<B>int addrtypeof(const ip_address *src);</B>
<BR>
<B>size_t addrlenof(const ip_address *src);</B>
<BR>
<B>size_t addrbytesof(const ip_address *src,</B>
<BR>
&nbsp;
<B>unsigned char *dst, size_t dstlen);</B>
<BR>
<B>size_t addrbytesptr(const ip_address *src,</B>
<BR>
&nbsp;
<B>const unsigned char **dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_address</I>
to contain one of the (currently two) types of IP address.
These functions provide basic tools for creating and examining this type.
<P>
<I>Initaddr</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_address</I>
from an address
(in network byte order,
indicated by a pointer
<I>src</I>
and a length
<I>srclen</I>)
and an address family
<I>af</I>
(typically
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The length must be consistent with the address family.
<P>
<I>Addrtypeof</I>
returns the address type of an address,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Addrlenof</I>
returns the size (in bytes) of the address within an
<I>ip_address</I>,
to permit storage allocation etc.
<P>
<I>Addrbytesof</I>
copies the address within the
<I>ip_address</I>
<I>src</I>
to the buffer indicated by the pointer
<I>dst</I>
and the length
<I>dstlen</I>,
and returns the address length (in bytes).
If the address will not fit,
as many bytes as will fit are copied;
the returned length is still the full length.
It is the caller's responsibility to check the
returned value to ensure that there was enough room.
<P>
<I>Addrbytesptr</I>
sets
<I>*dst</I>
to a pointer to the internal address within the
<I>ip_address</I>,
and returns the address length (in bytes).
If
<I>dst</I>
is
<B>NULL</B>,
it just returns the address length.
The pointer points to
<B>const</B>
to discourage misuse.
<P>
<I>Initaddr</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
The functions which return
<I>size_t</I>
return
<B>0</B>
for a failure.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
An unknown address family is a fatal error for any of these functions
except
<I>addrtypeof</I>.
An address-size mismatch is a fatal error for
<I>initaddr</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
<I>Addrtypeof</I>
should probably have been named
<I>addrfamilyof</I>.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

453
doc/manpage.d/ipsec_initsaid.3.html Normal file
View File

@ -0,0 +1,453 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_TTOSA</TITLE>
</HEAD><BODY>
<H1>IPSEC_TTOSA</H1>
Section: C Library Functions (3)<BR>Updated: 26 Nov 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec ttosa, satot - convert IPsec Security Association IDs to and from text
<BR>
ipsec initsaid - initialize an SA ID
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>typedef struct {</B>
<BR>
&nbsp;
<B>ip_address dst;</B>
<BR>
&nbsp;
<B>ipsec_spi_t spi;</B>
<BR>
&nbsp;
<B>int proto;</B>
<BR>
<B>} ip_said;</B>
<P>
<B>const char *ttosa(const char *src, size_t srclen,</B>
<BR>
&nbsp;
<B>ip_said *sa);</B>
<BR>
<B>size_t satot(const ip_said *sa, int format,</B>
<BR>
&nbsp;
<B>char *dst, size_t dstlen);</B>
<BR>
<B>void initsaid(const ip_address *addr, ipsec_spi_t spi,</B>
<BR>
&nbsp;
<B>int proto, ip_said *dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Ttosa</I>
converts an ASCII Security Association (SA) specifier into an
<B>ip_said</B>
structure (containing
a destination-host address
in network byte order,
an SPI number in network byte order, and
a protocol code).
<I>Satot</I>
does the reverse conversion, back to a text SA specifier.
<I>Initsaid</I>
initializes an
<B>ip_said</B>
from separate items of information.
<P>
An SA is specified in text with a mail-like syntax, e.g.
<B><A HREF="mailto:esp.5a7@1.2.3.4">esp.5a7@1.2.3.4</A></B>.
An SA specifier contains
a protocol prefix (currently
<B>ah</B>,
<B>esp</B>,
<B>tun</B>,
<B>comp</B>,
or
<B>int</B>),
a single character indicating the address family
(<B>.</B>
for IPv4,
<B>:</B>
for IPv6),
an unsigned integer SPI number in hexadecimal (with no
<B>0x</B>
prefix),
and an IP address.
The IP address can be any form accepted by
<I><A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A></I>(3),
e.g. dotted-decimal IPv4 address,
colon-hex IPv6 address,
or DNS name.
<P>
As a special case, the SA specifier
<B>%passthrough4</B>
or
<B>%passthrough6</B>
signifies the special SA used to indicate that packets should be
passed through unaltered.
(At present, these are synonyms for
<B><A HREF="mailto:tun.0@0.0.0.0">tun.0@0.0.0.0</A></B>
and
<B>tun:0@::</B>
respectively,
but that is subject to change without notice.)
<B>%passthrough</B>
is a historical synonym for
<B>%passthrough4</B>.
These forms are known to both
<I>ttosa</I>
and
<I>satot</I>,
so the internal representation is never visible.
<P>
Similarly, the SA specifiers
<B>%pass</B>,
<B>%drop</B>,
<B>%reject</B>,
<B>%hold</B>,
<B>%trap</B>,
and
<B>%trapsubnet</B>
signify special ``magic'' SAs used to indicate that packets should be
passed, dropped, rejected (dropped with ICMP notification),
held,
and trapped (sent up to
<I><A HREF="ipsec_pluto.8.html">ipsec_pluto</A></I>(8),
with either of two forms of
<B>%hold</B>
automatically installed)
respectively.
These forms too are known to both routines,
so the internal representation of the magic SAs should never be visible.
<P>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file supplies the
<B>ip_said</B>
structure, as well as a data type
<B>ipsec_spi_t</B>
which is an unsigned 32-bit integer.
(There is no consistency between kernel and user on what such a type
is called, hence the header hides the differences.)
<P>
The protocol code uses the same numbers that IP does.
For user convenience, given the difficulty in acquiring the exact set of
protocol names used by the kernel,
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
defines the names
<B>SA_ESP</B>,
<B>SA_AH</B>,
<B>SA_IPIP</B>,
and
<B>SA_COMP</B>
to have the same values as the kernel names
<B>IPPROTO_ESP</B>,
<B>IPPROTO_AH</B>,
<B>IPPROTO_IPIP</B>,
and
<B>IPPROTO_COMP</B>.
<P>
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
also defines
<B>SA_INT</B>
to have the value
<B>61</B>
(reserved by IANA for ``any host internal protocol'')
and
<B>SPI_PASS</B>,
<B>SPI_DROP</B>,
<B>SPI_REJECT</B>,
<B>SPI_HOLD</B>,
and
<B>SPI_TRAP</B>
to have the values 256-260 (in <I>host</I> byte order) respectively.
These are used in constructing the magic SAs
(which always have address
<B>0.0.0.0</B>).
<P>
If
<I>satot</I>
encounters an unknown protocol code, e.g. 77,
it yields output using a prefix
showing the code numerically, e.g. ``unk77''.
This form is
<I>not</I>
recognized by
<I>ttosa</I>.
<P>
The
<I>srclen</I>
parameter of
<I>ttosa</I>
specifies the length of the string pointed to by
<I>src</I>;
it is an error for there to be anything else
(e.g., a terminating NUL) within that length.
As a convenience for cases where an entire NUL-terminated string is
to be converted,
a
<I>srclen</I>
value of
<B>0</B>
is taken to mean
<B>strlen(src)</B>.
<P>
The
<I>dstlen</I>
parameter of
<I>satot</I>
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file defines a constant,
<B>SATOT_BUF</B>,
which is the size of a buffer just large enough for worst-case results.
<P>
The
<I>format</I>
parameter of
<I>satot</I>
specifies what format is to be used for the conversion.
The value
<B>0</B>
(not the ASCII character
<B>'0'</B>,
but a zero value)
specifies a reasonable default
(currently
lowercase protocol prefix, lowercase hexadecimal SPI,
dotted-decimal or colon-hex address).
The value
<B>'f'</B>
is similar except that the SPI is padded with
<B>0</B>s
to a fixed 32-bit width, to ease aligning displayed tables.
<P>
<I>Ttosa</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<I>Satot</I>
returns
<B>0</B>
for a failure, and otherwise
always returns the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
<P>
There is also, temporarily, support for some obsolete
forms of SA specifier which lack the address-family indicator.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec_ttoul.3.html">ipsec_ttoul</A>(3), <A HREF="ipsec_ttoaddr.3.html">ipsec_ttoaddr</A>(3), <A HREF="ipsec_samesaid.3.html">ipsec_samesaid</A>(3), <A HREF="inet.3.html">inet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>ttosa</I>
are:
empty input;
input too small to be a legal SA specifier;
no
<B>@</B>
in input;
unknown protocol prefix;
conversion error in
<I>ttoul</I>
or
<I>ttoaddr</I>.
<P>
Fatal errors in
<I>satot</I>
are:
unknown format.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The restriction of text-to-binary error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The text-to-binary error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
A good way to make it clearer is to write something like:
<P>
<DL COMPACT><DT><DD>
<PRE>
<B>const char *error;</B>
<B>error = ttosa( /* ... */ );</B>
<B>if (error != NULL) {</B>
<B> /* something went wrong */</B>
</PRE>
</DL>
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

238
doc/manpage.d/ipsec_initsubnet.3.html Normal file
View File

@ -0,0 +1,238 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITSUBNET</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITSUBNET</H1>
Section: C Library Functions (3)<BR>Updated: 12 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initsubnet - initialize an ip_subnet
<BR>
ipsec addrtosubnet - initialize a singleton ip_subnet
<BR>
ipsec subnettypeof - get address type of an ip_subnet
<BR>
ipsec masktocount - convert subnet mask to bit count
<BR>
ipsec networkof - get base address of an ip_subnet
<BR>
ipsec maskof - get subnet mask of an ip_subnet
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initsubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>int maskbits, int clash, ip_subnet *dst);</B>
<BR>
<B>const char *addrtosubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>ip_subnet *dst);</B>
<P>
<B>int subnettypeof(const ip_subnet *src);</B>
<BR>
<B>int masktocount(const ip_address *src);</B>
<BR>
<B>void networkof(const ip_subnet *src, ip_address *dst);</B>
<BR>
<B>void maskof(const ip_subnet *src, ip_address *dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_subnet</I>
to contain a description of an IP subnet
(base address plus mask).
These functions provide basic tools for creating and examining this type.
<P>
<I>Initsubnet</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_subnet</I>
from a base address and
a count of mask bits.
The
<I>clash</I>
parameter specifies what to do if the base address includes
<B>1</B>
bits outside the prefix specified by the mask
(that is, in the ``host number'' part of the address):
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT>'0'<DD>
zero out host-number bits
<DT>'x'<DD>
non-zero host-number bits are an error
</DL>
</DL>
<P>
<I>Initsubnet</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
<I>Addrtosubnet</I>
initializes an
<I>ip_subnet</I>
variable
<I>*dst</I>
to a ``singleton subnet'' containing the single address
<I>*addr</I>.
It returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure.
<P>
<I>Subnettypeof</I>
returns the address type of a subnet,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Masktocount</I>
converts a subnet mask, expressed as an address, to a bit count
suitable for use with
<I>initsubnet</I>.
It returns
<B>-1</B>
for error; see DIAGNOSTICS.
<P>
<I>Networkof</I>
fills in
<I>*dst</I>
with the base address of subnet
<I>src</I>.
<P>
<I>Maskof</I>
fills in
<I>*dst</I>
with the subnet mask of subnet
<I>src</I>,
expressed as an address.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttosubnet.3.html">ipsec_ttosubnet</A>(3), <A HREF="ipsec_rangetosubnet.3.html">ipsec_rangetosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>initsubnet</I>
are:
unknown address family;
unknown
<I>clash</I>
value;
impossible mask bit count;
non-zero host-number bits and
<I>clash</I>
is
<B>'x'</B>.
Fatal errors in
<I>addrtosubnet</I>
are:
unknown address family.
Fatal errors in
<I>masktocount</I>
are:
unknown address family;
mask bits not contiguous.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

166
doc/manpage.d/ipsec_isanyaddr.3.html Normal file
View File

@ -0,0 +1,166 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 8 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec anyaddr - get &quot;any&quot; address
<BR>
ipsec isanyaddr - test address for equality to &quot;any&quot; address
<BR>
ipsec unspecaddr - get &quot;unspecified&quot; address
<BR>
ipsec isunspecaddr - test address for equality to &quot;unspecified&quot; address
<BR>
ipsec loopbackaddr - get loopback address
<BR>
ipsec isloopbackaddr - test address for equality to loopback address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *anyaddr(int af, ip_address *dst);</B>
<BR>
<B>int isanyaddr(const ip_address *src);</B>
<BR>
<B>const char *unspecaddr(int af, ip_address *dst);</B>
<BR>
<B>int isunspecaddr(const ip_address *src);</B>
<BR>
<B>const char *loopbackaddr(int af, ip_address *dst);</B>
<BR>
<B>int isloopbackaddr(const ip_address *src);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions fill in, and test for, special values of the
<I>ip_address</I>
type.
<P>
<I>Anyaddr</I>
fills in the destination
<I>*dst</I>
with the ``any'' address of address family
<I>af</I>
(normally
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The IPv4 ``any'' address is the one embodied in the old
<B>INADDR_ANY</B>
macro.
<P>
<I>Isanyaddr</I>
returns
<B>1</B>
if the
<I>src</I>
address equals the ``any'' address,
and
<B>0</B>
otherwise.
<P>
Similarly,
<I>unspecaddr</I>
supplies, and
<I>isunspecaddr</I>
tests for,
the ``unspecified'' address,
which may be the same as the ``any'' address.
<P>
Similarly,
<I>loopbackaddr</I>
supplies, and
<I>islookbackaddr</I>
tests for,
the loopback address.
<P>
<I>Anyaddr</I>,
<I>unspecaddr</I>,
and
<I>loopbackaddr</I>
return
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_addrtot.3.html">ipsec_addrtot</A>(3), <A HREF="ipsec_sameaddr.3.html">ipsec_sameaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in the address-supplying functions are:
unknown address family.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

166
doc/manpage.d/ipsec_isloopbackaddr.3.html Normal file
View File

@ -0,0 +1,166 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 8 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec anyaddr - get &quot;any&quot; address
<BR>
ipsec isanyaddr - test address for equality to &quot;any&quot; address
<BR>
ipsec unspecaddr - get &quot;unspecified&quot; address
<BR>
ipsec isunspecaddr - test address for equality to &quot;unspecified&quot; address
<BR>
ipsec loopbackaddr - get loopback address
<BR>
ipsec isloopbackaddr - test address for equality to loopback address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *anyaddr(int af, ip_address *dst);</B>
<BR>
<B>int isanyaddr(const ip_address *src);</B>
<BR>
<B>const char *unspecaddr(int af, ip_address *dst);</B>
<BR>
<B>int isunspecaddr(const ip_address *src);</B>
<BR>
<B>const char *loopbackaddr(int af, ip_address *dst);</B>
<BR>
<B>int isloopbackaddr(const ip_address *src);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions fill in, and test for, special values of the
<I>ip_address</I>
type.
<P>
<I>Anyaddr</I>
fills in the destination
<I>*dst</I>
with the ``any'' address of address family
<I>af</I>
(normally
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The IPv4 ``any'' address is the one embodied in the old
<B>INADDR_ANY</B>
macro.
<P>
<I>Isanyaddr</I>
returns
<B>1</B>
if the
<I>src</I>
address equals the ``any'' address,
and
<B>0</B>
otherwise.
<P>
Similarly,
<I>unspecaddr</I>
supplies, and
<I>isunspecaddr</I>
tests for,
the ``unspecified'' address,
which may be the same as the ``any'' address.
<P>
Similarly,
<I>loopbackaddr</I>
supplies, and
<I>islookbackaddr</I>
tests for,
the loopback address.
<P>
<I>Anyaddr</I>,
<I>unspecaddr</I>,
and
<I>loopbackaddr</I>
return
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_addrtot.3.html">ipsec_addrtot</A>(3), <A HREF="ipsec_sameaddr.3.html">ipsec_sameaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in the address-supplying functions are:
unknown address family.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

166
doc/manpage.d/ipsec_isunspecaddr.3.html Normal file
View File

@ -0,0 +1,166 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 8 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec anyaddr - get &quot;any&quot; address
<BR>
ipsec isanyaddr - test address for equality to &quot;any&quot; address
<BR>
ipsec unspecaddr - get &quot;unspecified&quot; address
<BR>
ipsec isunspecaddr - test address for equality to &quot;unspecified&quot; address
<BR>
ipsec loopbackaddr - get loopback address
<BR>
ipsec isloopbackaddr - test address for equality to loopback address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *anyaddr(int af, ip_address *dst);</B>
<BR>
<B>int isanyaddr(const ip_address *src);</B>
<BR>
<B>const char *unspecaddr(int af, ip_address *dst);</B>
<BR>
<B>int isunspecaddr(const ip_address *src);</B>
<BR>
<B>const char *loopbackaddr(int af, ip_address *dst);</B>
<BR>
<B>int isloopbackaddr(const ip_address *src);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions fill in, and test for, special values of the
<I>ip_address</I>
type.
<P>
<I>Anyaddr</I>
fills in the destination
<I>*dst</I>
with the ``any'' address of address family
<I>af</I>
(normally
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The IPv4 ``any'' address is the one embodied in the old
<B>INADDR_ANY</B>
macro.
<P>
<I>Isanyaddr</I>
returns
<B>1</B>
if the
<I>src</I>
address equals the ``any'' address,
and
<B>0</B>
otherwise.
<P>
Similarly,
<I>unspecaddr</I>
supplies, and
<I>isunspecaddr</I>
tests for,
the ``unspecified'' address,
which may be the same as the ``any'' address.
<P>
Similarly,
<I>loopbackaddr</I>
supplies, and
<I>islookbackaddr</I>
tests for,
the loopback address.
<P>
<I>Anyaddr</I>,
<I>unspecaddr</I>,
and
<I>loopbackaddr</I>
return
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_addrtot.3.html">ipsec_addrtot</A>(3), <A HREF="ipsec_sameaddr.3.html">ipsec_sameaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in the address-supplying functions are:
unknown address family.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:17 GMT, November 11, 2003
</BODY>
</HTML>

174
doc/manpage.d/ipsec_keyblobtoid.3.html Normal file
View File

@ -0,0 +1,174 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_KEYBLOBTOID</TITLE>
</HEAD><BODY>
<H1>IPSEC_KEYBLOBTOID</H1>
Section: C Library Functions (3)<BR>Updated: 25 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec keyblobtoid, splitkeytoid - generate key IDs from RSA keys
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>size_t keyblobtoid(const unsigned char *blob,</B>
<BR>
&nbsp;
<B>size_t bloblen, char *dst, size_t dstlen);</B>
<BR>
<B>size_t splitkeytoid(const unsigned char *e, size_t elen,</B>
<BR>
&nbsp;
<B>const unsigned char *m, size_t mlen, char *dst,</B>
<BR>
&nbsp;
<B>size_t dstlen);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Keyblobtoid</I>
and
<I>splitkeytoid</I>
generate
key IDs
from RSA keys,
for use in messages and reporting,
writing the result to
<I>dst</I>.
A
<I>key ID</I>
is a short ASCII string identifying a key;
currently it is just the first nine characters of the base64
encoding of the RFC 2537/3110 ``byte blob'' representation of the key.
(Beware that no finite key ID can be collision-proof:
there is always some small chance of two random keys having the
same ID.)
<P>
<I>Keyblobtoid</I>
generates a key ID from a key which is already in the form of an
RFC 2537/3110 binary key
<I>blob</I>
(encoded exponent length, exponent, modulus).
<P>
<I>Splitkeytoid</I>
generates a key ID from a key given in the form of a separate
(binary) exponent
<I>e</I>
and modulus
<I>m</I>.
<P>
The
<I>dstlen</I>
parameter of either
specifies the size of the
<I>dst</I>
parameter;
under no circumstances are more than
<I>dstlen</I>
bytes written to
<I>dst</I>.
A result which will not fit is truncated.
<I>Dstlen</I>
can be zero, in which case
<I>dst</I>
need not be valid and no result is written,
but the return value is unaffected;
in all other cases, the (possibly truncated) result is NUL-terminated.
The
<I>freeswan.h</I>
header file defines a constant
<B>KEYID_BUF</B>
which is the size of a buffer large enough for worst-case results.
<P>
Both functions return
<B>0</B>
for a failure, and otherwise
always return the size of buffer which would
be needed to
accommodate the full conversion result, including terminating NUL;
it is the caller's responsibility to check this against the size of
the provided buffer to determine whether truncation has occurred.
With keys generated by
<I><A HREF="ipsec_rsasigkey.3.html">ipsec_rsasigkey</A></I>(3),
the first two base64 digits are always the same,
and the third carries only about one bit of information.
It's worse with keys using longer fixed exponents,
e.g. the 24-bit exponent that's common in X.509 certificates.
However, being able to relate key IDs to the full
base64 text form of keys by eye is sufficiently useful that this
waste of space seems justifiable.
The choice of nine digits is a compromise between bulk and
probability of collision.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
RFC 3110,
<I>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</I>,
Eastlake, 2001
(superseding the older but better-known RFC 2537).
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors are:
key too short to supply enough bits to construct a complete key ID
(almost certainly indicating a garbage key);
exponent too long for its length to be representable.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

229
doc/manpage.d/ipsec_klipsdebug.5.html Normal file
View File

@ -0,0 +1,229 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_KLIPSDEBUG</TITLE>
</HEAD><BODY>
<H1>IPSEC_KLIPSDEBUG</H1>
Section: File Formats (5)<BR>Updated: 26 Jun 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec_klipsdebug - list KLIPS (kernel IPSEC support) debug features and level
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>klipsdebug</B>
<P>
<B>cat</B>
<B>/proc/net/ipsec_klipsdebug</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>/proc/net/ipsec_klipsdebug</I>
lists flags that control various parts of the debugging output of Klips
(the kernel portion of FreeS/WAN IPSEC).
At this point it is a read-only file.
<P>
A table entry consists of:
<DL COMPACT>
<DT>+<DD>
a KLIPS debug variable
<DT>+<DD>
a '=' separator for visual and automated parsing between the variable
name and its current value
<DT>+<DD>
hexadecimal bitmap of variable's flags.
</DL>
<P>
The variable names roughly describe the scope of the debugging variable.
Currently, no flags are documented or individually accessible yet except
tunnel-xmit.
<P>
The variable names are:
<DL COMPACT>
<DT><B>tunnel</B>
<DD>
tunnelling code
<DT><B>netlink</B>
<DD>
userspace communication code (obsolete)
<DT><B>xform</B>
<DD>
transform selection and manipulation code
<DT><B>eroute</B>
<DD>
eroute table manipulation code
<DT><B>spi</B>
<DD>
SA table manipulation code
<DT><B>radij</B>
<DD>
radij tree manipulation code
<DT><B>esp</B>
<DD>
encryptions transforms code
<DT><B>ah</B>
<DD>
authentication transforms code
<DT><B>rcv</B>
<DD>
receive code
<DT><B>ipcomp</B>
<DD>
ip compression transforms code
<DT><B>verbose</B>
<DD>
give even more information, beware this will probably trample the 4k kernel printk buffer giving inaccurate output
</DL>
<P>
All KLIPS debug output appears as
<B>kernel.info</B>
messages to
<I><A HREF="syslogd.8.html">syslogd</A></I>(8).
Most systems are set up
to log these messages to
<I>/var/log/messages</I>.
<P>
<A NAME="lbAE">&nbsp;</A>
<H2>EXAMPLES</H2>
<P>
<B>debug_tunnel=00000010.</B>
<BR>
<B>debug_netlink=00000000.</B>
<BR>
<B>debug_xform=00000000.</B>
<BR>
<B>debug_eroute=00000000.</B>
<BR>
<B>debug_spi=00000000.</B>
<BR>
<B>debug_radij=00000000.</B>
<BR>
<B>debug_esp=00000000.</B>
<BR>
<B>debug_ah=00000000.</B>
<BR>
<B>debug_rcv=00000000.</B>
<BR>
<B>debug_pfkey=ffffffff.</B>
<P>
means that one
<B>tunnel</B>
flag has been set (tunnel-xmit),
full
<B>pfkey</B>
sockets debugging has been set and everything else is not set.
<P>
<A NAME="lbAF">&nbsp;</A>
<H2>FILES</H2>
/proc/net/ipsec_klipsdebug, /usr/local/bin/ipsec
<A NAME="lbAG">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8), <A HREF="ipsec_tncfg.8.html">ipsec_tncfg</A>(8), <A HREF="ipsec_eroute.8.html">ipsec_eroute</A>(8),
<A HREF="ipsec_spi.8.html">ipsec_spi</A>(8), <A HREF="ipsec_spigrp.8.html">ipsec_spigrp</A>(8), <A HREF="ipsec_klipsdebug.5.html">ipsec_klipsdebug</A>(5), <A HREF="ipsec_version.5.html">ipsec_version</A>(5),
<A HREF="ipsec_pf_key.5.html">ipsec_pf_key</A>(5)
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Richard Guy Briggs.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">EXAMPLES</A><DD>
<DT><A HREF="#lbAF">FILES</A><DD>
<DT><A HREF="#lbAG">SEE ALSO</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

264
doc/manpage.d/ipsec_klipsdebug.8.html Normal file
View File

@ -0,0 +1,264 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_KLIPSDEBUG</TITLE>
</HEAD><BODY>
<H1>IPSEC_KLIPSDEBUG</H1>
Section: Maintenance Commands (8)<BR>Updated: 21 Jun 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec klipsdebug - set KLIPS (kernel IPSEC support) debug features and level
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>klipsdebug</B>
<P>
<B>ipsec</B>
<B>klipsdebug</B>
<B>--set</B>
flagname
<P>
<B>ipsec</B>
<B>klipsdebug</B>
<B>--clear</B>
flagname
<P>
<B>ipsec</B>
<B>klipsdebug</B>
<B>--all</B>
<P>
<B>ipsec</B>
<B>klipsdebug</B>
<B>--none</B>
<P>
<B>ipsec</B>
<B>klipsdebug</B>
<B>--help</B>
<P>
<B>ipsec</B>
<B>klipsdebug</B>
<B>--version</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Klipsdebug</I>
sets and clears flags that control
various parts of the debugging output of Klips
(the kernel portion of FreeS/WAN IPSEC).
The form with no additional arguments lists the present contents of
/proc/net/ipsec_klipsdebug.
The
<B>--set</B>
form turns the specified flag on,
while the
<B>--clear</B>
form turns the specified flag off.
The
<B>--all</B>
form
turns all flags on except verbose, while the
<B>--none</B>
form turns all flags off.
<P>
The current flag names are:
<DL COMPACT>
<DT><B>tunnel</B>
<DD>
tunnelling code
<DT><B>tunnel-xmit</B>
<DD>
tunnelling transmit only code
<DT><B>pfkey</B>
<DD>
userspace communication code
<DT><B>xform</B>
<DD>
transform selection and manipulation code
<DT><B>eroute</B>
<DD>
eroute table manipulation code
<DT><B>spi</B>
<DD>
SA table manipulation code
<DT><B>radij</B>
<DD>
radij tree manipulation code
<DT><B>esp</B>
<DD>
encryptions transforms code
<DT><B>ah</B>
<DD>
authentication transforms code
<B>rcv</B>
receive code
<DT><B>ipcomp</B>
<DD>
ip compression transforms code
<DT><B>verbose</B>
<DD>
give even more information, BEWARE:
a)this will print authentication and encryption keys in the logs
b)this will probably trample the 4k kernel printk buffer giving inaccurate output
</DL>
<P>
All Klips debug output appears as
<B>kernel.info</B>
messages to
<I><A HREF="syslogd.8.html">syslogd</A></I>(8).
Most systems are set up
to log these messages to
<I>/var/log/messages</I>.
Beware that
<B>klipsdebug</B>
<B>--all</B>
produces a lot of output and the log file will grow quickly.
<P>
The file format for /proc/net/ipsec_klipsdebug is discussed in
<A HREF="ipsec_klipsdebug.5.html">ipsec_klipsdebug</A>(5).
<A NAME="lbAE">&nbsp;</A>
<H2>EXAMPLES</H2>
<DL COMPACT>
<DT><B>klipsdebug --all</B>
<DD>
turns on all KLIPS debugging except verbose.
<DT><B>klipsdebug --clear tunnel</B>
<DD>
turns off only the
<B>tunnel</B>
debugging messages.
</DL>
<P>
<A NAME="lbAF">&nbsp;</A>
<H2>FILES</H2>
/proc/net/ipsec_klipsdebug, /usr/local/bin/ipsec
<A NAME="lbAG">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8), <A HREF="ipsec_tncfg.8.html">ipsec_tncfg</A>(8), <A HREF="ipsec_eroute.8.html">ipsec_eroute</A>(8),
<A HREF="ipsec_spi.8.html">ipsec_spi</A>(8), <A HREF="ipsec_spigrp.8.html">ipsec_spigrp</A>(8), <A HREF="ipsec_klipsdebug.5.html">ipsec_klipsdebug</A>(5)
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Richard Guy Briggs.
<A NAME="lbAI">&nbsp;</A>
<H2>BUGS</H2>
It really ought to be possible to set or unset selective combinations
of flags.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">EXAMPLES</A><DD>
<DT><A HREF="#lbAF">FILES</A><DD>
<DT><A HREF="#lbAG">SEE ALSO</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
<DT><A HREF="#lbAI">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

76
doc/manpage.d/ipsec_look.8.html Normal file
View File

@ -0,0 +1,76 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of look</TITLE>
</HEAD><BODY>
<H1>look</H1>
Section: Maintenance Commands (8)<BR>Updated: 25 Apr 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec look - get a quick summary of FreeS/WAN status
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<I>look</I>
is used to get a quick overview of what the status of FreeSWAN is.
It is equivalent to:
&nbsp;&nbsp;&nbsp;ipsec eroute
<P>
&nbsp;&nbsp;&nbsp;ipsec spigrp
<P>
&nbsp;&nbsp;&nbsp;ipsec tncfg
<P>
&nbsp;&nbsp;&nbsp;ipsec spi
<P>
&nbsp;&nbsp;&nbsp;netstat -rn
<P>
<P>
However a bit of processing is done to combine the outputs.
<A NAME="lbAD">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_tncfg.8.html">ipsec_tncfg</A>(8), <A HREF="ipsec_spi.8.html">ipsec_spi</A>(8), <A HREF="ipsec_spigrp.8.html">ipsec_spigrp</A>(8), <A HREF="ipsec_eroute.5.html">ipsec_eroute</A>(5),
<A HREF="netstat.8.html">netstat</A>(8).
<A NAME="lbAE">&nbsp;</A>
<H2>HISTORY</H2>
Man page written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson. Original program written by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">SEE ALSO</A><DD>
<DT><A HREF="#lbAE">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

166
doc/manpage.d/ipsec_loopbackaddr.3.html Normal file
View File

@ -0,0 +1,166 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_ANYADDR</TITLE>
</HEAD><BODY>
<H1>IPSEC_ANYADDR</H1>
Section: C Library Functions (3)<BR>Updated: 8 Sept 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec anyaddr - get &quot;any&quot; address
<BR>
ipsec isanyaddr - test address for equality to &quot;any&quot; address
<BR>
ipsec unspecaddr - get &quot;unspecified&quot; address
<BR>
ipsec isunspecaddr - test address for equality to &quot;unspecified&quot; address
<BR>
ipsec loopbackaddr - get loopback address
<BR>
ipsec isloopbackaddr - test address for equality to loopback address
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *anyaddr(int af, ip_address *dst);</B>
<BR>
<B>int isanyaddr(const ip_address *src);</B>
<BR>
<B>const char *unspecaddr(int af, ip_address *dst);</B>
<BR>
<B>int isunspecaddr(const ip_address *src);</B>
<BR>
<B>const char *loopbackaddr(int af, ip_address *dst);</B>
<BR>
<B>int isloopbackaddr(const ip_address *src);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions fill in, and test for, special values of the
<I>ip_address</I>
type.
<P>
<I>Anyaddr</I>
fills in the destination
<I>*dst</I>
with the ``any'' address of address family
<I>af</I>
(normally
<B>AF_INET</B>
or
<B>AF_INET6</B>).
The IPv4 ``any'' address is the one embodied in the old
<B>INADDR_ANY</B>
macro.
<P>
<I>Isanyaddr</I>
returns
<B>1</B>
if the
<I>src</I>
address equals the ``any'' address,
and
<B>0</B>
otherwise.
<P>
Similarly,
<I>unspecaddr</I>
supplies, and
<I>isunspecaddr</I>
tests for,
the ``unspecified'' address,
which may be the same as the ``any'' address.
<P>
Similarly,
<I>loopbackaddr</I>
supplies, and
<I>islookbackaddr</I>
tests for,
the loopback address.
<P>
<I>Anyaddr</I>,
<I>unspecaddr</I>,
and
<I>loopbackaddr</I>
return
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_addrtot.3.html">ipsec_addrtot</A>(3), <A HREF="ipsec_sameaddr.3.html">ipsec_sameaddr</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in the address-supplying functions are:
unknown address family.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

400
doc/manpage.d/ipsec_lwdnsq.8.html Normal file
View File

@ -0,0 +1,400 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC LWDNSQ</TITLE>
</HEAD><BODY>
<H1>IPSEC LWDNSQ</H1>
Section:  (8)<BR>Updated: <BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
lwdnsq - lookup items in DNS to help pluto (and others)
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<P>
<PRE>
<B>ipsec lwdnsq</B> lwdnsq [<B>--prompt</B>] [<B>--serial</B>]
</PRE>
<P>
<PRE>
<B>ipsec lwdnsq</B> lwdnsq [<B>--help</B>]
</PRE>
<P>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<P>
<P>
The <B>ipsec lwdnsq</B> is a helper program that does DNS lookups for other programs. It implements an asynchronous interface on stdin/stdout, with an ASCII driven command language.
<P>
<P>
If stdin is a tty or if the <B>--prompt</B> option is given, then it issues a prompt to the user. Otherwise, it is silent, except for results.
<P>
<P>
The program will accept multiple queries concurrently, with each result being marked with the ID provided on the output. The IDs are strings.
<P>
<P>
If the <B>--serial</B> option is given, then the program will not attempt to execute concurrent queries, but will serialize all input and output.
<P>
<A NAME="lbAE">&nbsp;</A>
<H2>QUERY LANGUAGE</H2>
<P>
<P>
There are eleven command that the program understands. This is to lookup different types of records in both the forward and reverse maps. Every query includes a queryid, which is returned in the output, on every single line to identify the transaction.
<P>
<A NAME="lbAF">&nbsp;</A>
<H3>KEY queryid FQDN</H3>
<P>
<P>
This request looks up the KEY resource record for the given <B>FQDN.</B>.
<P>
<A NAME="lbAG">&nbsp;</A>
<H3>KEY4 queryid A.B.C.D</H3>
<P>
<P>
This request looks up the KEY resource record found in the reverse map for the IP version 4 address <B>A.B.C.D</B>, i.e. it looks up D.C.B.A.in-addr.arpa.
<P>
<A NAME="lbAH">&nbsp;</A>
<H3>KEY6 queryid A:B::C:D</H3>
<P>
<P>
This request looks up the KEY resource record found in the reverse map for the IPv6 address <B>A:B::C:D</B>, i.e. it looks the 32-nibble long entry in ip6.arpa (and ip6.int).
<P>
<A NAME="lbAI">&nbsp;</A>
<H3>TXT4 queryid A.B.C.D</H3>
<P>
<P>
This request looks up the TXT resource record found in the reverse map for the IP version 4 address <B>A.B.C.D</B>, i.e. it looks up D.C.B.A.in-addr.arpa.
<P>
<A NAME="lbAJ">&nbsp;</A>
<H3>TXT6 queryid A:B::C:D</H3>
<P>
<P>
This request looks up the TXT resource record found in the reverse map for the IPv6 address <B>A:B::C:D</B>, i.e. it looks the 32-nibble long entry in ip6.arpa (and ip6.int).
<P>
<A NAME="lbAK">&nbsp;</A>
<H3>KEY queryid FQDN</H3>
<P>
<P>
This request looks up the IPSECKEY resource record for the given <B>FQDN.</B>. See note about IPSECKEY processing, below.
<P>
<A NAME="lbAL">&nbsp;</A>
<H3>IPSECKEY4 queryid A.B.C.D</H3>
<P>
<P>
This request looks up the IPSECKEY resource record found in the reverse map for the IP version 4 address <B>A.B.C.D</B>, i.e. it looks up D.C.B.A.in-addr.arpa. See special note about IPSECKEY processing, below.
<P>
<A NAME="lbAM">&nbsp;</A>
<H3>IPSECKEY6 queryid A:B::C:D</H3>
<P>
<P>
This request looks up the IPSECKEY resource record found in the reverse map for the IPv6 address <B>A:B::C:D</B>, i.e. it looks the 32-nibble long entry in ip6.arpa (and ip6.int). See special note about IPSECKEY processing, below.
<P>
<A NAME="lbAN">&nbsp;</A>
<H3>OE4 queryid A.B.C.D</H3>
<P>
<P>
This request looks an appropriate record for Opportunistic Encryption for the given IP address. This attempts to look for the delegation record. This may be one of IPSECKEY, KEY, or TXT record. Unless configured otherwise, (see OE4 Directives, below), then a query type of ANY will be used to retrieve all relevant records, and all will be returned.
<P>
<A NAME="lbAO">&nbsp;</A>
<H3>OE6 queryid A:B::C:D</H3>
<P>
<P>
This request looks an appropriate record for Opportunistic Encryption for the given IPv6 address. This attempts to look for the delegation record. This may be one of IPSECKEY, KEY, or TXT record. Unless configured otherwise, (see OE Directives, below), then a query type of ALL will be used to retrieve all relevant records, and all will be returned. i.e. it looks the 32-nibble long entry in ip6.arpa (and ip6.int).
<P>
<A NAME="lbAP">&nbsp;</A>
<H3>A queryid FQDN</H3>
<P>
<P>
This request looks up the A (IPv4) resource record for the given <B>FQDN.</B>.
<P>
<A NAME="lbAQ">&nbsp;</A>
<H3>AAAA queryid FQDN</H3>
<P>
<P>
This request looks up the AAAA (IPv6) resource record for the given <B>FQDN.</B>.
<P>
<A NAME="lbAR">&nbsp;</A>
<H2>REPLIES TO QUERIES</H2>
<P>
<P>
All replies from the queries are in the following format:
<P>
<PRE>
&lt;ID&gt; &lt;TIME&gt; &lt;TTL&gt; &lt;TYPE&gt; &lt;TYPE-SPECIFIC&gt; \n
</PRE>
<BR>&nbsp;&nbsp;
<P>
<DL COMPACT>
<DT><I>ID</I><DD>
this is the <B>queryid</B> value that was provided in the query. It is repeated on every line to permit the replies to be properly associated with the query. When the response is not ascribable to particular query (such as for a mis-formed query), then the query ID &quot;0&quot; will be used.
<P>
<DT><I>TIME</I><DD>
this is the current time in seconds since epoch.
<P>
<DT><I>TTL</I><DD>
for answers which have a time to live, this is the current value. The answer is valid for this number of seconds. If there is no useful value here, then the number 0 is used.
<P>
<DT><I>TYPE</I><DD>
This is the type of the record that is being returned. The types are described in the next section. The TYPE specific data that follows is specific to the type.
<BR>&nbsp;
<P>
</DL>
<P>
The replies are limited to 4096 bytes, a value defined as <B>LWDNSQ_RESULT_LEN_MAX</B>. This is defined in <I>freeswan.h</I>.
<P>
<P>
All of the replies which include resource records use the standard presentation format (with no line feeds or carriage returns) in their answer.
<P>
<A NAME="lbAS">&nbsp;</A>
<H3>START</H3>
<P>
<P>
This reply indicates that a query has been received and has been started. It serves as an anchor point for timing, as well as an acknowledgement.
<P>
<A NAME="lbAT">&nbsp;</A>
<H3>DONE</H3>
<P>
<P>
This reply indicates that a query is entirely over, and no further information from this query will be sent.
<P>
<A NAME="lbAU">&nbsp;</A>
<H3>RETRY</H3>
<P>
<P>
This reply indicates that a query is entirely over, but that no data was found. The records may exist, but appropriate servers could not be reached.
<P>
<A NAME="lbAV">&nbsp;</A>
<H3>FATAL</H3>
<P>
<P>
This reply indicates that a query is entirely over, and that no data of the type requested could be found. There were no timeouts, and all servers were available and confirmed non-existances. There may be NXT records returned prior to this.
<P>
<A NAME="lbAW">&nbsp;</A>
<H3>CNAME</H3>
<P>
<P>
This is an interim reply, and indicates that a CNAME was found (and followed) while performing the query. The value of the CNAME is present in the type specific section.
<P>
<A NAME="lbAX">&nbsp;</A>
<H3>CNAMEFROM</H3>
<P>
<P>
This is an interim reply, and indicates that a CNAME was found. The original name that was queries for was not the canonical name, and this reply indicates the name that was actually followed.
<P>
<A NAME="lbAY">&nbsp;</A>
<H3>NAME</H3>
<P>
<P>
This is an interim reply. The original name that was queries for was not the canonical name. This reply indicates the canonical name.
<P>
<A NAME="lbAZ">&nbsp;</A>
<H3>DNSSEC</H3>
<P>
<P>
This is an interim reply. It is followed either by &quot;OKAY&quot; or &quot;not present. It indicates if DNSSEC was available on the reply.
<P>
<A NAME="lbBA">&nbsp;</A>
<H3>TXT and AD-TXT</H3>
<P>
<P>
This is an interim reply. If there are TXT resource records in the reply, then each one is presented using this type. If preceeded by AD-, then this record was signed with DNSSEC.
<P>
<A NAME="lbBB">&nbsp;</A>
<H3>A and AD-A</H3>
<P>
<P>
This is an interim reply. If there are A resource records in the reply, then each one is presented using this type. If preceeded by AD-, then this record was signed with DNSSEC.
<P>
<A NAME="lbBC">&nbsp;</A>
<H3>AAAA and AD-AAAA</H3>
<P>
<P>
This is an interim reply. If there are AAAA resource records in the reply, then each one is presented using this type. If preceeded by AD-, then this record was signed with DNSSEC.
<P>
<A NAME="lbBD">&nbsp;</A>
<H3>PTR and AD-PTR</H3>
<P>
<P>
This is an interim reply. If there are PTR resource records in the reply, then each one is presented using this type. If preceeded by AD-, then this record was signed with DNSSEC.
<P>
<A NAME="lbBE">&nbsp;</A>
<H3>KEY and AD-KEY</H3>
<P>
<P>
This is an interim reply. If there are KEY resource records in the reply, then each one is presented using this type. If preceeded by AD-, then this record was signed with DNSSEC.
<P>
<A NAME="lbBF">&nbsp;</A>
<H3>IPSECKEY and AD-IPSECKEY</H3>
<P>
<P>
This is an interim reply. If there are IPSEC resource records in the reply, then each one is presented using this type. If preceeded by AD-, then this record was signed with DNSSEC.
<P>
<A NAME="lbBG">&nbsp;</A>
<H2>SPECIAL IPSECKEY PROCESSING</H2>
<P>
<P>
At the time of this writing, the IPSECKEY resource record is not entirely specified. In particular no resource record number has been assigned. This program assumes that it is resource record number 45. If the file /etc/ipsec.d/lwdnsq.conf exists, and contains a line like
<P>
<PRE>
ipseckey_rr=<B>number</B>
</PRE>
<BR>&nbsp;then&nbsp;this&nbsp;number&nbsp;will&nbsp;be&nbsp;used&nbsp;instead.&nbsp;The&nbsp;file&nbsp;is&nbsp;read&nbsp;only&nbsp;once&nbsp;at&nbsp;startup.
<P>
<A NAME="lbBH">&nbsp;</A>
<H2>OE DIRECTIVES</H2>
<P>
<P>
If the file /etc/ipsec.d/lwdnsq.conf exists, and contains a line like
<P>
<PRE>
queryany=false
</PRE>
<BR>&nbsp;then&nbsp;instead&nbsp;of&nbsp;doing&nbsp;an&nbsp;ALL&nbsp;query&nbsp;when&nbsp;looking&nbsp;for&nbsp;OE&nbsp;delegation&nbsp;records,&nbsp;lwdnsq&nbsp;will&nbsp;do&nbsp;a&nbsp;series&nbsp;of&nbsp;queries.&nbsp;It&nbsp;will&nbsp;first&nbsp;look&nbsp;for&nbsp;IPSECKEY,&nbsp;and&nbsp;then&nbsp;TXT&nbsp;record.&nbsp;If&nbsp;it&nbsp;finds&nbsp;neither,&nbsp;it&nbsp;will&nbsp;then&nbsp;look&nbsp;for&nbsp;KEY&nbsp;records&nbsp;of&nbsp;all&nbsp;kinds,&nbsp;although&nbsp;they&nbsp;do&nbsp;not&nbsp;contain&nbsp;delegation&nbsp;information.
<P>
<A NAME="lbBI">&nbsp;</A>
<H2>SPECIAL IPSECKEY PROCESSING</H2>
<P>
<PRE>
/etc/ipsec.d/lwdnsq.conf
</PRE>
<P>
<A NAME="lbBJ">&nbsp;</A>
<H2>AUTHOR</H2>
Michael Richardson &lt;<A HREF="mailto:mcr@sandelman.ottawa.on.ca">mcr@sandelman.ottawa.on.ca</A>&gt;.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">QUERY LANGUAGE</A><DD>
<DL>
<DT><A HREF="#lbAF">KEY queryid FQDN</A><DD>
<DT><A HREF="#lbAG">KEY4 queryid A.B.C.D</A><DD>
<DT><A HREF="#lbAH">KEY6 queryid A:B::C:D</A><DD>
<DT><A HREF="#lbAI">TXT4 queryid A.B.C.D</A><DD>
<DT><A HREF="#lbAJ">TXT6 queryid A:B::C:D</A><DD>
<DT><A HREF="#lbAK">KEY queryid FQDN</A><DD>
<DT><A HREF="#lbAL">IPSECKEY4 queryid A.B.C.D</A><DD>
<DT><A HREF="#lbAM">IPSECKEY6 queryid A:B::C:D</A><DD>
<DT><A HREF="#lbAN">OE4 queryid A.B.C.D</A><DD>
<DT><A HREF="#lbAO">OE6 queryid A:B::C:D</A><DD>
<DT><A HREF="#lbAP">A queryid FQDN</A><DD>
<DT><A HREF="#lbAQ">AAAA queryid FQDN</A><DD>
</DL>
<DT><A HREF="#lbAR">REPLIES TO QUERIES</A><DD>
<DL>
<DT><A HREF="#lbAS">START</A><DD>
<DT><A HREF="#lbAT">DONE</A><DD>
<DT><A HREF="#lbAU">RETRY</A><DD>
<DT><A HREF="#lbAV">FATAL</A><DD>
<DT><A HREF="#lbAW">CNAME</A><DD>
<DT><A HREF="#lbAX">CNAMEFROM</A><DD>
<DT><A HREF="#lbAY">NAME</A><DD>
<DT><A HREF="#lbAZ">DNSSEC</A><DD>
<DT><A HREF="#lbBA">TXT and AD-TXT</A><DD>
<DT><A HREF="#lbBB">A and AD-A</A><DD>
<DT><A HREF="#lbBC">AAAA and AD-AAAA</A><DD>
<DT><A HREF="#lbBD">PTR and AD-PTR</A><DD>
<DT><A HREF="#lbBE">KEY and AD-KEY</A><DD>
<DT><A HREF="#lbBF">IPSECKEY and AD-IPSECKEY</A><DD>
</DL>
<DT><A HREF="#lbBG">SPECIAL IPSECKEY PROCESSING</A><DD>
<DT><A HREF="#lbBH">OE DIRECTIVES</A><DD>
<DT><A HREF="#lbBI">SPECIAL IPSECKEY PROCESSING</A><DD>
<DT><A HREF="#lbBJ">AUTHOR</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

97
doc/manpage.d/ipsec_mailkey.8.html Normal file
View File

@ -0,0 +1,97 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_MAILKEY</TITLE>
</HEAD><BODY>
<H1>IPSEC_MAILKEY</H1>
Section: Maintenance Commands (8)<BR>Updated: 21 Feb 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec mailkey - mail DNS records for Opportunistic Encryption
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>mailkey</B>
--me
<A HREF="mailto:my@address.tld">my@address.tld</A>
[
<B>--reverse</B>
1.2.3.4
] [
<B>--forward</B>
hostname.domain.tld
]
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>mailkey</I>
is a meta-program. It generates a script which will attempt to mail the TXT
records required to enable Opportunistic Encryption (OE).
<P>
An e-mail address for the domain's DNS administrator is derived from SOA records.
The mail body and destination address are freely editable in the script.
<P>
If no administrator can be located, the output file will not be executable.
<P>
<DL COMPACT>
<DT><B>--me</B>&nbsp;<I><A HREF="mailto:my@address.tld">my@address.tld</A></I><DD>
set the Reply-To: address of the mail to be sent.
<DT><B>--forward</B>&nbsp;<I>hostname.domain.tld</I><DD>
the domain name to be used for initator-only OE.
<DT><B>--reverse</B>&nbsp;<I>1.2.3.4</I><DD>
the IP address to be used for full Opportunistic Encryption.
</DL>
<P>
Only one of --forward or --reverse may be specified.
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
<PRE>
/etc/ipsec.secrets
</PRE>
<A NAME="lbAF">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec_showhostkey.8.html">ipsec_showhostkey</A>(8), <A HREF="host.8.html">host</A>(8)
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project &lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt; by Sam Sgro.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
May produce indeterminate results when processing non-routable IPs.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">SEE ALSO</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

414
doc/manpage.d/ipsec_manual.8.html Normal file
View File

@ -0,0 +1,414 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_MANUAL</TITLE>
</HEAD><BODY>
<H1>IPSEC_MANUAL</H1>
Section: Maintenance Commands (8)<BR>Updated: 17 July 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec manual - take manually-keyed IPsec connections up and down
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>manual</B>
[
<B>--show</B>
] [
<B>--showonly</B>
] [
<B>--other</B>
]
<BR>
&nbsp;&nbsp;&nbsp;[
<B>--iam</B>
address<B>@</B>interface
] [
<B>--config</B>
configfile
]
<BR>
&nbsp;&nbsp;&nbsp;operation connection
<P>
<B>ipsec</B>
<B>manual</B>
[
<I>options</I>
]
<B>--union</B>
operation part ...
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Manual</I>
manipulates manually-keyed FreeS/WAN IPsec connections,
setting them up and shutting them down,
based on the information in the IPsec configuration file.
In the normal usage,
<I>connection</I>
is the name of a connection specification in the configuration file;
<I>operation</I>
is
<B>--up</B>,
<B>--down</B>,
<B>--route</B>,
or
<B>--unroute</B>.
<I>Manual</I>
generates setup (<B>--route</B>
or
<B>--up</B>)
or
teardown (<B>--down</B>
or
<B>--unroute</B>)
commands for the connection and feeds them to a shell for execution.
<P>
The
<B>--up</B>
operation brings the specified connection up, including establishing a
suitable route for it if necessary.
<P>
The
<B>--route</B>
operation just establishes the route for a connection.
Unless and until an
<B>--up</B>
operation is done, packets routed by that route will simply be discarded.
<P>
The
<B>--down</B>
operation tears the specified connection down,
<I>except</I>
that it leaves the route in place.
Unless and until an
<B>--unroute</B>
operation is done, packets routed by that route will simply be discarded.
This permits establishing another connection to the same destination
without any ``window'' in which packets can pass without encryption.
<P>
The
<B>--unroute</B>
operation (and only the
<B>--unroute</B>
operation) deletes any route established for a connection.
<P>
In the
<B>--union</B>
usage, each
<I>part</I>
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
<B>also</B>
parameter in connection descriptions;
see
<I><A HREF="ipsec.conf.5.html">ipsec.conf</A></I>(5)
for details.)
<P>
The
<B>--show</B>
option turns on the
<B>-x</B>
option of the shell used to execute the commands,
so each command is shown as it is executed.
<P>
The
<B>--showonly</B>
option causes
<I>manual</I>
to show the commands it would run, on standard output,
and not run them.
<P>
The
<B>--other</B>
option causes
<I>manual</I>
to pretend it is the other end of the connection.
This is probably not useful except in combination with
<B>--showonly</B>.
<P>
The
<B>--iam</B>
option causes
<I>manual</I>
to believe it is running on the host with the specified IP
<I>address</I>,
and that it should use the specified
<I>interface</I>
(normally it determines all this automatically,
based on what IPsec interfaces are up and how they are configured).
<P>
The
<B>--config</B>
option specifies a non-standard location for the FreeS/WAN IPsec
configuration file (default
<I>/etc/ipsec.conf</I>).
<P>
See
<I><A HREF="ipsec.conf.5.html">ipsec.conf</A></I>(5)
for details of the configuration file.
Apart from the basic parameters which specify the endpoints and routing
of a connection (<B>left</B>
and
<B>right</B>,
plus possibly
<B>leftsubnet</B>,
<B>leftnexthop</B>,
<B>leftfirewall</B>,
their
<B>right</B>
equivalents,
and perhaps
<B>type</B>),
a non-<B>passthrough</B>
<I>manual</I>
connection needs an
<B>spi</B>
or
<B>spibase</B>
parameter and some parameters specifying encryption, authentication, or
both, most simply
<B>esp</B>,
<B>espenckey</B>,
and
<B>espauthkey</B>.
Moderately-secure keys can be obtained from
<I><A HREF="ipsec_ranbits.8.html">ipsec_ranbits</A></I>(8).
For production use of manually-keyed connections,
it is strongly recommended that the keys be kept in a separate file
(with permissions
<B>rw-------</B>)
using the
<B>include</B>
and
<B>also</B>
facilities of the configuration file (see
<I><A HREF="ipsec.conf.5.html">ipsec.conf</A></I>(5)).
<P>
If an
<B>spi</B>
parameter is given,
<I>manual</I>
uses that value as the SPI number for all the SAs
(which are in separate number spaces anyway).
If an
<B>spibase</B>
parameter is given instead,
<I>manual</I>
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
<B>0x100</B>
through
<B>0xfff</B>;
FreeS/WAN reserves those for manual keying and will not
attempt to use them for automatic keying (unless requested to,
presumably by a non-FreeS/WAN other end).
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
/etc/ipsec.conf<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT>default IPsec configuration file<BR>
<BR>
/var/run/ipsec.info<TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</TT><B>%defaultroute</B> information<BR>
<A NAME="lbAF">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec.conf.5.html">ipsec.conf</A>(5), <A HREF="ipsec_spi.8.html">ipsec_spi</A>(8), <A HREF="ipsec_eroute.8.html">ipsec_eroute</A>(8), <A HREF="ipsec_spigrp.8.html">ipsec_spigrp</A>(8),
<A HREF="route.8.html">route</A>(8)
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
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
<I>is</I>
smart enough to translate bit-count netmasks to dotted-decimal form.
<P>
If the connection specification for a connection is changed between an
<B>--up</B>
and the ensuing
<B>--down</B>,
chaos may ensue.
<P>
The
<B>--up</B>
operation is not smart enough to notice whether the connection is already up.
<P>
<I>Manual</I>
is not smart enough to reject insecure combinations of algorithms,
e.g. encryption with no authentication at all.
<P>
Any non-IPsec route to the other end which is replaced by the
<B>--up</B>
or
<B>--route</B>
operation will not be re-established by
<B>--unroute</B>.
Whether this is a feature or a bug depends on your viewpoint.
<P>
The optional parameters which
override the automatic
<B>spibase</B>-based
SPI assignment are a messy area of the code and bugs are likely.
<P>
``Road warrior'' handling,
and other special forms of setup which
require negotiation between the two security gateways,
inherently cannot be done with
<I>manual</I>.
<P>
<I>Manual</I>
generally lags behind
<I>auto</I>
in support of various features,
even when implementation <I>would</I> be possible.
For example, currently it does not do IPComp content compression.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">SEE ALSO</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

238
doc/manpage.d/ipsec_maskof.3.html Normal file
View File

@ -0,0 +1,238 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITSUBNET</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITSUBNET</H1>
Section: C Library Functions (3)<BR>Updated: 12 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initsubnet - initialize an ip_subnet
<BR>
ipsec addrtosubnet - initialize a singleton ip_subnet
<BR>
ipsec subnettypeof - get address type of an ip_subnet
<BR>
ipsec masktocount - convert subnet mask to bit count
<BR>
ipsec networkof - get base address of an ip_subnet
<BR>
ipsec maskof - get subnet mask of an ip_subnet
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initsubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>int maskbits, int clash, ip_subnet *dst);</B>
<BR>
<B>const char *addrtosubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>ip_subnet *dst);</B>
<P>
<B>int subnettypeof(const ip_subnet *src);</B>
<BR>
<B>int masktocount(const ip_address *src);</B>
<BR>
<B>void networkof(const ip_subnet *src, ip_address *dst);</B>
<BR>
<B>void maskof(const ip_subnet *src, ip_address *dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_subnet</I>
to contain a description of an IP subnet
(base address plus mask).
These functions provide basic tools for creating and examining this type.
<P>
<I>Initsubnet</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_subnet</I>
from a base address and
a count of mask bits.
The
<I>clash</I>
parameter specifies what to do if the base address includes
<B>1</B>
bits outside the prefix specified by the mask
(that is, in the ``host number'' part of the address):
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT>'0'<DD>
zero out host-number bits
<DT>'x'<DD>
non-zero host-number bits are an error
</DL>
</DL>
<P>
<I>Initsubnet</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
<I>Addrtosubnet</I>
initializes an
<I>ip_subnet</I>
variable
<I>*dst</I>
to a ``singleton subnet'' containing the single address
<I>*addr</I>.
It returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure.
<P>
<I>Subnettypeof</I>
returns the address type of a subnet,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Masktocount</I>
converts a subnet mask, expressed as an address, to a bit count
suitable for use with
<I>initsubnet</I>.
It returns
<B>-1</B>
for error; see DIAGNOSTICS.
<P>
<I>Networkof</I>
fills in
<I>*dst</I>
with the base address of subnet
<I>src</I>.
<P>
<I>Maskof</I>
fills in
<I>*dst</I>
with the subnet mask of subnet
<I>src</I>,
expressed as an address.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttosubnet.3.html">ipsec_ttosubnet</A>(3), <A HREF="ipsec_rangetosubnet.3.html">ipsec_rangetosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>initsubnet</I>
are:
unknown address family;
unknown
<I>clash</I>
value;
impossible mask bit count;
non-zero host-number bits and
<I>clash</I>
is
<B>'x'</B>.
Fatal errors in
<I>addrtosubnet</I>
are:
unknown address family.
Fatal errors in
<I>masktocount</I>
are:
unknown address family;
mask bits not contiguous.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

122
doc/manpage.d/ipsec_masktobits.3.html Normal file
View File

@ -0,0 +1,122 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_GOODMASK</TITLE>
</HEAD><BODY>
<H1>IPSEC_GOODMASK</H1>
Section: C Library Functions (3)<BR>Updated: 11 June 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec goodmask - is this Internet subnet mask a valid one?
<BR>
ipsec masktobits - convert Internet subnet mask to bit count
<BR>
ipsec bitstomask - convert bit count to Internet subnet mask
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>int goodmask(struct in_addr mask);</B>
<BR>
<B>int masktobits(struct in_addr mask);</B>
<BR>
<B>struct in_addr bitstomask(int n);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
These functions are obsolete;
see
<I><A HREF="ipsec_masktocount.3.html">ipsec_masktocount</A></I>(3)
for a partial replacement.
<P>
<I>Goodmask</I>
reports whether the subnet
<I>mask</I>
is a valid one,
i.e. consists of a (possibly empty) sequence of
<B>1</B>s
followed by a (possibly empty) sequence of
<B>0</B>s.
<I>Masktobits</I>
takes a (valid) subnet mask and returns the number of
<B>1</B>
bits in it.
<I>Bitstomask</I>
reverses this,
returning the subnet mask corresponding to bit count
<I>n</I>.
<P>
All masks are in network byte order.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_atosubnet.3.html">ipsec_atosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
<I>Masktobits</I>
returns
<B>-1</B>
for an invalid mask.
<I>Bitstomask</I>
returns an all-zeros mask for a negative or out-of-range
<I>n</I>.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAH">&nbsp;</A>
<H2>BUGS</H2>
The error-reporting convention of
<I>bitstomask</I>
is less than ideal;
zero is sometimes a legitimate mask.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
<DT><A HREF="#lbAH">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

238
doc/manpage.d/ipsec_masktocount.3.html Normal file
View File

@ -0,0 +1,238 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITSUBNET</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITSUBNET</H1>
Section: C Library Functions (3)<BR>Updated: 12 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initsubnet - initialize an ip_subnet
<BR>
ipsec addrtosubnet - initialize a singleton ip_subnet
<BR>
ipsec subnettypeof - get address type of an ip_subnet
<BR>
ipsec masktocount - convert subnet mask to bit count
<BR>
ipsec networkof - get base address of an ip_subnet
<BR>
ipsec maskof - get subnet mask of an ip_subnet
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initsubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>int maskbits, int clash, ip_subnet *dst);</B>
<BR>
<B>const char *addrtosubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>ip_subnet *dst);</B>
<P>
<B>int subnettypeof(const ip_subnet *src);</B>
<BR>
<B>int masktocount(const ip_address *src);</B>
<BR>
<B>void networkof(const ip_subnet *src, ip_address *dst);</B>
<BR>
<B>void maskof(const ip_subnet *src, ip_address *dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_subnet</I>
to contain a description of an IP subnet
(base address plus mask).
These functions provide basic tools for creating and examining this type.
<P>
<I>Initsubnet</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_subnet</I>
from a base address and
a count of mask bits.
The
<I>clash</I>
parameter specifies what to do if the base address includes
<B>1</B>
bits outside the prefix specified by the mask
(that is, in the ``host number'' part of the address):
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT>'0'<DD>
zero out host-number bits
<DT>'x'<DD>
non-zero host-number bits are an error
</DL>
</DL>
<P>
<I>Initsubnet</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
<I>Addrtosubnet</I>
initializes an
<I>ip_subnet</I>
variable
<I>*dst</I>
to a ``singleton subnet'' containing the single address
<I>*addr</I>.
It returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure.
<P>
<I>Subnettypeof</I>
returns the address type of a subnet,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Masktocount</I>
converts a subnet mask, expressed as an address, to a bit count
suitable for use with
<I>initsubnet</I>.
It returns
<B>-1</B>
for error; see DIAGNOSTICS.
<P>
<I>Networkof</I>
fills in
<I>*dst</I>
with the base address of subnet
<I>src</I>.
<P>
<I>Maskof</I>
fills in
<I>*dst</I>
with the subnet mask of subnet
<I>src</I>,
expressed as an address.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttosubnet.3.html">ipsec_ttosubnet</A>(3), <A HREF="ipsec_rangetosubnet.3.html">ipsec_rangetosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>initsubnet</I>
are:
unknown address family;
unknown
<I>clash</I>
value;
impossible mask bit count;
non-zero host-number bits and
<I>clash</I>
is
<B>'x'</B>.
Fatal errors in
<I>addrtosubnet</I>
are:
unknown address family.
Fatal errors in
<I>masktocount</I>
are:
unknown address family;
mask bits not contiguous.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

238
doc/manpage.d/ipsec_networkof.3.html Normal file
View File

@ -0,0 +1,238 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_INITSUBNET</TITLE>
</HEAD><BODY>
<H1>IPSEC_INITSUBNET</H1>
Section: C Library Functions (3)<BR>Updated: 12 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec initsubnet - initialize an ip_subnet
<BR>
ipsec addrtosubnet - initialize a singleton ip_subnet
<BR>
ipsec subnettypeof - get address type of an ip_subnet
<BR>
ipsec masktocount - convert subnet mask to bit count
<BR>
ipsec networkof - get base address of an ip_subnet
<BR>
ipsec maskof - get subnet mask of an ip_subnet
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *initsubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>int maskbits, int clash, ip_subnet *dst);</B>
<BR>
<B>const char *addrtosubnet(const ip_address *addr,</B>
<BR>
&nbsp;
<B>ip_subnet *dst);</B>
<P>
<B>int subnettypeof(const ip_subnet *src);</B>
<BR>
<B>int masktocount(const ip_address *src);</B>
<BR>
<B>void networkof(const ip_subnet *src, ip_address *dst);</B>
<BR>
<B>void maskof(const ip_subnet *src, ip_address *dst);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
library uses an internal type
<I>ip_subnet</I>
to contain a description of an IP subnet
(base address plus mask).
These functions provide basic tools for creating and examining this type.
<P>
<I>Initsubnet</I>
initializes a variable
<I>*dst</I>
of type
<I>ip_subnet</I>
from a base address and
a count of mask bits.
The
<I>clash</I>
parameter specifies what to do if the base address includes
<B>1</B>
bits outside the prefix specified by the mask
(that is, in the ``host number'' part of the address):
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT>'0'<DD>
zero out host-number bits
<DT>'x'<DD>
non-zero host-number bits are an error
</DL>
</DL>
<P>
<I>Initsubnet</I>
returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
<P>
<I>Addrtosubnet</I>
initializes an
<I>ip_subnet</I>
variable
<I>*dst</I>
to a ``singleton subnet'' containing the single address
<I>*addr</I>.
It returns
<B>NULL</B>
for success and
a pointer to a string-literal error message for failure.
<P>
<I>Subnettypeof</I>
returns the address type of a subnet,
normally
<B>AF_INET</B>
or
<B>AF_INET6</B>.
(The
<B>&lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
header file arranges to include the necessary headers for these
names to be known.)
<P>
<I>Masktocount</I>
converts a subnet mask, expressed as an address, to a bit count
suitable for use with
<I>initsubnet</I>.
It returns
<B>-1</B>
for error; see DIAGNOSTICS.
<P>
<I>Networkof</I>
fills in
<I>*dst</I>
with the base address of subnet
<I>src</I>.
<P>
<I>Maskof</I>
fills in
<I>*dst</I>
with the subnet mask of subnet
<I>src</I>,
expressed as an address.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="inet.3.html">inet</A>(3), <A HREF="ipsec_ttosubnet.3.html">ipsec_ttosubnet</A>(3), <A HREF="ipsec_rangetosubnet.3.html">ipsec_rangetosubnet</A>(3)
<A NAME="lbAF">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Fatal errors in
<I>initsubnet</I>
are:
unknown address family;
unknown
<I>clash</I>
value;
impossible mask bit count;
non-zero host-number bits and
<I>clash</I>
is
<B>'x'</B>.
Fatal errors in
<I>addrtosubnet</I>
are:
unknown address family.
Fatal errors in
<I>masktocount</I>
are:
unknown address family;
mask bits not contiguous.
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

196
doc/manpage.d/ipsec_newhostkey.8.html Normal file
View File

@ -0,0 +1,196 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_NEWHOSTKEY</TITLE>
</HEAD><BODY>
<H1>IPSEC_NEWHOSTKEY</H1>
Section: Maintenance Commands (8)<BR>Updated: 4 March 2002<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec newhostkey - generate a new host authentication key
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>ipsec</B>
<B>newhostkey</B>
<B>--output</B>
filename
[
<B>--quiet</B>
]
<B>\</B>
<BR>
[
<B>--bits</B>
n
]
[
<B>--hostname</B>
host
]
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Newhostkey</I>
outputs (into
<I>filename</I>,
which can be `<B>-</B>' for standard output)
an RSA private key suitable for this host,
in
<I>/etc/ipsec.secrets</I>
format
(see
<I><A HREF="ipsec.secrets.5.html">ipsec.secrets</A></I>(5)).
Normally,
<I>newhostkey</I>
invokes
<I>rsasigkey</I>
(see
<I><A HREF="ipsec_rsasigkey.8.html">ipsec_rsasigkey</A></I>(8))
with the
<B>--verbose</B>
option, so a narrative of what is being done appears on standard error.
<P>
The
<B>--output</B>
specifier, although it is syntactically an option and can appear at
any point among the options (it doesn't have to be first),
is not optional.
The specified
<I>filename</I>
is created under umask
<B>077</B>
if nonexistent;
if it already exists and is non-empty,
a warning message about that is sent to standard error,
and the output is appended to the file.
<P>
The
<B>--quiet</B>
option suppresses both the
<I>rsasigkey</I>
narrative and the existing-file warning message.
<P>
The
<B>--bits</B>
option specifies the number of bits in the key;
the current default is 2192 and we do not recommend use of anything
shorter unless unusual constraints demand it.
<P>
The
<B>--hostname</B>
option is passed through to
<I>rsasigkey</I>
to tell it what host name to label the output with
(via its
<B>--hostname</B>
option).
<P>
The output format is that of
<I>rsasigkey</I>,
with bracketing added to complete the
<I>ipsec.secrets</I>
format.
In the usual case, where
<I>ipsec.secrets</I>
contains only the host's own private key,
the output of
<I>newhostkey</I>
is sufficient as a complete
<I>ipsec.secrets</I>
file.
<A NAME="lbAE">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.secrets.5.html">ipsec.secrets</A>(5), <A HREF="ipsec_rsasigkey.8.html">ipsec_rsasigkey</A>(8)
<A NAME="lbAF">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org">http://www.freeswan.org</A>&gt;
by Henry Spencer.
<A NAME="lbAG">&nbsp;</A>
<H2>BUGS</H2>
As with
<I>rsasigkey</I>,
the run time is difficult to predict,
since depletion of the system's randomness pool can cause
arbitrarily long waits for random bits,
and the prime-number searches can also take unpredictable
(and potentially large) amounts of CPU time.
See
<I><A HREF="ipsec_rsasigkey.8.html">ipsec_rsasigkey</A></I>(8)
for some typical performance numbers.
<P>
A higher-level tool which could handle the clerical details
of changing to a new key would be helpful.
<P>
The requirement for
<B>--output</B>
is a blemish,
but private keys are extremely sensitive information
and unusual precautions seem justified.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">SEE ALSO</A><DD>
<DT><A HREF="#lbAF">HISTORY</A><DD>
<DT><A HREF="#lbAG">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

275
doc/manpage.d/ipsec_optionsfrom.3.html Normal file
View File

@ -0,0 +1,275 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_OPTIONSFROM</TITLE>
</HEAD><BODY>
<H1>IPSEC_OPTIONSFROM</H1>
Section: C Library Functions (3)<BR>Updated: 16 Oct 1998<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec optionsfrom - read additional ``command-line'' options from file
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>#include &lt;<A HREF="file:/usr/include/freeswan.h">freeswan.h</A>&gt;</B>
<P>
<B>const char *optionsfrom(char *filename, int *argcp,</B>
<BR>
&nbsp;
<B>char ***argvp, int optind, FILE *errsto);</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>Optionsfrom</I>
is called from within a
<I><A HREF="getopt_long.3.html">getopt_long</A></I>(3)
scan,
as the result of the appearance of an option (preferably
<B>--optionsfrom</B>)
to insert additional ``command-line'' arguments
into the scan immediately after
the option.
Typically this would be done to pick up options which are
security-sensitive and should not be visible to
<I><A HREF="ps.1.html">ps</A></I>(1)
and similar commands,
and hence cannot be supplied as part
of the actual command line or the environment.
<P>
<I>Optionsfrom</I>
reads the additional arguments from the specified
<I>filename</I>,
allocates a new argument vector to hold pointers to the existing
arguments plus the new ones,
and amends
<I>argc</I>
and
<I>argv</I>
(via the pointers
<I>argcp</I>
and
<I>argvp</I>,
which must point to the
<I>argc</I>
and
<I>argv</I>
being supplied to
<I><A HREF="getopt_long.3.html">getopt_long</A></I>(3))
accordingly.
<I>Optind</I>
must be the index, in the original argument vector,
of the next argument.
<P>
If
<I>errsto</I>
is NULL,
<I>optionsfrom</I>
returns NULL for success and
a pointer to a string-literal error message for failure;
see DIAGNOSTICS.
If
<I>errsto</I>
is non-NULL and an error occurs,
<I>optionsfrom</I>
prints a suitable complaint onto the
<I>errsto</I>
descriptor and invokes
<I>exit</I>
with an exit status of 2;
this is a convenience for cases where more sophisticated
responses are not required.
<P>
The text of existing arguments is not disturbed by
<I>optionsfrom</I>,
so pointers to them and into them remain valid.
<P>
The file of additional arguments is an ASCII text file.
Lines consisting solely of white space,
and lines beginning with
<B>#</B>,
are comments and are ignored.
Otherwise, a line which does not begin with
<B>-</B>
is taken to be a single argument;
if it both begins and ends with double-quote (&quot;),
those quotes are stripped off (note, no other processing is done within
the line!).
A line beginning with
<B>-</B>
is considered to contain multiple arguments separated by white space.
<P>
Because
<I>optionsfrom</I>
reads its entire file before the
<I><A HREF="getopt_long.3.html">getopt_long</A></I>(3)
scan is resumed, an
<I>optionsfrom</I>
file can contain another
<B>--optionsfrom</B>
option.
Obviously, infinite loops are possible here.
If
<I>errsto</I>
is non-NULL,
<I>optionsfrom</I>
considers it an error to be called more than 100 times.
If
<I>errsto</I>
is NULL,
loop detection is up to the caller
(and the internal loop counter is zeroed out).
<A NAME="lbAE">&nbsp;</A>
<H2>EXAMPLE</H2>
A reasonable way to invoke
<I>optionsfrom</I>
would be like so:
<P>
<PRE>
<B>#include &lt;<A HREF="file:/usr/include/getopt.h">getopt.h</A>&gt;
struct option opts[] = {
/* ... */
&quot;optionsfrom&quot;, 1, NULL, '+',
/* ... */
};
int
main(argc, argv)
int argc;
char *argv[];
{
int opt;
extern char *optarg;
extern int optind;
while ((opt = getopt_long(argc, argv, &quot;&quot;, opts, NULL)) != EOF)
switch (opt) {
/* ... */
case '+': /* optionsfrom */
optionsfrom(optarg, &amp;argc, &amp;argv, optind, stderr);
/* does not return on error */
break;
/* ... */
}
/* ... */
</B></PRE>
<A NAME="lbAF">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="getopt_long.3.html">getopt_long</A>(3)
<A NAME="lbAG">&nbsp;</A>
<H2>DIAGNOSTICS</H2>
Errors in
<I>optionsfrom</I>
are:
unable to open file;
attempt to allocate temporary storage for argument or
argument vector failed;
read error in file;
line too long.
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for the FreeS/WAN project by Henry Spencer.
<A NAME="lbAI">&nbsp;</A>
<H2>BUGS</H2>
The double-quote convention is rather simplistic.
<P>
Line length is currently limited to 1023 bytes,
and there is no continuation convention.
<P>
The restriction of error reports to literal strings
(so that callers don't need to worry about freeing them or copying them)
does limit the precision of error reporting.
<P>
The error-reporting convention lends itself
to slightly obscure code,
because many readers will not think of NULL as signifying success.
<P>
There is a certain element of unwarranted chumminess with
the insides of
<I><A HREF="getopt_long.3.html">getopt_long</A></I>(3)
here.
No non-public interfaces are actually used, but
<I>optionsfrom</I>
does rely on
<I><A HREF="getopt_long.3.html">getopt_long</A></I>(3)
being well-behaved in certain ways that are not actually
promised by the specs.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">EXAMPLE</A><DD>
<DT><A HREF="#lbAF">SEE ALSO</A><DD>
<DT><A HREF="#lbAG">DIAGNOSTICS</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
<DT><A HREF="#lbAI">BUGS</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

176
doc/manpage.d/ipsec_pf_key.5.html Normal file
View File

@ -0,0 +1,176 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_PF_KEY</TITLE>
</HEAD><BODY>
<H1>IPSEC_PF_KEY</H1>
Section: File Formats (5)<BR>Updated: 29 Jun 2000<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
ipsec_pf_key - lists PF_KEY sockets registered with KLIPS
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>cat</B>
<B>/proc/net/pf_key</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<I>/proc/net/pf_key</I>
is a read-only file which lists the presently open PF_KEY sockets on the
local system and their parameters.
<P>
Each line lists one PF_KEY socket.
A table entry consists of:
<DL COMPACT>
<DT>+<DD>
sock pointer (sock)
<DT>+<DD>
PID of the socket owner (pid)
<DT>+<DD>
flag to indicate if the socket is dead (d)
<DT>+<DD>
socket wait queue (sleep)
<DT>+<DD>
socket pointer (socket)
<DT>+<DD>
next socket in chain (next)
<DT>+<DD>
previous socket in chain (prev)
<DT>+<DD>
last socket error (e)
<DT>+<DD>
pointer to destruct routine (destruct)
<DT>+<DD>
is this a reused socket (r)
<DT>+<DD>
has this socket been zapped (z)
<DT>+<DD>
socket family to which this socket belongs (fa)
<DT>+<DD>
local port number (n)
<DT>+<DD>
protocol version number (p)
<DT>+<DD>
Receive queue bytes committed (r)
<DT>+<DD>
Transmit queue bytes committed (w)
<DT>+<DD>
option memory allocations (o)
<DT>+<DD>
size of send buffer in bytes (sndbf)
<DT>+<DD>
timestamp in seconds (stamp)
<DT>+<DD>
socket flags (Flags)
<DT>+<DD>
socket type (Type)
<DT>+<DD>
connection state (St)
<B>.SH</B>EXAMPLES
<DT>
<DD>
<DT><B>c3b8c140 3553 0 c0599818 c05997fc 0 0 0 0 1 0 15 0 2 0 0 0 65535 0.103232 00000000 00000003 01</B>
<DD>
</DL>
<P>
shows that there is one pf_key socket set up that starts at
<B>c3b8c140</B>,
whose owning process has PID
<B>3553</B>,
the socket is not dead, its wait queue is at
<B>c0599818</B>,
whose owning socket is at
<B>c05997fc</B>,
with no other sockets in the chain, no errors, no destructor, it is a
reused socket which has not been zapped, from protocol family
<B>15</B>
(PF_KEY), local port number
<B>0</B>,
protocol socket version
<B>2</B>,
no memory allocated to transmit, receive or option queues, a send buffer
of almost
<B>64kB</B>,
a timestamp of
<B>0.103232</B>,
no flags set, type
<B>3</B>,
in state
<B>1</B>.
<A NAME="lbAE">&nbsp;</A>
<H2>FILES</H2>
/proc/net/pf_key
<A NAME="lbAF">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8), <A HREF="ipsec_eroute.5.html">ipsec_eroute</A>(5), <A HREF="ipsec_spi.5.html">ipsec_spi</A>(5),
<A HREF="ipsec_spigrp.5.html">ipsec_spigrp</A>(5), <A HREF="ipsec_klipsdebug.5.html">ipsec_klipsdebug</A>(5), <A HREF="ipsec_tncfg.8.html">ipsec_tncfg</A>(8), <A HREF="ipsec_version.5.html">ipsec_version</A>(5)
<A NAME="lbAG">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Richard Guy Briggs.
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">FILES</A><DD>
<DT><A HREF="#lbAF">SEE ALSO</A><DD>
<DT><A HREF="#lbAG">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

122
doc/manpage.d/ipsec_pf_key.8.html Normal file
View File

@ -0,0 +1,122 @@
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of IPSEC_PF_KEY</TITLE>
</HEAD><BODY>
<H1>IPSEC_PF_KEY</H1>
Section: User Commands (1)<BR>Updated: 17 Oct 2001<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB">&nbsp;</A>
<H2>NAME</H2>
pf_key - shows pfkey messages emitted by the kernel
<A NAME="lbAC">&nbsp;</A>
<H2>SYNOPSIS</H2>
<B>pf_key</B>
<B>--ah</B>
<B>--esp</B>
<B>--ipip</B>
<B>--ipcomp</B>
<B>--daemon </B>
<I>file</I>
<B>hmac-md5-96</B>|<B>hmac-sha1-96</B>
<A NAME="lbAD">&nbsp;</A>
<H2>DESCRIPTION</H2>
<B>pf_key</B>
is a program to open a PF_KEY socket and print all messages that are received
from it. With no options, it will register itself to receive key requests for
AH, ESP, IPIP and IPCOMP security associations. If given more specific
options, then it will listen only to those protocols which are listed.
<P>
If the messages are recognized, the messages will be decoded.
<P>
If the option
<B>--daemon</B>
is provided, then after doing the registrations, the program will fork
into the background. The provided file will be opened and the process ID of
the background process will be written to it. This option is present to
present race conditions in regression testing.
<A NAME="lbAE">&nbsp;</A>
<H2>EXAMPLES</H2>
<DL COMPACT>
<DT>
<DD>
</DL>
<A NAME="lbAF">&nbsp;</A>
<H2>FILES</H2>
/proc/net/pf_key
<A NAME="lbAG">&nbsp;</A>
<H2>SEE ALSO</H2>
<A HREF="pf_key.5.html">pf_key</A>(5), <A HREF="ipsec.8.html">ipsec</A>(8), <A HREF="ipsec_manual.8.html">ipsec_manual</A>(8), <A HREF="ipsec_eroute.5.html">ipsec_eroute</A>(5), <A HREF="ipsec_spi.5.html">ipsec_spi</A>(5),
<A HREF="ipsec_spigrp.5.html">ipsec_spigrp</A>(5), <A HREF="ipsec_klipsdebug.5.html">ipsec_klipsdebug</A>(5), <A HREF="ipsec_tncfg.8.html">ipsec_tncfg</A>(8), <A HREF="ipsec_version.5.html">ipsec_version</A>(5)
<A NAME="lbAH">&nbsp;</A>
<H2>HISTORY</H2>
Written for the Linux FreeS/WAN project
&lt;<A HREF="http://www.freeswan.org/">http://www.freeswan.org/</A>&gt;
by Michael Richardson &lt;<A HREF="mailto:mcr@freeswan.org">mcr@freeswan.org</A>&gt;
<P>
<HR>
<A NAME="index">&nbsp;</A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">NAME</A><DD>
<DT><A HREF="#lbAC">SYNOPSIS</A><DD>
<DT><A HREF="#lbAD">DESCRIPTION</A><DD>
<DT><A HREF="#lbAE">EXAMPLES</A><DD>
<DT><A HREF="#lbAF">FILES</A><DD>
<DT><A HREF="#lbAG">SEE ALSO</A><DD>
<DT><A HREF="#lbAH">HISTORY</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 21:40:18 GMT, November 11, 2003
</BODY>
</HTML>

Some files were not shown because too many files have changed in this diff Show More