10. Monitoring functions
11. Firewall support functions
11.1 Environment variables in the updown script
- 11.2 Automatic insertion and deletion of iptables firewall rules (NEW)
+ 11.2 Automatic insertion and deletion of iptables firewall rules
11.3 Sample Linux 2.6 _updown_espmark script for iptables < 1.3.5
12. Authentication with raw RSA public keys
13. Authentication with OpenPGP certificates
14.1 Authentication and encryption algorithms
14.2 NAT traversal
14.3 Dead peer detection
- 14.4 IKE Mode Config
+ 14.4 IKE Mode Config Pull Mode
+ 14.5 IKE Mode Config Push Mode
+ 14.6 XAUTH - Extended Authentication (NEW)
15. Copyright statement and acknowledgements
strongSwan is an OpenSource IPsec solution for the Linux operating system
and currently supports the following features:
- * runs both on Linux 2.4 (KLIPS) and Linux 2.6 (native IPsec) kernels.
+ * runs on Linux 2.6 (native IPsec) kernels.
* strong 3DES, AES, Serpent, Twofish, or Blowfish encryption.
* NAT-Traversal (RFC 3947)
- * Support of Virtual IPs via static configuratin and IKE Mode Config
+ * Support of Virtual IPs via static configuration and IKE Mode Config
+
+ * XAUTH client and server functionality in conjunction with either PSK
+ or RSA IKE Main Mode authentication.
* Support of Delete SA and informational Notification messages.
In the following examples we assume for reasons of clarity that left designates
the local host and that right is the remote host. Certificates for users, hosts
-and gateways are issued by a ficticious strongSwan CA. How to generate private keys
+and gateways are issued by a fictitious strongSwan CA. How to generate private keys
and certificates using OpenSSL will be explained in section 3. The CA certificate
"strongswanCert.pem" must be present on all VPN end points in order to be able to
authenticate the peers.
part of the certificate request message when strongSwan is the initiator.
A special case occurs when strongSwan responds to a roadwarrior. If several
roadwarrior connections based on different CAs are defined then all eligible
-CAs will be listed in Pluto\92s certificate request message.
+CAs will be listed in Pluto�s certificate request message.
4.9 IPsec policies based on group attributes
if self-signed certificates are used which wouldn't be accepted any way by
the other side. In these cases it is recommended to add
- leftsendcert=never
+ leftsendcert=never
to the connection definition[s] in order to avoid the sending of the host's
own certificate. The default value is
- leftsendcert=always.
+ leftsendcert=ifasked
+
+If a peer does not send a certificate request then use the setting
+
+ leftsendcert=always
If a peer certificate contains a subjectAltName extension, then an alternative
rightid type can be used, as the example "conn sun" shows. If no rightid
000 8836362e030e6707c32ffaa0bdad5540
The leading three characters represent the return code of the whack channel
-with 000 signifying that no error has occured. Here is another example showing
+with 000 signifying that no error has occurred. Here is another example showing
the use of the inbase and outbase attributes
ipsec scdecrypt m/ewDnTs0k...woE= --inbase base64 --outbase text
ipsec listpubkeys [--utc]
lists all public keys currently installed in the chained list of public
-keys. These keys were statically loaded from ipsec.conf or aquired either
+keys. These keys were statically loaded from ipsec.conf or acquired either
from received certificates or retrieved from secure DNS servers using
opportunistic mode.
and can be used when the following prerequisites are fulfilled:
- - Linux 2.4.x kernel, KLIPS IPsec stack, and arbitrary iptables version.
- Filtering of tunneled traffic is based on ipsecN interfaces.
-
- - Linux 2.4.16 kernel or newer, native NETKEY IPsec stack, and
+ - Linux 2.6.16 kernel or newer, native NETKEY IPsec stack, and
iptables-1.3.5 or newer. Filtering of tunneled traffic is based on
IPsec policy matching rules.
Currently please refer to README.NAT-Traversal document in the strongSwan
distribution.
-
-
+
+
14.3 Dead peer detection
--------------------
dpdaction=none, which disables DPD.
-14.4 IKE Mode Config
- ---------------
-
+14.4 IKE Mode Config Pull Mode
+ -------------------------
+
The IKE Mode Config protocol <draft-ietf-ipsec-isakmp-mode-cfg-04.txt> allows
the dynamic assignment of virtual IP addresses and optional DNS and WINS server
-information to IPsec clients. Currently only "Mode Config Pull Mode" is
-implemented where the client actively sends a Mode Config request to the server
-in order to obtain a virtual IP.
+information to IPsec clients. As a default the "Mode Config Pull Mode" is
+used where the client actively sends a Mode Config request to the server
+in order to obtain a virtual IP. The server answers with a Mode Config reply
+message containing the requested information.
Client side configuration (carol):
an LDAP-based lookup mechanism will be supported.
+14.5 IKE Mode Config Push Mode
+ -------------------------
+
+Cisco VPN equipment uses the alternative "Mode Config Push Mode" where the
+initiating clients waits for the server to push down a virtual address via
+a Mode Config set message. The receipt is acknowledged by the client with a
+Mode Config ack message.
+
+Mode Config Push Mode is activated by the parameter
+
+ modeconfig=push
+
+as part of the connection definition in ipsec.conf. The default value is
+modeconfig=pull.
+
+
+14.6 XAUTH - Extended Authentication
+ -------------------------------
+
+The XAUTH protocol <draft-beaulieu-ike-xauth-02.txt> allows an extended
+client authentication using e.g. a username/password paradigm in addition
+to the IKE Main Mode authentication. Thus XAUTH can be used in conjunction
+with Pre-Shared Keys (PSK) by defining
+
+ authby=xauthpsk
+
+or with RSA signatures
+
+ authby=xauthrsasig
+
+in the connection definition, correspondingly. strongSwan can act either as
+an XAUTH client with
+
+ xauth=client
+
+or as an XAUTH server with
+
+ xauth=server
+
+with xauth=client being the default value. strongSwan integrates a default
+implementation where the XAUTH user credentials are stored on both the
+server and the client in the /etc/ipsec.secrets file, using the syntax
+
+ : XAUTH john "rT6q!V2p"
+
+The client must not have more than one XAUTH entry whereas the server can
+contain an unlimited number of user credentials in ipsec.secrets.
+
+Either the prompting on the client side or the verification of the user
+credentials on the server side can be implemented as a customized XAUTH
+dynamic library module. The corresponding library interface is defined
+by the pluto/xauth.h header file.
+
+
15. Copyright statement and acknowledgements
----------------------------------------
Copyright (c) 2002, Stephane Laroche
- IKE Mode Config protocol:
+ IKE Mode Config and XAUTH protocol:
Copyright (c) 2001-2002, Colubris Networks
scepclient:
Copyright (c) 2005, Jan Hutter, Martin Willi
- Copyright (c) 2005-2006, Andreas Steffen
+ Copyright (c) 2005-2007, Andreas Steffen
University of Applied Sciences in Rapperswil, Switzerland
for more details.
-----------------------------------------------------------------------------
-This file is RCSID $Id: README,v 1.33 2006/04/24 21:27:49 as Exp $
-
projects / strongswan.git / blobdiff