diff options
| author | Martin Willi <martin@strongswan.org> | 2006-04-28 09:07:55 +0000 |
|---|---|---|
| committer | Martin Willi <martin@strongswan.org> | 2006-04-28 09:07:55 +0000 |
| commit | 83cb0b0e8cc1e97efdbf53c4e0a14121aef08b42 (patch) | |
| tree | 62b5b705196fdaf9d647199b700db7a7c359ccca /README | |
| parent | a06e45dc9c91c96954505dfcee52e734742618a4 (diff) | |
| download | strongswan-83cb0b0e8cc1e97efdbf53c4e0a14121aef08b42.tar.bz2 strongswan-83cb0b0e8cc1e97efdbf53c4e0a14121aef08b42.tar.xz | |
Diffstat (limited to 'README')
| -rw-r--r-- | README | 3091 |
1 files changed, 0 insertions, 3091 deletions
diff --git a/README b/README deleted file mode 100644 index d40d887a3..000000000 --- a/README +++ /dev/null @@ -1,3091 +0,0 @@ - ---------------------------- - strongSwan - Configuration - ---------------------------- - - -Contents --------- - - 1. Overview - 2. Quickstart - 2.1 Site-to-Site case - 2.2 Host-to-Host case - 2.3 Four Tunnel case - 2.4 Four Tunnel case the elegant way with source routing - 2.5 Roadwarrior case - 2.6 Roadwarrior case with virtual IP - 3. Generating X.509 certificates and CRLs with OpenSSL - 3.1 Generating a CA certificate - 3.2 Generating a host or user certificate - 3.3 Generating a CRL - 3.4 Revoking a certificate - 4. Configuring the connections - ipsec.conf - 4.1 Configuring my side - 4.2 Multiple certificates - 4.3 Configuring the peer side using CA certificates - 4.4 Handling Virtual IPs and wildcard subnets - 4.5 Protocol and port selectors - 4.6 IPsec policies based on wildcards - 4.7 IPsec policies based on CA certificates - 4.8 Sending certificate requests - 4.9 IPsec policies based on group attributes - 5. Configuring certificates and CRLs - 5.1 Installing CA certificates - 5.2 Installing optional Certificate Revocation Lists (CRLs) - 5.3 Dynamic update of certificates and CRLs - 5.4 Local caching of CRLs - 5.5 Online Certificate Status Protocol (OCSP) - 5.6 CRL policy - 5.7 Configuring the peer side using locally stored certificates - 6. Configuring the private keys - ipsec.secrets - 6.1 Loading private key files in PKCS#1 format - 6.2 Entering passphrases interactively - 6.3 Multiple private keys - 7. Configuring CA properties - ipsec.conf - 8. Smartcard support - 8.1 Configuring a smartcard-based connection - 8.2 Entering the PIN code - 8.3 PIN-pad equipped smartcard readers - 8.4 Configuring a smartcard using pkcs15-init - 8.5 PKCS#1 proxy functions - 9. Configuring the clients - 9.1 strongSwan - 9.2 PGPnet - 9.3 Safenet/Soft-Remote - 9.4 SSH Sentinel - 9.5 Windows 2000/XP - 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.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 - 13.1 OpenPGP certificates - 13.2 OpenPGP private keys - 13.3 Monitoring functions - 13.4 Suppression of certificate request messages - 14. Additional features - 14.1 Authentication and encryption algorithms - 14.2 NAT traversal - 14.3 Dead peer detection - 14.4 IKE Mode Config - 15. Copyright statement and acknowledgements - - -1. Overview - -------- - -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. - - * strong 3DES, AES, Serpent, Twofish, or Blowfish encryption. - - * Authentication based on X.509 certificates or preshared secrets. - - * IPsec policies based on wildcards or intermediate CAs. - - * Powerful and flexible IPsec policies based on group attributes. - - * Retrieval of Certificate Revocation Lists (CRLs) via HTTP or LDAP. - - * Local caching of fetched CRLs - - * Full support of the Online Certificate Status Protocol (OCSP, RFC 2560). - - * CA management functions including OCSP and CRL URIs and default LDAP server. - - * Optional storage of RSA private keys on smartcards or USB crypto tokens - - * Standardized PKCS#11 interface with optional proxy functions serving - external applications (disc encryption, etc.). - - * NAT-Traversal (RFC 3947) - - * Support of Virtual IPs via static configuratin and IKE Mode Config - - * Support of Delete SA and informational Notification messages. - - * Dead Peer Detection (DPD, RFC 3706) - -Compatibility has successfully been tested with peers running the following -IPsec clients: - - FreeS/WAN, Openswan, SafeNet/SoftRemote, NCP Secure Entry Client, - SonicWALL Global VPN Client, The GreenBow, Microsoft Windows 2000/XP, etc. - -Furthermore, interoperability with the following VPN gateways -has been demonstrated during the IPsec 2001 Conference in Paris: - - Cisco IOS Routers, Cisco PIX firewall, Cisco VPN3000, - Nortel Contivity VPN Switch, NetScreen (FreeS/WAN as responder only), - OpenBSD with isakmpd, Netasq, Netcelo, and 6WIND. - -Potentially any IPsec implementation with X.509 certificate support can -be made to cooperate with strongSwan. The latest addition has been the successful -interoperability with the Check Point VPN-1 NG gateway. - - -2. Quickstart - ---------- - -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 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. - - -2.1 Site-to-site case - ----------------- - -In this scenario two security gateways moon and sun will connect the -two subnets moon-net and sun-net with each other through a VPN tunnel -set up between the two gateways: - - 10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16 - moon-net moon sun sun-net - -Configuration on gateway moon: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/moonCert.pem - - /etc/ipsec.secrets: - - : RSA moonKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn net-net - left=%defaultroute - leftsubnet=10.1.0.0/16 - leftcert=moonCert.pem - right=192.168.0.2 - rightsubnet=10.2.0.0/16 - rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" - auto=start - -Configuration on gateway sun: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/sunCert.pem - - /etc/ipsec.secrets: - - : RSA sunKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn net-net - left=%defaultroute - leftsubnet=10.2.0.0/16 - leftcert=sunCert.pem - right=192.168.0.1 - rightsubnet=10.1.0.0/16 - rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" - auto=start - - -2.2 Host-to-host case - ----------------- - -This is a setup between two single hosts which don't have a subnet behind -them. Although IPsec transport mode would be sufficient for host-to-host -connections we will use the default IPsec tunnel mode. - - | 192.168.0.1 | === | 192.168.0.2 | - moon sun - -Configuration on host moon: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/moonCert.pem - - /etc/ipsec.secrets: - - : RSA moonKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn host-host - left=%defaultroute - leftcert=moonCert.pem - right=192.168.0.2 - rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" - auto=start - -Configuration on host sun: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/sunCert.pem - - /etc/ipsec.secrets: - - : RSA sunKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn host-host - left=%defaultroute - leftcert=sunCert.pem - right=192.168.0.1 - rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" - auto=start - - -2.3 Four Tunnel case - ---------------- - -In a site-to-site setup a system administrator logged into the local gateway -often would like to access the peer gateway or a server in the subnet behind -the peer gateway over a secure IPsec tunnel.Since IP packets leaving a gateway -via the outer network interface carry the IP address of this NIC, four IPsec -Security Associations (SAs) must be set up to achieve full connectivity. The -example below shows how this can be done without much additional typing work , -using the "also" macro which includes connection definitions defined farther -down in the ipsec.conf file. - - 10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16 - moon-net moon sun sun-net - -Configuration on gateway moon: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/moonCert.pem - - /etc/ipsec.secrets: - - : RSA moonKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn net-net - leftsubnet=10.1.0.0/16 - rightsubnet=10.2.0.0/16 - also host-host - - conn net-host - leftsubnet=10.1.0.0/16 - also host-host - - conn host-net - rightsubnet=10.2.0.0/16 - also host-host - - conn host-host - left=%defaultroute - leftcert=moonCert.pem - right=192.168.0.2 - rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" - auto=start - -Configuration on gateway sun: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/sunCert.pem - - /etc/ipsec.secrets: - - : RSA sunKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn net-net - leftsubnet=10.2.0.0/16 - rightsubnet=10.1.0.0/16 - also=host-host - - conn net-host - leftsubnet=10.2.0.0/16 - also=host-host - - conn host-net - rightsubnet=10.1.0.0/16 - also=host-host - - conn host-host - left=%defaultroute - leftcert=sunCert.pem - right=192.168.0.1 - rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" - auto=start - - -2.4 The four tunnel case the elegant way with source routing - -------------------------------------------------------- - -As you certainly agree, the full four tunnel case described in the previous -section becomes quite complex. If we could force the source address of the -IP packets leaving the gateway through the outer interface to take on the -IP address of the inner interface then we could use the single subnet-to-subnet -tunnel from section 2.1. Such a setup becomes possible if we use the -source routing capabilites of the ip route command that is already used -by strongSwan's updown scripts. - - 10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16 - moon-net moon sun sun-net - -If we assume that the inner IP address of gateway moon is 10.1.0.1 -and the inner IP address of gateway sun is 10.2.0.1 then the -insertion of the parameter - - leftsourceip=10.1.0.1 - -in the connection definition of moon and - - leftsourceip=10.2.0.1 - -on sun, respectively, will install source routing on both gateways. -As a result the command - - ping 10.2.0.1 - -executed on moon will leave the gateway with a source address of -10.1.0.1 and will therefore take the net-net IPsec tunnel. - -Configuration on gateway moon: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/moonCert.pem - - /etc/ipsec.secrets: - - : RSA moonKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn net-net - left=%defaultroute - leftsourceip=10.1.0.1 - leftsubnet=10.1.0.0/16 - leftcert=moonCert.pem - right=192.168.0.2 - rightsubnet=10.2.0.0/16 - rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" - auto=start - -Configuration on gateway sun: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/sunCert.pem - - /etc/ipsec.secrets: - - : RSA sunKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn net-net - left=%defaultroute - leftsubnet=10.2.0.0/16 - leftsourceip=10.2.0.1 - leftcert=sunCert.pem - right=192.168.0.1 - rightsubnet=10.1.0.0/16 - rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" - auto=start - - -2.5 Roadwarrior case - ---------------- - -This is a very common case where a strongSwan gateway serves an arbitrary number -of remote VPN clients usually having dynamic IP addresses. - - 10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | - moon-net moon carol - -Configuration on gateway moon: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/moonCert.pem - - /etc/ipsec.secrets: - - : RSA moonKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn rw - left=%defaultroute - leftsubnet=10.1.0.0/16 - leftcert=moonCert.pem - right=%any - auto=add - -Configuration on roadwarrior carol: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/carolCert.pem - - /etc/ipsec.secrets: - - : RSA carolKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn home - left=%defaultroute - leftcert=carolCert.pem - right=192.168.0.1 - rightsubnet=10.1.0.0/16 - rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" - auto=start - - -2.6 Roadwarrior case with virtual IP - -------------------------------- - -Roadwarriors usually have dynamic IP addresses assigned by the ISP they are -currently attached to. In order to simplify the routing from moon-net back -to the remote access client carol it would be desirable if the roadwarrior had -an inner IP address chosen from a pre-assigned pool. - - 10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | -- 10.3.0.1 - moon-net moon carol virtual IP - -This virtual IP address can be assigned to a strongSwan roadwarrior by adding -the parameter - - leftsourceip=10.3.0.1 - -to the roadwarrior's ipsec.conf. Of course the virtual IP of each roadwarrior -must be distinct. In our example it is chosen from the address pool - - rightsubnetwithin=10.3.0.0/16 - -which can be added to the gateway's ipsec.conf so that a single connection -definition can handle multiple roadwarriors. - -Configuration on gateway moon: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/moonCert.pem - - /etc/ipsec.secrets: - - : RSA moonKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn rw - left=%defaultroute - leftsubnet=10.1.0.0/16 - leftcert=moonCert.pem - right=%any - rightsubnetwithin=10.3.0.0/16 - auto=add - -Configuration on roadwarrior carol: - - /etc/ipsec.d/cacerts/strongswanCert.pem - - /etc/ipsec.d/certs/carolCert.pem - - /etc/ipsec.secrets: - - : RSA carolKey.pem "<optional passphrase>" - - /etc/ipsec.conf: - - conn home - left=%defaultroute - leftsourceip=10.3.0.1 - leftcert=carolCert.pem - right=192.168.0.1 - rightsubnet=10.1.0.0/16 - rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" - auto=start - - -3. Generating certificates and CRLs with OpenSSL - --------------------------------------------- - -This section is not a full-blown tutorial on how to use OpenSSL. It just lists -a few points that are relevant if you want to generate your own certificates -and CRLs for use with strongSwan. - - -3.1 Generating a CA certificate - --------------------------- - -The OpenSSL statement - - openssl req -x509 -days 1460 -newkey rsa:2048 \ - -keyout strongswanKey.pem -out strongswanCert.pem - -creates a 2048 bit RSA private key strongswanKey.pem and a self-signed CA -certificate strongswanCert.pem with a validity of 4 years (1460 days). - - openssl x509 -in cert.pem -noout -text - -lists the properties of a X.509 certificate cert.pem. It allows you to verify -whether the configuration defaults in openssl.cnf have been inserted correctly. - -If you prefer the CA certificate to be in binary DER format then the following -command achieves this transformation: - - openssl x509 -in strongswanCert.pem -outform DER -out strongswanCert.der - -The directory /etc/ipsec.d/cacerts contains all required CA certificates either -in binary DER or in base64 PEM format. Irrespective of the file suffix, Pluto -"automagically" determines the correct format. - - -3.2 Generating a host or user certificate - ------------------------------------- - -The OpenSSL statement - - openssl req -newkey rsa:1024 -keyout hostKey.pem \ - -out hostReq.pem - -generates a 1024 bit RSA private key hostKey.pem and a certificate request -hostReq.pem which has to be signed by the CA. - -If you want to add a subjectAltName field to the host certificate you must edit -the OpenSSL configuration file openssl.cnf and add the following line in the -[ usr_cert ] section: - - subjectAltName=DNS:moon.strongswan.org - -if you want to identify the host by its Fully Qualified Domain Name (FQDN ), or - - subjectAltName=IP:192.168.0.1 - -if you want the ID to be of type IPV4_ADDR. Of course you could include both -ID types with - - subjectAltName=DNS:moon.strongswan.org,IP:192.168.0.1 - -but the use of an IP address for the identification of a host should be -discouraged anyway. - -For user certificates the appropriate ID type is USER_FQDN which can be -specified as - - subjectAltName=email:carol@strongswan.org - -or if the user's e-mail address is part of the subject's distinguished name - - subjectAltName=email:copy - -Now the certificate request can be signed by the CA with the command - - openssl ca -in hostReq.pem -days 730 -out hostCert.pem -notext - -If you omit the -days option then the default_days value (365 days) specified -in openssl.cnf is used. The -notext option avoids that a human readable -listing of the certificate is prepended to the base64 encoded certificate -body. - -If you want to use the dynamic CRL fetching feature described in section 4.7 -then you may include one or several crlDistributionPoints in your end -certificates. This can be done in the [ usr_cert ] section of the openssl.cnf -configuration file: - - crlDistributionPoints= @crl_dp - - [ crl_dp ] - - URI.1="http://crl.strongswan.org/strongswan.crl" - URI.2="ldap://ldap.strongswan.org/cn=strongSwan Root CA, o=Linux strongSwan - , c=CH?certificateRevocationList" - -If you have only a single http distribution point then the short form - - crlDistributionPoints="URI:http://crl.strongswan.org/strongswan.crl" - -also works. Due to a known bug in OpenSSL this notation fails with ldap URIs. - -Usually a Windows-based VPN client needs its private key, its host or -user certificate, and the CA certificate. The most convenient way to load -this information is to put everything into a PKCS#12 file: - - openssl pkcs12 -export -inkey carolKey.pem \ - -in carolCert.pem -name "carol" \ - -certfile strongswanCert.pem -caname "strongSwan Root CA" \ - -out carolCert.p12 - - -3.3 Generating a CRL - ---------------- - -An empty CRL that is signed by the CA can be generated with the command - - openssl ca -gencrl -crldays 15 -out crl.pem - -If you omit the -crldays option then the default_crl_days value (30 days) -specified in openssl.cnf is used. - -If you prefer the CRL to be in binary DER format then this conversion -can be achieved with - - openssl crl -in crl.pem -outform DER -out cert.crl - -The directory /etc/ipsec.d/crls contains all CRLs either in binary DER -or in base64 PEM format. Irrespective of the file suffix, Pluto -"automagically" determines the correct format. - - -3.4 Revoking a certificate - ---------------------- - -A specific host certificate stored in the file host.pem is revoked with the -command - - openssl ca -revoke host.pem - -Next the CRL file must be updated - - openssl ca -gencrl -crldays 60 -out crl.pem - -The content of the CRL file can be listed with the command - - openssl crl -in crl.pem -noout -text - -in the case of a base64 CRL, or alternatively for a CRL in DER format - - openssl crl -inform DER -in cert.crl -noout -text - - - -4. Configuring the connections - ipsec.conf - ---------------------------------------- - -4.1 Configuring my side - ------------------- - -Usually the local side is the same for all connections. Therefore it makes -sense to put the definitions characterizing the strongSwan security gateway into -the conn %default section of the configuration file /etc/ipsec.conf. If we -assume throughout this document that the strongSwan security gateway is left and -the peer is right then we can write - -conn %default - # my side is left - the freeswan security gateway - left=%defaultroute - leftcert=moonCert.pem - # load connection definitions automatically - auto=add - -The X.509 certificate by which the strongSwan security gateway will authenticate -itself by sending it in binary form to its peers as part of the Internet Key -Exchange (IKE) is specified in the line - - leftcert=moonCert.pem - -The certificate can either be stored in base64 PEM-format or in the binary -DER-format. Irrespective of the file suffix, Pluto "automagically" determines -the correct format. Therefore - - leftcert=moonCert.der - -or - - leftcert=moonCert.cer - -would also be valid alternatives. - -When using relative pathnames as in the examples above, the certificate files -must be stored in in the directory /etc/ipsec.d/certs. In order to distinguish -strongSwan's own certificates from locally stored trusted peer certificates -(see section 5.5 for details), they could also be stored in a subdirectory -below /etc/ipsec.d/certs as e.g. in - - leftcert=mycerts/moonCert.pem - -Absolute pathnames are also possible as in - - leftcert=/usr/ssl/certs/moonCert.pem - -As an ID for the VPN gateway we recommend the use of a Fully Qualified Domain -Name (FQDN) of the form - -conn rw - right=%any - leftid=@moon.strongswan.org - -Important: When an FQDN identifier is used it must be explicitly included as a -so called subjectAltName of type dnsName (DNS:) in the certificate indicated -by leftcert. For details on how to generate certificates with subjectAltNames, -please refer to section 7.2. - -If you don't want to mess with subjectAltNames, you can use the certificate's -Distinguished Name (DN) instead, which is an identifier of type DER_ASN1_DN -and which can be written e.g. in the LDAP-type format - -conn rw - right=%any - leftid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" - -Since the subject's DN is part of the certificate, the leftid does not have to -be declared explicitly. Thus the entry - -conn rw - right=%any - -automatically assumes the subject DN of leftcert to be the host ID. - - -4.2 Multiple certificates - --------------------- - -strongSwan supports multiple local host certificates and corresponding -RSA private keys: - -conn rw1 - right=%any - rightid=@peer1.domain1 - leftcert=myCert1.pem - # leftid is DN of myCert1 - -conn rw2 - right=%any - rightid=@peer2.domain2 - leftcert=myCert2.pem - # leftid is DN of myCert2 - -When peer1 initiates a connection then strongSwan will send myCert1 and will -sign with myKey1 defined in /etc/ipsec.secrets (see section 6.2) whereas -myCert2 and myKey2 will be used in a connection setup started from peer2. - - -4.3 Configuring the peer side using CA certificates - ----------------------------------------------- - -Now we can proceed to define our connections. In many applications we might -have dozens of mostly Windows-based road warriors connecting to a central -strongSwan security gateway. The following most simple statement: - -conn rw - right=%any - -defines the general roadwarrior case. The line right=%any literally means that -any IPSec peer is accepted, regardless of its current IP source address and its -ID, as long as the peer presents a valid X.509 certificate signed by a CA the -strongSwan security gateway puts explicit trust in. Additionally the signature -during IKE main mode gives proof that the peer is in possession of the private -RSA key matching the public key contained in the transmitted certificate. - -The ID by which a peer is identifying itself during IKE main mode can by any of -the ID types IPV4_ADDR, FQDN, USER_FQDN or DER_ASN1_DN. If one of the first -three ID types is used, then the accompanying X.509 certificate of the peer -must contain a matching subjectAltName field of the type ipAddress (IP:), -dnsName (DNS:) or rfc822Name (email:), respectively. With the fourth type -DER_ASN1_DN the identifier must completely match the subject field of the -peer's certificate. One of the two possible representations of a -Distinguished Name (DN) is the LDAP-type format - - rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" - -Additional whitespace can be added everywhere as desired since it will be -automatically eliminated by the X.509 parser. An exception is the single -whitespace between individual words , like e.g. in Linux strongSwan, which is -preserved by the parser. - -The Relative Distinguished Names (RDNs) can alternatively be separated by a -slash '/' instead of a comma ',' - - rightid="/C=CH/O=Linux strongSwan/CN=sun.strongswan.org" - -This is the representation extracted from the certificate by the OpenSSL -command line option - - openssl x509 -in sunCert.pem -noout -subject - -The following RDNs are supported by strongSwan - -+---------------------------------------------------+ -| DC Domain Component | -|---------------------------------------------------| -| C Country | -|---------------------------------------------------| -| ST State or province | -|---------------------------------------------------| -| L Locality or town | -|---------------------------------------------------| -| O Organisation | -|---------------------------------------------------| -| OU Organisational Unit | -|---------------------------------------------------| -| CN Common Name | -|---------------------------------------------------| -| ND NameDistinguisher, used with CN | -|---------------------------------------------------| -| N Name | -|---------------------------------------------------| -| G Given name | -|---------------------------------------------------| -| S Surname | -|---------------------------------------------------| -| I Initials | -|---------------------------------------------------| -| T Personal title | -|---------------------------------------------------| -| E E-mail | -|---------------------------------------------------| -| Email E-mail | -|---------------------------------------------------| -| emailAddress E-mail | -|---------------------------------------------------| -| SN Serial number | -|---------------------------------------------------| -| serialNumber Serial number | -|---------------------------------------------------| -| D Description | -|---------------------------------------------------| -| ID X.500 Unique Identifier | -|---------------------------------------------------| -| UID User ID | -|---------------------------------------------------| -| TCGID [Siemens] Trust Center Global ID | -|---------------------------------------------------| -| unstructuredName Unstructured Name | -|---------------------------------------------------| -| UN Unstructured Name | -|---------------------------------------------------| -| employeeNumber Employee Number | -|---------------------------------------------------| -| EN Employee Number | -+---------------------------------------------------+ - -With the roadwarrior connection definition listed above, an IPsec SA for -the strongSwan security gateway moon.strongswan.org itself can be established. -If any roadwarrior should be able to reach e.g. the two subnets 10.1.0.0/24 -and 10.1.3.0/24 behind the security gateway then the following connection -definitions will make this possible - -conn rw1 - right=%any - leftsubnet=10.1.0.0/24 - -conn rw3 - right=%any - leftsubnet=10.1.3.0/24 - -If not all peers in possession of a X.509 certificate signed by a specific -certificate authority shall be given access to the Linux security gateway, -then either a subset of them can be barred by listing the serial numbers of -their certificates in a certificate revocation list (CRL) as specified in -section 5.2 or as an alternative, access can be controlled by explicitly -putting a roadwarrior entry for each eligible peer into ipsec.conf: - -conn sun - right=%any - rightid=@sun.strongswan.org - -conn carol - right=%any - rightid=carol@strongswan.org - -conn dave - right=%any - rightid="C=CH, O=Linux strongSwan, CN=dave@strongswan.org" - -When the IP address of a peer is known to be stable, it can be specified as -well. This entry is mandatory when the strongSwan host wants to act as the -initiator of an IPSec connection. - -conn sun - right=192.168.0.2 - rightid=@sun.strongswan.org - -conn carol - right=192.168.0.100 - rightid=carol@strongswan.org - -conn dave - right=192.168.0.200 - rightid="C=CH, O=Linux strongSwan, CN=dave@strongswan.org" - -conn venus - right=192.168.0.50 - -In the last example the ID types FQDN, USER_FQDN, DER_ASN1_DN and IPV4_ADDR, -respectively, were used. Of course all connection definitions presented so far -have included the lines in the conn %defaults section, comprising among other -a left and leftcert entry. - - -4.4 Handling Virtual IPs and wildcard subnets - ----------------------------------------- - -Often roadwarriors are behind NAT-boxes with IPsec passthrough, which causes -the inner IP source address of an IPsec tunnel to be different from the -outer IP source address usually assigned dynamically by the ISP. -Whereas the varying outer IP address can be handled by the right=%any -construct, the inner IP address or subnet must always be declared in a -connection definition. Therefore for the three roadwarriors rw1 to rw3 -connecting to a strongSwan security gateway the following entries are -required in /etc/ipsec.conf: - -conn rw1 - right=%any - righsubnet=10.4.0.5/32 - -conn rw2 - right=%any - rightsubnet=10.4.0.47/32 - -conn rw3 - right=%any - rightsubnet=10.4.0.128/28 - -With the wildcard parameter rightsubnetwithin these three entries can be -reduced to the single connection definition - -conn rw - right=%any - rightsubnetwithin=10.4.0.0/24 - -Any host will be accepted (of course after successful authentication based on -the peer's X.509 certificate only) if it declares a client subnet lying totally -within the brackets defined by the wildcard subnet definition (in our example -10.4.0.0/24). For each roadwarrior a connection instance tailored to the -subnet of the particular client will be created,based on the generic -rightsubnetwithin template. - -This strongSwan feature can also be helpful with VPN clients getting a -dynamically assigned inner IP from a DHCP server located on the NAT router box. - - -4.5 Protocol and Port Selectors - --------------------------- - -strongSwan offer the possibility to restrict the protocol and optionally the -ports in an IPsec SA using the rightprotoport and leftprotoport parameters. - -Some examples: - -conn icmp - right=%any - rightprotoport=icmp - left=%defaultroute - leftid=@moon.strongswan.org - leftprotoport=icmp - -conn http - right=%any - rightprotoport=6 - left=%defaultroute - leftid=@moon.strongswan.org - leftprotoport=6/80 - -conn l2tp # with port wildcard for Mac OS X Panther interoperability - right=%any - rightprotoport=17/%any - left=%defaultroute - leftid=@moon.strongswan.org - leftprotoport=17/1701 - -conn dhcp - right=%any - rightprotoport=udp/bootpc - left=%defaultroute - leftid=@moon.strongswan.org - leftsubnet=0.0.0.0/0 #allows DHCP discovery broadcast - leftprotoport=udp/bootps - rekey=no - keylife=20s - rekeymargin=10s - auto=add - -Protocols and ports can be designated either by their numerical values -or by their acronyms defined in /etc/services. - - ipsec status - -shows the following connection definitions: - -"icmp": 192.168.0.1[@moon.strongswan.org]:1/0...%any:1/0 -"http": 192.168.0.1[@moon.strongswan.org]:6/80...%any:6/0 -"l2tp": 192.168.0.1[@moon.strongswan.org]:17/1701...%any:17/%any -"dhcp": 0.0.0.0/0===192.168.0.1[@moon.strongswan.org]:17/67...%any:17/68 - -Based on the protocol and port selectors appropriate eroutes will be set -up, so that only the specified payload types will pass through the IPsec -tunnel. - - -4.6 IPsec policies based on wildcards - --------------------------------- - -In large VPN-based remote access networks there is often a requirement that -access to the various parts of an internal network must be granted selectively, -e.g. depending on the group membership of the remote access user. strongSwan -makes this possible by applying wildcard filtering on the VPN user's -distinguished name (ID_DER_ASN1_DN). - -Let's make a practical example: - -An organization has a sales department (OU=Sales) and a research group -(OU=Research). In the company intranet there are separate subnets for Sales -(10.0.0.0/24) and Research (10.0.1.0/24) but both groups share a common web -server (10.0.2.100). The VPN clients use Virtual IP addresses that are either -assigned statically or via DHCP-over-IPsec. The sales and research departments -use IP addresses from separate DHCP address pools (10.1.0.0/24) and (10.1.1.0/24), -respectively. An X.509 certificate is issued to each employee, containing in its -subject distinguished name the country (C=CH), the company (O=ACME), -the group membership(OU=Sales or OU=Research) and the common name (e.g. -CN=Bart Simpson). - -The IPsec policy defined above can now be enforced with the following three -IPsec security associations: - -conn sales - right=%any - rightid="C=CH, O=ACME, OU=Sales, CN=*" - rightsubnetwithin=10.1.0.0/24 # Sales DHCP range - leftsubnet=10.0.0.0/24 # Sales subnet - -conn research - right=%any - rightid="C=CH, O=ACME, OU=Research, CN=*" - rightsubnetwithin=10.1.1.0/24 # Research DHCP range - leftsubnet=10.0.1.0/24 # Research subnet - -conn web - right=%any - rightid="C=CH, O=ACME, OU=*, CN=*" - rightsubnetwithin=10.1.0.0/23 # Remote access DHCP range - leftsubnet=10.0.2.100/32 # Web server - rightprotoport=tcp # TCP protocol only - leftprotoport=tcp/http # TCP port 80 only - -Of course group specific tunneling could be implemented on the -basis of the Virtual IP range specified by the rightsubnetwithin -parameter alone, but the wildcard matching mechanism guarantees that -only authorized user can access the corresponding subnets. - -The '*' character is used as a wildcard in relative distinguished names (RDNs). -In order to match a wildcard template, the ID_DER_ASN1_DN of a peer must contain -the same number of RDNs (selected from the list in section 4.3) appearing in the -exact order defined by the template. - - "C=CH, O=ACME, OU=Research, OU=Special Effects, CN=Bart Simpson" - -matches the templates - - "C=CH, O=ACME, OU=Research, OU=*, CN=*" - - "C=CH, O=ACME, OU=*, OU=Special Effects, CN=*" - - "C=CH, O=ACME, OU=*, OU=*, CN=*" - -but not the template - - "C=CH, O=ACME, OU=*, CN=*" - -which doesn't have the same number of RDNs. - - -4.7 IPsec policies based on CA certificates - --------------------------------------- - -As an alternative to the wildcard based IPsec policies described in section 4.6, -access to specific client host and subnets can abe controlled on the basis of -the CA that issued the peer certificate - - -conn sales - right=%any - rightca="C=CH, O=ACME, OU=Sales, CN=Sales CA" - rightsubnetwithin=10.1.0.0/24 # Sales DHCP range - leftsubnet=10.0.0.0/24 # Sales subnet - -conn research - right=%any - rightca="C=CH, O=ACME, OU=Research, CN=Research CA" - rightsubnetwithin=10.1.1.0/24 # Research DHCP range - leftsubnet=10.0.1.0/24 # Research subnet - -conn web - right=%any - rightca="C=CH, O=ACME, CN=ACME Root CA" - rightsubnetwithin=10.1.0.0/23 # Remote access DHCP range - leftsubnet=10.0.2.100/32 # Web server - rightprotoport=tcp # TCP protocol only - leftprotoport=tcp/http # TCP port 80 only - -In the example above, the connection "sales" can be used by peers -presenting certificates issued by the Sales CA, only. In the same way, -the use of the connection "research" is restricted to owners of certificates -issued by the Research CA. The connection "web" is open to both "Sales" and -"Research" peers because the required "ACME Root CA" is the issuer of the -Research and Sales intermediate CAs. If no rightca parameter is present -then any valid certificate issued by one of the trusted CAs in -/etc/ipsec.d/cacerts can be used by the peer. - -The leftca parameter usually doesn't have to be set explicitly because -by default it is set to the issuer field of the certificate loaded via -leftcert. The statement - - rightca=%same - -sets the CA requested from the peer to the CA used by the left side itself -as e.g. in - -conn sales - right=%any - rightca=%same - leftcert=mySalesCert.pem - - -4.8 Sending certificate requests - ---------------------------- - -The presence of a rightca parameter also causes the CA to be sent as -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’s certificate request message. - - -4.9 IPsec policies based on group attributes - ---------------------------------------- - -X.509 attribute certificates are the most powerful mechanism for implementing -IPsec security policies. The rightgroups parameter in a connection definition -restricts the access to members of the listed groups only. An IPsec peer must -have a valid attribute certificate issued by a trusted Authorization Authority -and listing one of the requirede group attributes in order to get admitted. - -conn sales - right=%any - rightgroups="Sales" - rightsubnetwithin=10.1.0.0/24 # Sales DHCP range - leftsubnet=10.0.0.0/24 # Sales subnet - -conn research - right=%any - rightgroups="Research" - rightsubnetwithin=10.1.1.0/24 # Research DHCP range - leftsubnet=10.0.1.0/24 # Research subnet - -conn web - right=%any - rightgroups="Sales, Research" - rightsubnetwithin=10.1.0.0/23 # Remote access DHCP range - leftsubnet=10.0.2.100/32 # Web server - rightprotoport=tcp # TCP protocol only - leftprotoport=tcp/http # TCP port 80 only - -In the examples above membership of the group "Sales" is required for -connection sales and membership of "Research" for connection research -whereas connection web is accessible for both groups. - -Currently the attribute certificates of the peers must be loaded statically -via the /etc/ipsec.d/acerts/ directory. In future releases of strongSwan it -will be possible to fetch them from an LDAP directory server. - - -5. Configuring certificates and CRLs - --------------------------------- - - -5.1 Installing the CA certificates - ------------------------------ - -X.509 certificates received by strongSwan during the IKE protocol are -automatically authenticated by going up the trust chain until a self-signed -root CA certificate is reached. Usually host certificates are directly signed -by a root CA, but strongSwan also supports multi-level hierarchies with -intermediate CAs in between. All CA certificates belonging to a trust chain -must be copied in either binary DER or base64 PEM format into the directory - - /etc/ipsec.d/cacerts/ - - -5.2 Installing optional certificate revocation lists (CRLs) - ------------------------------------------------------- - -By copying a CA certificate into /etc/ipsec.d/cacerts/, automatically all user -or host certificates issued by this CA are declared valid. Unfortunately -private keys might get compromised inadvertently or intentionally, personal -certificates of users leaving a company have to be blocked immediately, etc. -To this purpose certificate revocation lists (CRLs) have been created. CRLs -contain the serial numbers of all user or host certificates that have been -revoked due to various reasons. - -After successful verification of the X.509 trust chain, Pluto searches its -list of CRLs either obtained by loading them from the /etc/ipsec.d/crls/ -directory or fetching them dynamically from a HTTP or LDAP server for the -presence of a CRL issued by the CA that has signed the certificate. - -If the serial number of the certificate is found in the CRL then the public key -contained in the certificate is declared invalid and the IPSec SA will not be -established. If no CRL is found or if the deadline defined in the nextUpdate -field of the CRL has been reached, a warning is issued but the public key will -nevertheless be accepted. CRLs must be stored either in binary DER or base64 PEM -format in the crls directory. Section 7.3 will explain in detail how CRLs can -be created using OpenSSL. - - -5.3 Dynamic update of certificates and CRLs - --------------------------------------- - -Pluto reads certificates and CRLs from their respective files during system -startup and keeps them in memory in the form of chained lists. X.509 -certificates have a finite life span defined by their validity field. Therefore -it must be possible to replace CA or OCSP certificates kept in system memory -without disturbing established ISAKMP SAs. Certificate revocation lists should -also be updated in the regular intervals indicated by the nextUpdate field in -the CRL body. The following interactive commands allow the manual replacement -of the various files: - -+---------------------------------------------------------------------------+ -| ipsec rereadsecrets reload file /etc/ipsec.secrets | -|---------------------------------------------------------------------------| -| ipsec rereadcacerts reload all files in /etc/ipsec.d/cacerts/ | -|---------------------------------------------------------------------------| -| ipsec rereadaacerts reload all files in /etc/ipsec.d/aacerts/ | -|---------------------------------------------------------------------------| -| ipsec rereadocspcerts reload all files in /etc/ipsec.d/ocspcerts/ | -|---------------------------------------------------------------------------| -| ipsec rereadacerts reload all files in /etc/ipsec.d/acerts/ | -|---------------------------------------------------------------------------| -| ipsec rereadcrls reload all files in /etc/ipsec.d/crls/ | -|---------------------------------------------------------------------------| -| ipsec rereadall ipsec rereadsecrets | -| rereadcacerts | -| rereadaacerts | -| rereadocspcerts | -| rereadacerts | -| rereadcrls | -|---------------------------------------------------------------------------| -| ipsec purgeocsp purge the OCSP cache and fetching requests | -+---------------------------------------------------------------------------+ - -CRLs can also be automatically fetched from an HTTP or LDAP server by using -the CRL distribution points contained in X.509 certificates. The command - - ipsec listcrls - -shows any pending fetch requests: - - Oct 31 00:29:53 2002, trials: 2 - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - distPts: 'http://crl.strongswan.org/strongswan.crl' - 'ldap://ldap.strongswan.org/o=Linux strongSwan, c=CH - ?certificateRevocationList?base - ?(objectClass=certificationAuthority)' - -In the example above, an http and an ldap URL were extracted from a received -end certificate. An independent thread then tries to fetch a CRL from the -designated distribution points. The same thread also periodically checks -if any loaded CRLs are about to expire. The check interval can be defined in -the "config setup" section of the ipsec.conf file: - - config setup - crlcheckinterval=600 - -In our example the thread wakes up every 600 seconds or 10 minutes in order -to check the validity of the CRLs or to retry any pending fetch requests: - - List of X.509 CRLs: - - Dec 19 09:35:31 2002, revoked certs: 40 - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - distPts: 'http://crl.strongswan.org/strongswan.crl' - updates: this Dec 19 09:35:00 2002 - next Dec 19 10:35:00 2002 warning (expires in 19 minutes) - - List of fetch requests: - - Dec 19 10:15:31 2002, trials: 1 - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - distPts: 'http://crl.strongwan.org/strongswan.crl' - -The first trial to update a CRL is started 2*crlcheckinterval before the -nextUpdate time, i.e. when less than 20 minutes are left in our practical -example. When crlcheckinterval is set to 0 (this is also the default value -when the parameter is not set in ipsec.conf) then the CRL checking and updating -thread is not started and dynamic CRL fetching is disabled. - - -5.4 Local caching of CRLs - --------------------- - -The the ipsec.conf option - - config setup - cachecrls=yes - -activates the local caching of CRLs that were dynamically fetched from an -HTTP or LDAP server. Cached copies are stored in /etc/ipsec.d/crls under a -unique filename formed from the issuer's SubjectKeyIdentifier and the suffix .crl. - -With the cached copy the CRL is immediately available after pluto's startup. -When the local copy is about to expire it is automatically replaced with an -updated CRL fetched from one of the defined CRL distribution points. - - -5.5 Online Certificate Status Protocol (OCSP) - ----------------------------------------- - -The Online Certificate Status Protocol is defined by RFC 2560. It can be -used to query an OCSP server about the current status of an X.509 certificate -and is often used as a more dynamic alternative to a static Certificate -Revocation List (CRL). Both the OCSP request sent by the client and the OCSP -response messages returned by the server are transported via a standard -TCP/HTTP connection. Therefore cURL support must be enabled in pluto/Makefile: - - # Uncomment this line to enable OCSP fetching using HTTP - LIBCURL=1 - -In the simplest OCSP setup, a default URI under which the OCSP server for a -given CA can be accessed is defined in ipsec.conf: - - config setup - crlcheckinterval=600 - - ca strongswan - cacert=strongswanCert.pem - ocspuri=http://ocsp.strongswan.org:8880 - auto=add - -The HTTP port can be freely chosen. In our example we have assumed TCP port 8880. -The crlcheckinterval must be set to a value different from zero. Otherwise the -OCSP fetching thread will not be started. - -The well-known openssl-0.9.7 package from http://www.openssl.org implements -an OCSP server that can be used in conjunction with an openssl-based Public -Key Infrastructure. The OCSP client integrated into Pluto does not contain -any OpenSSL code though, but is based on the existing ASN.1 functionality of -strongSwan. - -The OpenSSL-based OCSP server is started with the following command: - - openssl ocsp -index index.txt -CA strongswanCert.pem -port 8880 \ - -rkey ocspKey.pem -rsigner ocspCert.pem \ - -resp_no_certs -nmin 60 -text - -The command consists of the parameters - - -index index.txt is a copy of the OpenSSL index file containing the list of - all issued certificates. The certificate status in indext.txt - is designated either by V for valid or R for revoked. If - a new certificate is added or if a certificate is revoked - using the openssl ca command, the OCSP server must be restarted - in order for the changes in index.txt to take effect. - - -CA the CA certificate - - -port the HTTP port the OCSP server is listening on. - --rkey the private key used to sign the OCSP response. The use of the - sensitive CA private key is not recommended since this could - jeopardize the security of your production PKI if the OCSP - server is hacked. It is much better to generate a special - RSA private key just for OCSP signing use instead. - --rsigner the certificate of the OCSP server containing a public key which - matches the private key defined by -rkey and which can be used by - the client to check the trustworthiness of the signed OCSP response. - --resp_no_certs With this option the OCSP signer certificate defined by - -rsigner is not included in the OCSP response. - --nmin the validity interval of an OCSP response given in minutes. - 2*crlcheckinterval before the expiration of the OCSP responses, - a new query will by pro-actively started by the Pluto fetching thread. - - If nmin is missing or set to zero then the default validity interval - compiled into Pluto will be 2 minutes, leading to a quasi one-time - use of the OCSP status response which will not be periodically - refreshed by the fetching thread. In conjunction with the parameter - setting "strictcrlpolicy=yes" a real-time certificate status query - can be implemented in this way. - --text This option activates a verbose logging output, showing the contents - of both the received OCSP request and sent OCSP response. - -How does Pluto get hold of the OCSP signer certificate? There are two -possibilities: - -Either you put the OCSP certificate into the default directory - - /etc/ipsec.d/ocspcerts - -or alternatively Pluto can receive it as part of the OCSP response from the -remote OCSP server. In the latter case, how can Pluto make sure that -the server has indeed been authorized by the CA to deal out certificate status -information? In order to ascertain the OCSP signer capability, an extended -key usage attribute can be included in the OCSP server certificate. Just -insert the parameter - - extendedKeyUsage=OCSPSigner - -in the [ usr_cert ] section of your openssl.cnf configuration file before -the CA signs the OCSP server certificate. - -For a given CA the corresponding ca section in ipsec.conf (see section 7) allows -to define the URI of a single OCSP server. As an alternative an OCSP URI can be -embedded into each host and user certificate by putting the line - - authorityInfoAccess = OCSP;URI:http://ocsp.strongswan.org:8880 - -into the [ usr_cert ] section of your openssl.cnf configuration file. -If an OCSP authorityInfoAccess extension is present in a certificate then this -record overrides the default URI defined by the ca section. - - -5.6 CRL Policy - ---------- - -By default Pluto is quite tolerant concerning the handling of CRLs. It is not -mandatory for a CRL to be present in /etc/ipsec.d/crls and if the expiration -date defined by the nextUpdate field of a CRL has been reached just a warning -is issued but a peer certificate will always be accepted if it has not been -revoked. - -If you want to enforce a stricter CRL policy then you can do this by setting -the "strictcrlpolicy" option. This is done in the "config setup" section -of the ipsec.conf file: - - config setup - strictcrlpolicy=yes - ... - -A certificate received from a peer will not be accepted if no corresponding -CRL or OCSP response is available. And if an ISAKMP SA re-negotiation takes -place after the nextUpdate deadline has been reached, the peer certificate -will be declared invalid and the cached RSA public key will be deleted, causing -the connection in question to fail. Therefore if you are going to use the -"strictcrlpolicy=yes" option, make sure that the CRLs will always be updated -in time. Otherwise a total standstill would ensue. - -As mentioned earlier the default setting is "strictcrlpolicy=no" - - -5.7 Configuring the peer side using locally stored certificates - ----------------------------------------------------------- - -If you don't want to use trust chains based on CA certificates as proposed in -section 4.3 you can alternatively import trusted peer certificates directly -into Pluto. Thus you do not have to rely on the certificate to be transmitted -by the peer as part of the IKE protocol. - -With the conn %default section defined in section 4.1 and the use of the -rightcert keyword for the peer side, the connection definitions in section 4.3 -can alternatively be written as - - conn sun - right=%any - rightid=@sun.strongswan.org - rightcert=sunCert.cer - - conn carol - right=192.168.0.100 - rightcert=carolCert.der - -If the peer certificates are loaded locally then there is no sense in sending -any certificates to the other end via the IKE Main Mode protocol. Especially -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 - -to the connection definition[s] in order to avoid the sending of the host's -own certificate. The default value is - - 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 -entry is present then the subject distinguished name contained in the -certificate is taken as the ID. - -Using the same rules concerning pathnames that apply to strongSwan's own -certificates, the following two definitions are also valid for trusted peer -certificates: - - rightcert=peercerts/carolCert.der - -or - - rightcert=/usr/ssl/certs/carolCert.der - - -6. Installing the private key - ipsec.secrets - ------------------------------------------ - -6.1 Loading private key files in PKCS#1 format - ------------------------------------------ - -Besides strongSwan's raw private key format strongSwan has been enabled to -load RSA private keys in the PKCS#1 file format. The key files can be -optionally secured with a passphrase. - -RSA private key files are declared in /etc/ipsec.secrets using the syntax - - : RSA <my keyfile> "<optional passphrase>" - -The key file can be either in base64 PEM-format or binary DER-format. The -actual coding is detected "automagically" by Pluto. The example - - : RSA moonKey.pem - -uses a relative pathname. In this case Pluto will look for the key file -in the directory - - /etc/ipsec.d/private - -As an alternative an absolute pathname can be given as in - - : RSA /usr/ssl/private/moonKey.pem - -In both cases make sure that the key files are root readable only. - -Often a private key must be transported from the Certification Authority -where it was generated to the target security gateway where it is going -to be used. In order to protect the key it can be encrypted with 3DES -using a symmetric transport key derived from a cryptographically strong -passphrase. - - openssl genrsa -des3 -out moonKey.pem 1024 - -Because of the weak security, key files protected by single DES will not -be accepted by Pluto!!! - -Once on the security gateway the private key can either be permanently -unlocked so that it can be used by Pluto without having to know a -passphrase - - openssl rsa -in moonKey.pem -out moonKey.pem - -or as an option the key file can remain secured. In this case the passphrase -unlocking the private key must be added after the pathname in -/etc/ipsec.secrets - - : RSA moonKey.pem "This is my passphrase" - -Some CAs distribute private keys embedded in a PKCS#12 file. Since Pluto -is not able yet to read this format directly, the private key part must -first be extracted using the command - - openssl pkcs12 -nocerts -in moonCert.p12 -out moonKey.pem - -if the key file moonKey.pem is to be secured again by a passphrase, or - - openssl pkcs12 -nocerts -nodes -in moonCert.p12 -out moonKey.pem - -if the private key is to be stored unlocked. - - -6.2 Entering passphrases interactively - ---------------------------------- - -On a VPN gateway you would want to put the passphrase protecting the private -key file right into /etc/ipsec.secrets as described in the previous paragraph, -so that the gateway can be booted in unattended mode. The risk of keeping -unencrypted secrets on a server can be minimized by putting the box into a -locked room. As long as no one can get root access on the machine the private -keys are safe. - -On a mobile laptop computer the situation is quite different. The computer can -be stolen or the user is leaving it unattended so that unauthorized persons -can get access to it. In theses cases it would be preferable not to keep any -passphrases openly in /etc/ipsec.secrets but to prompt for them interactively -instead. This is easily done by defining - - : RSA moonKey.pem %prompt - -Since strongSwan is usually started during the boot process, usually no -interactive console windows is available which can be used by Pluto to -prompt for the passphrase. This must be initiated by the user by typing - - ipsec secrets - -which actually is an alias for the existing command - - ipsec rereadsecrets - -and which causes the prompt - - need passphrase for '/etc/ipsec.d/private/moonKey.pem' - Enter: - -to appear. If the passphrase was correct and the private key file could be -successfully decrypted then - - valid passphrase - -results. Otherwise the prompt - - invalid passphrase, please try again - Enter: - -will give you another try. Entering a carriage return will abort the -the passphrase prompting. - - -6.3 Multiple private keys - --------------------- - -strongSwan supports multiple private keys. Since the connections defined -in ipsec.conf can find the correct private key based on the public key -contained in the certificate assigned by leftcert, default private key -definitions without specific IDs can be used - - : RSA myKey1.pem "<optional passphrase1>" - - : RSA myKey2.pem "<optional passphrase2>" - - -7. Configuring CA properties - ipsec.conf - -------------------------------------- - -Besides the definition of IPsec connections the ipsec.conf file can also -be used to configure a few properties of the certification authorities -needed to establish the X.509 trust chains. The following example shows -the parameters that are currently available: - - ca strongswan - cacert=strongswanCert.pem - ocspuri=http://ocsp.strongswan.org:8880 - crluri=http://crl.strongswan.org/strongswan.crl' - crluri2="ldap:///O=Linux strongSwan, C=CH?certificateRevocationList" - ldaphost=ldap.strongswan.org - auto=add - -In a similar way as conn sections are used for connection definitions, an -arbitrary number of optional ca sections define the basic properties of CAs. - -Each ca section is named with a unique label - - ca strongswan - -The only mandatory parameter is - - cacert=strongswanCert.pem - -which points to the CA certificate which usually resides in the default -directory /etc/ipsec.d/cacerts/ but could also be retrieved via an absolute -path name. If the CA certificate is stored on a smartcard then the -notation - - cacert=%smartcard#<n> - -or alternatively - - cacert=%smartcard<optional slot nr>:<key id> - -can be used. The selection of smartcard slots is described in more detail -in section 8.1. - -From the certificate the CA's distinguished name and the serial number -is extracted. If an optional subjectKeyAuthentifier is present then it can -be used to uniquely identify consecutive generations of CA certificates -carrying the same distinguished name. - -The OCSP URI - - ocspuri=http://ocsp.strongswan.org:8880 - -allows to define an individual OCSP server per CA. Also up to two additional -CRL distribution points (CDPs) can be defined - - crluri=http://crl.strongswan.org/strongswan.crl' - crluri2="ldap:///O=Linux strongSwan, C=CH?certificateRevocationList" - -which are added to any CDPs already present in the received certificates -themselves. The last parameter - - ldaphost=ldap.strongswan.org - -can be used to fill in the actual server name in LDAP CDPs where the host is missing -as e.g. in the crluri2 above. In future releases this ldaphost parameter might be used -to retrieve user, host and attribute certificates. - - -With the auto=add statement the ca definition is automatically loaded into Pluto during -system startup. Setting auto=ignore will ignore the ca section. Additional ca definitions -can be loaded from ipsec.conf during runtime with the command - - ipsec auto --type ca --add strongswan-sales - -and - - ipsec auto --type ca --delete strongswan-sales - -deletes the labeled ca entry. And finally the command - - ipsec auto --type ca --replace strongswan - -first deletes the old definition in Pluto's memory and then loads the updated version -from ipsec.conf. Any parameters which appear in several ca definitions can be put in -a common ca %default section - - ca %default - ldaphost=ldap.strongswan.org - - -8. Smartcard support - ----------------- - -8.1 Configuring a smartcard-based connection - ---------------------------------------- - -Defining a smartcard-based connection in ipsec.conf is easy: - - conn sun - right=192.168.0.2 - rightid=@sun.strongswan.org - left=%defaultroute - leftcert=%smartcard - auto=add - -In most cases there is a single smartcard reader or cryptotoken and only one -RSA private key safely stored on the crypto device. Thus usually the entry - - leftcert=%smartcard - -which stands for the full notation - - leftcert=%smartcard#1 - -is sufficient where the first certificate/private key object enumerated by -the PKCS#11 module is used. If several certificate/private key objects are -present then the nth object can be selected using - - leftcert=%smartcard#<n> - -The command - - ipsec listcards - -gives an overview over all certificate objects made available by the PKCS#11 -module.CA certificates are automatically available as trust anchors. - -As an alternative the certificate ID and/or the slot number defined by -the PKCS#11 standard can be specified using the notation - - leftcert=%smartcard<optional slot nr>:<key id in hex format> - -Thus - - leftcert=%smartcard:50 - -will look in all available slots for ID 0x50 starting with the first slot -(usually slot 0) whereas - - leftcert=%smartcard4:50 - -will directly check slot 4 (which is usually the first slot on the second -reader/token when using the OpenSC library) for a key with ID 0x50. - - -8.2 Entering the PIN code - --------------------- - -Since the smartcard signing operation needed to sign the hash with the -RSA private key during IKE Main Mode is protected by a PIN code, -the secret PIN must be made available to Pluto. - -For gateways that must be able to start IPsec tunnels automatically in -unattended mode after a reboot, the secret PIN can be stored statically -in ipsec.secrets - - : PIN %smartcard "12345678" - -or with the general notation - - : PIN %smartcard#<n> "<PIN code>" - -or alternatively - - : PIN %smartcard<optional slot nr>:<key id> "<PIN code>" - -On personal notebooks that could get stolen, you wouldn't want to store -your PIN in ipsec.secrets. Thus the alternative form - - : PIN %smartcard %prompt - -will prompt you for the PIN when you start up the first IPsec connection -using the command - - ipsec up sun - -The auto command calls the whack function which in turn communicates with -Pluto over a socket. Since the whack function call is executed from a command -window, Pluto can prompt you for the PIN over this socket connection. -Unfortunately roadwarrior connections which just wait passively for peers -cannot be initiated via the command window: - - conn rw - right=%any - left=%defaultroute - leftcert=%smartcard4:50 - auto=add - -But if there is a corresponding entry - - : PIN %smartcard4:50 %prompt - -in ipsec.secrets, then the standard command - - ipsec rereadsecrets - -or the alias - - ipsec secrets - -can be used to enter the PIN code for this connection interactively. - -The command - - ipsec listcards - -can be executed at any time to check the current status of the PIN code[s]. - - -8.3 PIN-pad equipped smartcard readers - ---------------------------------- - -Smartcard readers with an integrated PIN-pad offer an increased security -level because the PIN entry cannot be sniffed on the host computer e.g. -by a surrepticiously installed key logger. In order to tell pluto not to -prompt for the PIN on the host itself, the entry - - : PIN %smartcard:50 %pinpad - -can be used in ipsec.secrets. Because the key pad does not cache the PIN in -the smartcard reader, it must be entered for every PKCS #11 session login. -By default pluto does a session logout after every RSA signature. In order -to avoid the repeated entry of the PIN code during the periodic IKE main -mode rekeyings, the following parameter can be set in the config setup -section of ipsec.conf: - - config setup - pkcs11keepstate=yes - -The default setting is pkcs11keepstate=no. - - -8.4 Configuring a smartcard with pkcsc15-init - ----------------------------------------- - -strongSwan's smartcard solution is based on the PKCS#15 "Cryptographic Token -Information Format Standard" fully supported by OpenSC library functions. -Using the command - - pkcs15-init --erase-card --create-pkcs15 - -a fresh PKCS#15 file structure is created on a smartcard or cryptotoken. -With the next command - - pkcs15-init --auth-id 1 --store-pin --pin "12345678" --puk "87654321" - --label "my PIN" - -a secret PIN code with auth-id 1 is stored in an unretrievable location on -the smart card. The PIN will protect the RSA signing operation. If the PIN -is entered incorrectly more than three times the smartcard will be locked -and the PUK code can be used to unlock the card again. - -Next the RSA private key is transferred to the smartcard - - pkcs15-init --auth-id 1 --store-private-key myKey.pem [--id 45] - -By default the PKCS#15 smartcard record will be assigned the id 45. -Using the --id option multiple key records can be stored on a smartcard. - -At last we load the matching X.509 certificate onto the smartcard - - pkcs15-init --auth-id 1 --store-certificate myCert.pem [--id 45] - -The pkcs15-tool can now be used to verify the contents of the smartcard. - - pkcs15-tool --list-pins --list-keys --list-certificates - -If everything is ok then you are ready to use the generated PKCS#15 -structure with strongSwan. - -8.5 PKCS#11 proxy functions - ----------------------- - - With the setting pkcs11keepstate=yes some PKCS#11 implementations - (e.g. OpenSC) will lock the access to the smartcard as soon as pluto has - opened a session and will thus prevent other application from sharing the - smartcard resource. In order to solve this locking problem, strongSwan - offers a PKCS#11 proxy service making use of the whack socket communication - channel. The setting - - config setup - pkcs11proxy=yes - -will enable the proxy mode that is disabled by default. - -Currently two smartcard operations are supported: RSA encryption and -RSA decryption. The notation is as follows: - - ipsec scdecrypt <encrypted data> - [--inbase 16|hex|64|base64|256|text|ascii] - [--outbase 16|hex|64|base64|256|text|ascii] - [--keyid <id>] - -The default settings for inbase and outbase is hexadecimal. -Thus the simplest call has the form - - ipsec scdecrypt bb952b71920094ce0696ef9b8b26...12e6 - -and the returned result might be a decrypted 128 bit AES key - - 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 -the use of the inbase and outbase attributes - - ipsec scdecrypt m/ewDnTs0k...woE= --inbase base64 --outbase text - -where the result has the form - - 000 This is a secret - -By default the first RSA private key found by the PKCS#11 enumeration is -used. If a different key should be selected then the notation introduced -in sections 8.1 and 8.2 can be used: - - --keyid %smartcard:50 - --keyid %smartcard4:50 - --keyid %smartcard#3 - -with --keyid %smartcard#1 being the default. If supported by the smartcard -and PKCS#11 library RSA encryption can be used with the notation - - ipsec scencrypt <plaintext data> - [--inbase 16|hex|64|base64|256|text|ascii] - [--outbase 16|hex|64|base64|256|text|ascii] - [--keyid <id>] - -with the example - - ipsec scencrypt "This is a secret" --inbase ascii --outbase 64 - -returning the expected output - - 000 m/ewDnTs0k...woE= - - -9. Configuring the clients - ----------------------- - -9.1 strongSwan - ---------- - -A strongSwan to strongSwan connection is symmetrical. Any of the four defined -ID types can be used, even different types on either end of the connection, -although this wouldn't make much sense. - -+--------------------------------------------------------------+ -| Connection Definition ID type subjectAltName | -|--------------------------------------------------------------| -| rightid (strongSwan) DER_ASN1_DN - | -| FQDN DNS: | -| USER_FQDN email: | -| IPV4_ADDR IP: | -|--------------------------------------------------------------| -| leftid (strongSwan) DER_ASN1_DN - | -| FQDN DNS: | -| USER_FQDN email: | -| IPV4_ADDR IP: | -+--------------------------------------------------------------+ - - -9.2 PGPnet - ------ - -Use the file peerCert.p12 to import PGPnet's X.509 certificate, the CA -certificate, plus the encrypted private key in binary PKCS#12 format into the -PGPkey tool. You will be prompted for the passphrase securing the private key. - -Use the file myCert.pem to import the X.509 certificate of the strongSwan -security gateway into the PGPkey tool. The PGPkeyTool does not accept X.509 -certificates in binary DER format, so it must be imported in base64 format: - - -----BEGIN CERTIFICATE----- - M... - - ... - -----END CERTIFICATE----- - -Make sure that there is no human-readable listing of the X.509 certificate in -front of the line - - -----BEGIN CERTIFICATE----- - -otherwise PGPnet will refuse to load the *.PEM file. Any surplus lines can -either be deleted by loading the certificate into a text editor or you can -apply the command - - openssl x509 -in myCert.pem -out myCert.pem - -to achieve the same effect. - -With authentication based on X.509 certificates, PGPnet always sends the ID -type DER_ASN1_DN, therefore rightid in the connection definition of the -strongSwan security gateway must be an ASN.1 distinguished name. - -In the receiving direction PGPnet accepts all four ID types from strongSwan. - -+--------------------------------------------------------------+ -| Connection Definition ID type subjectAltName | -|--------------------------------------------------------------| -| rightid (PGPnet) DER_ASN1_DN - | -|--------------------------------------------------------------| -| leftid (strongSwan) DER_ASN1_DN - | -| FQDN DNS: | -| USER_FQDN email: | -| IPV4_ADDR IP: | -+--------------------------------------------------------------+ - - -9.3 SafeNet/Soft-PK/Soft-Remote - --------------------------- - -SafeNet/Soft-PK and SafeNet/Soft-Remote can be configured to send their -identity either as DER_ASN1_DN, IPV4_ADDR, FQDN, or USER_FQDN. -In the receiving direction SafeNet/Soft-PK and SafeNet/Soft-Remote -accept all four ID types coming from strongSwan. - -+--------------------------------------------------------------+ -| Connection Definition ID type subjectAltName | -|--------------------------------------------------------------| -| rightid (SafeNet/Soft-PK) DER_ASN1_DN - | -| FQDN DNS: | -| USER_FQDN email: | -| IPV4_ADDR IP: | -|--------------------------------------------------------------| -| leftid (strongSwan) DER_ASN1_DN - | -| FQDN DNS: | -| USER_FQDN email: | -| IPV4_ADDR IP: | -+--------------------------------------------------------------+ - - -9.4 SSH Sentinel - ------------ - -SSH Sentinel sends its identity as DER_ASN1_DN if the subjectAltName field of -its certificate is empty. If a subjectAltName field is present, then the -corresponding type IPV4_ADDR, FQDN, or USER_FQDN is automatically chosen. -With several subjectAltName entries, the precedence of the different ID types -is not quite clear. In the receiving direction SSH Sentinel accepts all four -ID types from strongSwan. - -+--------------------------------------------------------------+ -| Connection Definition ID type subjectAltName | -|--------------------------------------------------------------| -| rightid (SSH Sentinel) DER_ASN1_DN - | -| FQDN DNS: | -| USER_FQDN email: | -| IPV4_ADDR IP: | -|--------------------------------------------------------------| -| leftid (strongSwan) DER_ASN1_DN - | -| FQDN DNS: | -| USER_FQDN email: | -| IPV4_ADDR IP: | -+--------------------------------------------------------------+ - - -9.5 Windows 2000/XP - --------------- - -Windows 2000 and Windows XP always send the ID type DER_ASN1_DN, -therefore rightid in the connection definition of the strongSwan -security gateway must be an ASN.1 distinguished name.In the -receiving direction Windows 2000/XP accepts all four ID types -from strongSwan. - -+--------------------------------------------------------------+ -| Connection Definition ID type subjectAltName | -|--------------------------------------------------------------| -| rightid (Windows 2000/XP) DER_ASN1_DN - | -|--------------------------------------------------------------| -| leftid (strongSwan) DER_ASN1_D - | -| FQDN DNS: | -| USER_FQDN email: | -| IPV4_ADDR IP: | -+--------------------------------------------------------------+ - - -10. Monitoring functions - -------------------- - -strongSwan offers the following monitoring functions: - - - ipsec listalgs - -lists all IKE and ESP cryptographic algorithms that are currently -registered with strongSwan. - -The a listing has the following form: - - List of registered IKE Encryption Algorithms: - - #3 OAKLEY_BLOWFISH_CBC, blocksize: 64, keylen: 128-128-256 - #5 OAKLEY_3DES_CBC, blocksize: 64, keylen: 192-192-192 - #7 OAKLEY_AES_CBC, blocksize: 128, keylen: 128-128-256 - #65004 OAKLEY_SERPENT_CBC, blocksize: 128, keylen: 128-128-256 - #65005 OAKLEY_TWOFISH_CBC, blocksize: 128, keylen: 128-128-256 - #65289 OAKLEY_TWOFISH_CBC_SSH, blocksize: 128, keylen: 128-128-256 - - List of registered IKE Hash Algorithms: - - #1 OAKLEY_MD5, hashsize: 128 - #2 OAKLEY_SHA, hashsize: 160 - #4 OAKLEY_SHA2_256, hashsize: 256 - #6 OAKLEY_SHA2_512, hashsize: 512 - - List of registered IKE DH Groups: - - #2 OAKLEY_GROUP_MODP1024, groupsize: 1024 - #5 OAKLEY_GROUP_MODP1536, groupsize: 1536 - #14 OAKLEY_GROUP_MODP2048, groupsize: 2048 - #15 OAKLEY_GROUP_MODP3072, groupsize: 3072 - #16 OAKLEY_GROUP_MODP4096, groupsize: 4096 - #17 OAKLEY_GROUP_MODP6144, groupsize: 6144 - #18 OAKLEY_GROUP_MODP8192, groupsize: 8192 - - List of registered ESP Encryption Algorithms: - - #3 ESP_3DES, blocksize: 64, keylen: 168-168 - #7 ESP_BLOWFISH, blocksize: 64, keylen: 96-128 - #12 ESP_AES, blocksize: 128, keylen: 128-256 - #252 ESP_SERPENT, blocksize: 128, keylen: 128-256 - #253 ESP_TWOFISH, blocksize: 128, keylen: 128-256 - - List of registered ESP Authentication Algorithms: - - #1 AUTH_ALGORITHM_HMAC_MD5, keylen: 128-128 - #2 AUTH_ALGORITHM_HMAC_SHA1, keylen: 160-160 - #5 AUTH_ALGORITHM_HMAC_SHA2_256, keylen: 256-256 - #7 AUTH_ALGORITHM_HMAC_SHA2_512, keylen: 512-512 - - -The command - - 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 -from received certificates or retrieved from secure DNS servers using -opportunistic mode. - -The public key listing has the following form: - - Feb 11 14:40:18 2005, 2048 RSA Key AwEAAa+uL, - until Sep 09 13:17:25 2009 ok - ID_FQDN '@moon.strongswan.org' - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - serial: '03' - Feb 11 14:40:18 2005, 2048 RSA Key AwEAAa+uL, - until Sep 09 13:17:25 2009 ok - ID_DER_ASN1_DN 'C=CH, O=Linux strongSwan, CN=moon.strongswan.org' - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - serial: '03' - Feb 11 13:36:53 2005, 2048 RSA Key AwEAAbgbh, - until Dec 31 22:43:18 2009 ok - ID_USER_FQDN 'carol@strongswan.org' - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - serial: '0a' - -It consists of - - - the date the public key was installed either in local time or UTC (--utc) - - the modulus size of the RSA key in bits - - a keyID consisting of 9 base64 symbols representing the public exponent - and the most significant bits of the modulus - - the expiration date of the public key (extracted from the certificate) - - the type and value of the ID associated with the public key. - - the issuer of the certificate the public key was extracted from. - - the serial number of the certificate the public key was extracted from. - -A public key can be associated with several IDs, e.g. using subjectAltNames -in certificates and an ID can possess several public keys, e.g. retrieved -from a secure DNS server. - - -The command - - ipsec listcerts [--utc] - -lists all local certificates, both strongSwan's own and those of -trusted peer loaded via leftcert and rightcert, respectively. - -The output has the form - - Feb 11 13:36:47 2005, count: 4 - subject: 'C=CH, O=Linux strongSwan, CN=moon.strongswan.org' - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - serial: 03 - pubkey: 2048 RSA Key AwEAAa+uL, has private key - validity: not before Sep 10 13:17:25 2004 ok - not after Sep 09 13:17:25 2009 ok - subjkey: e5:e4:10:87:6c:2a:c4:be:ad:85:49:42:a6:de:76:58:30:3a:9f:c1 - authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef - aserial: 00 - -and shows - - - the date the certificate was installed either in local time or UTC (--utc) - - the count shows how many connections refer to this certificate - - the subject of the certificate - - the issuer of the certificate - - the serial number of the certificate - - the size and keyid of the RSA public key contained in the certificate. - the label "has private key" indicates that a matching RSA private key - has been found, defined or loaded in ipsec.secrets. - - the label "on smartcard" indicates that the certificate was loaded from - a smartcard or cryptotoken and that most probably a matching RSA private - key also resides on-card. - - the validity of the CA certificate expressed either in local time or - UTC (--utc). The validity is checked automatically resulting either - in an "ok" message or a "fatal" error message. - - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash - over the certificate's public key. - - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash - over the public key of the issuer who signed the certificate. - - the serial number of the issuer's certificate. - - -The command - - ipsec listcacerts [--utc] - -lists all CA certificates that have been either been loaded from the directory -/etc/ipsec.d/cacerts/ or received via the IKE protocol. The output has the form - - Feb 11 13:36:52 2005, count: 1 - subject: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - serial: 00 - pubkey: 2048 RSA Key AwEAAb/yX - validity: not before Sep 10 13:01:45 2004 ok - not after Sep 08 13:01:45 2014 ok - subjkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef - authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef - aserial: 00 - -and shows - - - the date the CA certificate was installed either in local time or UTC (--utc) - - the count is always set to 1 - - the subject of the CA certificate - - the issuer of the CA certificate - - the serial number of the CA certificate - - the size and keyid of the RSA public key contained in the certificate. - - the validity of the CA certificate expressed either in local time or - UTC (--utc). The validity is checked automatically resulting either - in an "ok" message or a "fatal" error message. - - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash - over the CA certificate's public key. - - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash - over the public key of the issuer who signed the CA certificate. - For Root CA certificates the authorityKeyIdentifier and subjectKeyIdentifier - fields must be equal. - - the serial number of the issuer's certificate. - - -The command - - ipsec listaacerts [--utc] - -lists all Authorization Authority certificates that have been loaded from -the directory /etc/ipsec.d/aacerts/. -The output has the form - - Dec 20 13:29:55 2004, count: 1 - subject: 'C=CH, O=strongSec GmbH, CN=strongSec Authorization Authority' - issuer: 'C=CH, O=strongSec GmbH, CN=strongSec Root CA' - serial: 0f - pubkey: 2048 RSA Key AwEAAfazH - validity: not before Aug 24 13:41:56 2003 ok - not after Aug 23 13:41:56 2005 ok - subjkey: 56:89:b9:28:c9:1b:a0:00:7f:50:9d:ec:28:75:23:c1:1e:d1:dd:90 - authkey: af:80:d5:c6:02:1c:96:78:b3:85:a5:65:a2:23:fd:ad:cf:e2:55:b2 - aserial: 00 - -and shows - - - the date the AA certificate was installed either in local time or UTC (--utc) - - the count is always set to 1 - - the subject of the AA certificate - - the issuer of the AA certificate - - the serial number of the AA certificate - - the size and keyid of the RSA public key contained in the certificate. - - the validity of the AA certificate expressed either in local time or - UTC (--utc). The validity is checked automatically resulting either - in an "ok" message or a "fatal" error message. - - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash - over the AA certificate's public key. - - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash - over the public key of the issuer who signed the AA certificate. - - the serial number of the issuer's certificate. - - -The command - - ipsec listocspcerts [--utc] - -lists all OCSO signer certificates that have been either loaded from -/etc/ipsec.d/ocspcerts/ or have been received included in the OCSP server -response. The output has the form - - Feb 09 22:56:17 2005, count: 1 - subject: 'C=CH, O=Linux strongSwan, OU=OCSP, CN=ocsp.strongswan.org' - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - serial: 09 - pubkey: 2048 RSA Key AwEAAaonT - validity: not before Nov 19 17:29:28 2004 ok - not after Nov 18 17:29:28 2009 ok - subjkey: 88:07:0a:b8:ae:c7:c1:07:5c:be:68:6a:c4:a5:7f:81:1f:37:b5:56 - authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef - aserial: 00 - -and shows - - - the date the OCSP signer certificate was installed either in local time - or UTC (--utc) - - the count is always set to 1 - - the subject of the OCSP signer certificate - - the issuer of the OCSP signer certificate - - the serial number of the OCSP signer certificate - - the size and keyid of the RSA public key contained in the certificate. - - the validity of the OCSP signer certificate expressed either in local time - or UTC (--utc). The validity is checked automatically resulting either - in an "ok" message or a "fatal" error message. - - the optional subjectKeyIdentifier extension which is a 20 byte SHA-1 hash - over the OCSP signer certificate's public key. - - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash - over the public key of the issuer who signed the OCSP certificate. - - the serial number of the issuer's certificate. - - -The command - - ipsec listacerts [--utc] - -lists all X.509 attribute certificates that have been loaded from the directory -/etc/ipsec.d/acerts/. -The output has the form - - Dec 20 13:29:56 2004 - holder: 'C=CH, O=strongSec GmbH, CN=Andreas Steffen' - hissuer: 'C=CH, O=strongSec GmbH, CN=strongSec Root CA' - hserial: 1e - groups: Research, Sales - issuer: 'C=CH, O=strongSec GmbH, CN=strongSec Authorization Authority' - serial: 2c - validity: not before Dec 19 14:51:38 2004 ok - not after Dec 20 14:51:38 2004 fatal (expired) - authkey: 56:89:b9:28:c9:1b:a0:00:7f:50:9d:ec:28:75:23:c1:1e:d1:dd:90 - aserial: 0f - -and shows - - - the date the attribute certificate was installed either in local time - or UTC (--utc) - - the holder of the attribute certificate - - the issuer of holder's certificate - - the serial number of the holder's certificate - - the group attributes - - the issuing Authorization Authority of the attribute certificate - - the serial number of the attribute certificate - - the validity of the attribute certificate expressed either in local time or - UTC (--utc). The validity is checked automatically resulting either - in an "ok" message or a "fatal" error message. - - an authorityKeyIdentifier extension which is a 20 byte SHA-1 hash - over the public key of the issuing Authorization Authority - - the serial number of the AA certificate. - - -The command - - ipsec listgroups [--utc] - -lists all group attributes either defined in right|leftgroups statements -in ipsec.conf or contained in loaded X.509 attribute certificates. -The output has the form - - Dec 20 13:29:55 2004, count: 4 - Research - Dec 20 13:30:04 2004, count: 1 - Research New York - Dec 20 13:29:55 2004, count: 3 - Sales - -and shows - - - the date the group attribute was first installed either in local time - or UTC (--utc) - - the count shows how many times the attribute is used - - the group name - - -The command - - ipsec listcainfos [--utc] - -lists the properties defined by the ca definition sections in ipsec.conf. -The output has the form - - Jun 08 22:31:37 2004, "strongswan" - authname: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - ldaphost: 'ldap.strongswan.org' - ocspuri: 'http://ocsp.strongswan.org:8880' - distPts: 'http://crl.strongswan.org/strongswan.crl' - 'ldap:///O=Linux strongSwan, C=CH?certificateRevocationList' - authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef - aserial: 00 - -and shows - - - the date the CA definition was loaded either in local time or UTC (--utc) - - the name of the ca section - - the distinguished name of the CA - - an optional default ldap host for the CA - - an optional OCSP URI - - a maximum of two optional CRL distribution points - - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash - over the public key of the CA. - - the serial number of the CA. - - -The command - - ipsec listcrls [--utc] - -lists all CRLs that have been loaded from /etc/ipsec.d/crls/. -The output has the form - - Feb 11 13:37:00 2005, revoked certs: 1 - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - distPts: 'http://crl.strongswan.org/strongswan.crl' - updates: this Feb 08 07:46:29 2005 - next Mar 10 07:46:29 2005 ok - authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef - aserial: 00 - -and shows - - - the date the CRL was installed either in local time or UTC (--utc) - - the number revoked certificates - - the issuer of the CRL - - the URLs of the distribution points where the CRL can be fetched from. - - the dates when the CRL was issued and when the next update - is expected, respectively, expressed either in local time or - UTC (--utc). It is automatically checked if the next update - deadline has passed, resulting either in an "ok" message, a - a "warning" message when strictcrlpolicy=no or a "fatal" message when - strictcrlpolicy=yes. - - the optional authorityKeyIdentifier extension which is a 20 byte SHA-1 hash - over the public key of the issuer who signed the CRL. This extension is - present in version 2 CRLs, only. - - the serial number of the issuer's certificate. - - -The command - - - ipsec listocsp [--utc] - -lists the contents of the OCSP response cache. The output has the form - - issuer: 'C=CH, O=Linux strongSwan, CN=strongSwan Root CA' - uri: 'http://ocsp.strongswan.org:8880' - authname: 13:9d:a0:9e:f4:32:ab:8f:e2:89:56:67:fa:d0:d4:e3:35:86:71:b9 - authkey: 5d:a7:dd:70:06:51:32:7e:e7:b6:6d:b3:b5:e5:e0:60:ea:2e:4d:ef - aserial: 00 - Feb 09 22:56:17 2005, until Feb 09 23:01:17 2005 warning (expires in 4 minutes) - serial: 0a, good - -and shows - - - the distinguished name of the CA handled by the OCSP server - - the http URI of the OCSP server. - - the 20 byte SHA-1 hash of the CA's distinguished name - - the 20 byte SHA-1 hash of the CA's public key - - the serial number of the CA's certificate - - a certificate status list showing - - the time the OCSP status was received - - an optional nextUpdate deadline (if missing the OCSP status will be - onetime with a lifetime of 2 minutes only). - - the serial number of the certificate - - the status of the certificate (good, revoked, unknown) - - -The command - - ipsec listcards [--utc] - -lists all smartcard records that are currently in use by Pluto. -The output has the form - - Aug 17 16:47:59 2005, #1, count: 6 - slot: 0, session closed, logged out, has valid pin - id: 45 - label: 'strongSwan' - subject: 'C=CH, O=Linux strongSwan, CN=carol@strongswan.org' - -with pkcs11keepstate=no and - - Aug 17 16:47:59 2005, #1, count: 6 - slot: 0, session opened, logged in, has pin pad - id: 45 - label: 'strongSwan' - subject: 'C=CH, O=Linux strongSwan, CN=carol@strongswan.org' - -with pkcs11keepstate=yes and shows - -- the date the certificate was read from the smartcard record -- the certificate objects are numbered starting from #1 -- the count shows how many connections and secret pin entries point - to the smartcard record -- the PKCS #11 slot number -- the PKCS #11 session state: closed | opened -- the PKCS #11 session login state: logged out | logged in -- the status of the PIN: no pin | valid pin | invalid pin | pin pad -- the ID of the certificate object -- the label of the certificate object -- the subject distinguished name of the certificate - - -The command - - ipsec auto --listall [--utc] - -is equivalent to - - ipsec listalgs - ipsec listpubkeys [--utc] - ipsec listcerts [--utc] - ipsec listcacerts [--utc] - ipsec listaacerts [--utc] - ipsec listocspcerts [--utc] - ipsec listacerts [--utc] - ipsec listgroups [--utc] - ipsec listcainfos [--utc] - ipsec listcrls [--utc] - ipsec listocsp [--utc] - ipsec listcards [--utc] - - -11. Firewall support functions - -------------------------- - - -11.1 Environment variables in the updown script - ------------------------------------------ - -strongSwan makes the following environment variables available -in the updown script indicated by the leftupdown option: - -+------------------------------------------------------------------+ -| Variable Example Comment | -|------------------------------------------------------------------| -| $PLUTO_PEER_ID carol@strongswan.org USER_FQDN (1) | -|------------------------------------------------------------------| -| $PLUTO_PEER_PROTOCOL 17 udp (2) | -|------------------------------------------------------------------| -| $PLUTO_PEER_PORT 68 bootpc (3) | -|------------------------------------------------------------------| -| $PLUTO_PEER_CA C=CH, O=ACME, CN=Sales CA (4) | -|------------------------------------------------------------------| -| $PLUTO_MY_ID @moon.strongswan.org FQDN (1) | -|------------------------------------------------------------------| -| $PLUTO_MY_PROTOCOL 17 udp (2) | -|------------------------------------------------------------------| -| $PLUTO_MY_PORT 67 bootps (3) | -+------------------------------------------------------------------+ - -(1) $PLUTO_PEER_ID/$PLUTO_MY_ID contain the IDs of the two ends - of an established connection. In our examples these - correspond to the strings defined by rightid and leftid, - respectively. - -(2) $PLUTO_PEER_PROTOCOL/$PLUTO_MY_PROTOCOL contain the protocol - defined by the rightprotoport and leftprotoport options, - respectively. Both variables contain the same protocol value. - The variables take on the value '0' if no protocol has been defined. - -(3) $PLUTO_PEER_PORT/$PLUTO_MY_PORT contain the ports defined by - the rightprotoport and leftprotoport options, respectively. - The variables take on the value '0' if no port has been defined. - -(4) $PLUTO_PEER_CA contains the distinguished name of the CA that - issued the peer's certificate. - - -11.2 Automatic insertion and deletion of iptables firewall rules - ----------------------------------------------------------- - -Starting with strongswan-2.7.0, the default _updown script automatically inserts -and deletes dynamic iptables firewall rules upon the establishment or teardown, -respectively, of an IPsec security association. This new feature is activated -with the line - - leftfirewall=yes - -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 - iptables-1.3.5 or newer. Filtering of tunneled traffic is based on - IPsec policy matching rules. - -If you define a local client subnet with a netmask larger than /32 behind -the gateway then the automatically inserted FORWARD iptables rules will -not allow to access the internal IP address of the host although it is -part of the client subnet definition. If you want additional INPUT and -OUTPUT iptables rules to be inserted, so that the host itself can be accessed -then add the following line: - - lefthostaccess=yes - -The _updown script also features a logging facility which will register the -creation (+) and the expiration (-) of each successfully established VPN -connection in a special syslog file in the following concise and easily -readable format: - -Jul 19 18:58:38 moon vpn: - + @carol.strongswan.org 192.168.0.100 -- 192.168.0.1 == 10.1.0.0/16 -Jul 19 22:15:17 moon vpn: - - @carol.strongswan.org 192.168.0.100 -- 192.168.0.1 == 10.1.0.0/16 - - -11.3 Sample Linux 2.6 updown script for iptables < 1.3.5 - --------------------------------------------------- - -If you are using a Linux 2.6 kernel older than 2.6.16 or an iptables version -older than 1.3.5 then the IPsec policy matching rules will not be available. -In order to make sure that only tunneled packets are accepted, a mark can be -set on incoming ESP packets. This "ESP" mark will be retained on the -decapsulated packet so that iptables rules inserted by the updown script can -check on the presence of this mark. For this purpose the template located in - - programs/_updown_espmark - -can be used. Store a copy of _updown_espmark e.g. in /etc/ipsec.updown and load -the script with the line - - leftupdown=/etc/updown.ipsec. - -In addition for the dynamic updown script to work the following static iptables rules -must be applied: - - iptables -t mangle -A INPUT -p 50 -j MARK --set-mark 50 - - -12. Authentication with raw RSA public keys - --------------------------------------- - -FreeS/WAN, as it is available from www.freeswan.org does public key -authentication with raw RSA public keys that are directly defined in -/etc/ipsec.conf - - rightrsasigkey=0sAq4c.... - -When version 1.x of standard FreeS/WAN receives a certificate request (CR), -it immediately drops the negotiation because it does not know how to answer -the request. As a workaround strongSwan does not send a CR if the RSA -key has been statically loaded using [right/left]rsasigkey. A problem -remains with roadwarriors initiating a connection. Since strongSwan -does not know the identity of the initiating peer in advance, it will always -send a CR, causing the rupture of the IKE negotiation if the peer is a -version 1.x FreeS/WAN host. To circumvent this problem the configuration -parameter 'nocrsend' can be set in the config setup section of /etc/ipsec.conf: - - config setup: - nocrsend=yes - -With this entry no certificate request is sent in any connection. -The default setting is nocrsend=no. - - -13. Authentication with OpenPGP certificates - ---------------------------------------- - -strongSwan also supports RSA based authentication using OpenPGP -certificates and OpenPGP V3 fingerprints used as an KEY_ID identifier. - - -13.1 OpenPGP certificates - -------------------- - -OpenPGP certificates containing RSA public keys can now directly be loaded -in ASCII armored PGP format using the leftcert and rightcert parameters -in /etc/ipsec.conf: - - conn pgp - right=%any - righcert=peerCert.asc - left=%defaultroute - leftcert=gatewayCert.asc - -The peer certificate must be stored locally (the default directory is -/etc/ipsec.d/certs) since currently no trust can be established for -PGP certificates received from a peer via the IKE protocol. - - -13.2 OpenPGP private keys - -------------------- - -PGP private keys in unencrypted form can now directly be loaded in ASCII -armored PGP format via an entry in /etc/ipsec.secrets: - - : RSA gatewayKey.asc - -Existing IDEA-encrypted RSA private keys can be unlocked with GnuPG and -the IDEA extension (see http://www.gnupg.org/gph/en/pgp2x.html) using -the commands - - gpg --import gatewayCert.asc - - gpg --allow-secret-key-import --import gatewayKey.asc - - gpg --edit-key <gateway ID> - > passwd #change to empty password - > save - - gpg -a --export-secret-key <gateway ID> gatewayKey.asc - - -13.3 Monitoring functions - -------------------- - -The command ipsec listcerts shows all loaded PGP certificates -in the following format: - - Aug 28 09:51:55 2002, count: 1 - fingerprint: 0x1ccfca12d93467ffa9d5093d87a465dc - pubkey: 1024 RSA Key ARHso6uKQ - created: Aug 27 08:51:39 2002 - until: --- -- --:--:-- ---- ok (expires never) - -The entries are - - - the date the certificate was loaded either in local time or UTC (--utc) - - the V3 fingerprint consisting of the 16 byte MD5 hash of the public key - which is used as an ID of type KEY_ID - - the modulus size of the RSA key in bits - - a keyID consisting of 9 base64 symbols representing the public exponent - and the most significant bits of the modulus - - the creation date of the public key (extracted from the certificate) - - the optional expiration date of the public key (extracted from the - certificate) - - -13.4 Suppression of certificate request messages - ------------------------------------------- - -PGPnet configured to work with OpenPGP certificates aborts the IKE -negotiation when it receives a X.509 certificate. Therefore it is recommended -(mandatory for roadwarrior connections) to set - - config setup: - nocrsend=yes - -in /etc/ipsec.conf. - - -14. Additional Features - ------------------- - - -14.1 Authentication and encryption algorithms - ---------------------------------------- - -strongSwan supports the following suite of encryption and authentication -algorithms for both IKE and ESP payloads. - -+------------------------------------------------------------------+ -| IKE algorithms (negotiated in Phase 1 Main Mode) | -+------------------------------------------------------------------+ -| Encryption algorithms: 3des, aes, serpent, twofish, blowfish | -|------------------------------------------------------------------| -| Hash algorithms: md5, sha, sha2 | -|------------------------------------------------------------------| -| DH groups: 1024, 1536, 2048, 3072, 4096, 6144, 8192 | -+------------------------------------------------------------------+ - -NOTE: For IKE the SHA-1 algorithm is denoted by "sha" - -The cryptographic IKE algorithms listed above are a fixed part of the -strongSwan distribution. Particular algorithms can be added or removed -in the "programs/pluto/alg" directory. - -+------------------------------------------------------------------+ -| ESP algorithms (negotiated in Phase 2 Quick Mode) | -+------------------------------------------------------------------+ -| Encryption algorithms: 3des, aes, serpent, twofish, blowfish | -|------------------------------------------------------------------| -| Hash algorithms: md5, sha1, sha2 | -|------------------------------------------------------------------| -| PFS groups: 1024, 1536, 2048, 3072, 4096, 6144, 8192 | -+------------------------------------------------------------------+ - -The cryptographic ESP algorithms listed above are a fixed part of the -strongSwan distribution. If your Linux 2.4 or 2.6 kernel includes the -CryptoAPI then additional ESP algorithms can be added or deleted as -kernel modules. - -The IKE and ESP cryptographic algorithms to be proposed to the peer -as an initiator can be specified on a per connection basis in the form - -conn normal - ... - ike=aes128-sha-modp1536,3des-sha-modp1536 - esp=aes128-sha1,3des-sha1 - ... - -or if you are more paranoid - -conn paranoid - ... - ike=aes256-sha2_512-modp2048 - esp=aes256-sha2_512 - ... - -If the the "ike" and "esp" configuration parameters are missing in -ipsec.conf, then the default settings - - ike=3des-md5-modp1536,3des-sha-modp1536,\ - 3des-md5-modp1024,3des-sha-modp1024 - esp=3des-md5,3des-sha1 - -arre implicitly assumed. The 3DES encryption algorithm and the MD5 and -SHA-1 hash algorithms are hardcoded into strongSwan and cannot be removed. - -If Perfect Forward Secrecy (PFS is desired), then a PFS group can be -optionally specified: - -conn make_sure - ... - pfs=yes - pfsgroup=modp2048,modp1536 - ... - -If the "pfs" parameter is missing then "pfs=yes" is assumed by default. -This means that PFS must be disabled explicitly by setting "pfs=no". - -If the "pfsgroup" parameter is missing then the default is - - pfsgroup=<Phase1 DH group> - -The "ike" and "esp" parameters are used to formulate one or several -transform proposals to the peer if the strongSwan VPN host is the initiator. -Attention! As a responder the first proposal from the peer is accepted that -is supported the by one of the registered algorithms listed by the command - - ipsec listalgs - -If the responder wants to restrict the allowed cipher suites the '!' flag -can be used to do so. The configuration - -conn normal_but_strict - ... - ike=aes128-sha-modp1536,3des-sha-modp1536! - esp=aes128-sha1,3des-sha1! - ... - -will only permit the listed algorithms defined above but no other methods -even if they might be supported by the responder. - - -14.2 NAT traversal - ------------- - -Currently please refer to README.NAT-Traversal document in the strongSwan -distribution. - - -14.3 Dead peer detection - -------------------- - -strongSwan implements the RFC 3706 Dead Peer Detection (DPD) keep-alive -scheme. If an established IPsec SA has been idle (i.e. without any traffic) -for N seconds (dpddelay=N) then strongSwan side sends a "hello" message -(R_U_THERE) and the peer replies with an acknowledge message (R_U_THERE_ACK). -If no response is received, the R_U_THERE messages are repeated until a DPD -timeout of M seconds (dpdtimeout=M) has elapsed. If still no traffic or -R_U_THERE_ACK packets were received, the peer is declared to be dead and all -SAs belonging to a common Phase 1 SA are deleted. - -DPD support is tuneable on a per connection basis by using the dpdaction, -dpddelay and dpdtimeout directives: - - conn roadwarrior - right=%any - left=%defaultroute - leftsubnet=10.1.0.0/16 - dpdaction=clear - - conn net-to-net - right=192.168.0.2 - rightsubnet=10.2.0.0/16 - left=%defaultroute - leftsubnet=10.1.0.0/16 - dpdaction=hold - dpddelay=60 - dpdtimeout=500 - -In the first example dpdaction=clear activates the DPD mechanism under the -condition that the peer supports RFC 3706. The values dpddelay=30s and -dpdtimeout=120s are assumed by default in the absence of these parameters, so -that during idle periods an R_U_THERE packet is sent every 30 seconds. If no -traffic or a no R_U_THERE_ACK packet is received from the peer within a -120 second time span, the peer will be declared dead and all SAs and associated -eroutes will be cleared. - -In the second example R_U_THERE packets are sent every 60 seconds and the -parameter setting dpdaction=hold will put the eroute of the ruptured connection -into a %trap state, so that when new outgoing traffic will occur, the -correspondig connection will be automatically renegotiated as soon as the -peer is up again. - -It is recommended to use dpdaction=hold for statically defined connections and -dpdaction=clear for dynamic roadwarrior connections. The default value is -dpdaction=none, which disables DPD. - - -14.4 IKE Mode Config - --------------- - -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. - -Client side configuration (carol): - - conn home - right=192.168.0.1 - rightsubnet=10.1.0.0/16 - rightid=@moon.strongswan.org - left=%defaultroute - leftsourceip=%modeconfig - leftcert=carolCert.pem - leftid=carol@strongswan.org - auto=start - -Server side configuration (moon): - - conn roadwarrior - right=%any - rightid=carol@strongswan.org - rightsourceip=10.3.0.1 - left=%defaultroute - leftsubnet=10.1.0.0/16 - leftcert=moonCert.pem - leftid=@moon.strongswan.org - auto=add - -The wildcard %modeconfig or %modecfg used in the leftsourceip parameter of the -client will trigger a Mode Config request. Currently the server will return -the virtual IP address defined by the rightsourceip parameter. In the future -an LDAP-based lookup mechanism will be supported. - - -15. Copyright statement and acknowledgements - ---------------------------------------- - - - FreeS/WAN version base system: - - Copyright (c) 1999-2004 - Henry Spencer, Richard Guy Briggs, - D. Hugh Redelmeier, Sandy Harris, Claudia Schmeing, - Michael Richardson, Angelos D. Keromytis, John Ioannidis, - - NAT-Traversal, ipsec starter, Delete SA and Notification messages: - - Copyright (c) 2002-2003, Mathieu Lafon - - Additional cryptoalgorithms (AES, etc): - - Copyright (c) 2002-2003, JuanJo Ciarlante - - Dead Peer Detection: - - Copyright (c) 2002-2004 - Ken Bantoft, JuanJo Ciarlante, Philip Craig, - Pawel Krawczyk, Srinvasan Venkataraman - - Porting to Linux 2.6 kernel: - - Copyright (c) 2003, Herbert Xu - - Dynamic CRL fetching: - - Copyright (c) 2002, Stephane Laroche - - IKE Mode Config protocol: - - Copyright (c) 2001-2002, Colubris Networks - - Virtual IP and source routing: - - Copyright (c) 2003, Tuomo Soini - - Port and protocol selectors for outbound traffic: - - Copyright (c) 2002, Stephen J. Bevan - - PGPnet-RSA parts of patch: - - Copyright (c) 2000, Kai Martius - - X.509, OCSP and smartcard functionality: - - Copyright (c) 2000, Andreas Hess, Patric Lichtsteiner, Roger Wegmann - Copyright (c) 2001, Marco Bertossa, Andreas Schleiss - Copyright (c) 2002, Uli Galizzi, Ariane Seiler, Mario Strasser - Copyright (c) 2002, Martin Berner, Lukas Suter - Copyright (c) 2003, Christoph Gysin, Simon Zwahlen - Copyright (c) 2004, David Buechi, Michael Meier - Copyright (c) 2000-2005, Andreas Steffen - - Zurich University of Applied Sciences in Winterthur, Switzerland - - scepclient: - - Copyright (c) 2005, Jan Hutter, Martin Willi - Copyright (c) 2005-2006, Andreas Steffen - - University of Applied Sciences in Rapperswil, Switzerland - - 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. ------------------------------------------------------------------------------ - -This file is RCSID $Id: README,v 1.33 2006/04/24 21:27:49 as Exp $ - |