Re: [RFR] templates://strongswan/{strongswan-starter.templates}
Jonathan Wiltshire wrote:
> Your review should be sent as an answer to this mail.
Thanks for doing this!
Despite the threading of this message my patch follows on from
Christian's.
> --- /home/jona/debian/rewrite/strongswan-starter/strongswan-starter.old/debian/strongswan-starter.templates 2009-04-22 11:31:20.000000000 +0100
> +++ /home/jona/debian/rewrite/strongswan-starter/strongswan-starter/debian/strongswan-starter.templates 2009-04-25 21:47:06.000000000 +0100
> @@ -3,79 +3,84 @@
> _Choices: earliest, "after NFS", "after PCMCIA"
__Choices: earliest, after NFS, after PCMCIA
> Default: earliest
> _Description: When to start strongSwan:
[...]
> + When should strongSwan be started?
>
> This question is huge and the user gets lost before being asked for a
> decison. Simplify the explanations as far as possible, lay them out the
> same, and re-iterate the question at the end.
Christian as I expected is complaining about the duplicate
questions; I'm leaving that part to him until I finally get round to
learning the technical details.
Then Christian's boiled-down bullety version of the text:
| StrongSwan starts during system startup so that it can protect filesystems
| that are automatically mounted. It can be started at different moments:
That last needs rephrasing... tricky. How about "There are three
options for when it can be started:"?
| * earliest: if /usr is not mounted through NFS and you don't use a
| PCMCIA network card, it is best to start strongSwan as soon as
| possible, so that NFS mounts can be secured by IPSec;
| * after NFS: recommended when /usr is mounted through NFS and no
| PCMCIA network card is used;
| * after PCMCIA: recommended if the IPSec connection uses a PCMCIA
| network card of if you want to fetch keys from a locally running DNS
| server with DNSSec support.
Typo (s/of/or/) in the last one. And maybe avoid talking in terms
of the sysadmin's personal whims:
* after PCMCIA: recommended if the IPSec connection uses a PCMCIA
network card, or if it needs keys fetched from a locally running DNS
server with DNSSec support.
> Template: strongswan/restart
> Type: boolean
> Default: true
> -_Description: Do you wish to restart strongSwan?
> - Restarting strongSwan is a good idea, since if there is a security fix, it
> - will not be fixed until the daemon restarts. Most people expect the daemon
> - to restart, so this is generally a good idea. However this might take down
> +_Description: Restart strongSwan:
> + Restarting strongSwan is a good idea, because if there is a security fix, it
> + will not be applied until the daemon restarts. However, this might close
> existing connections and then bring them back up.
> + .
> + Restart strongSwan now?
>
> Tidy the grammar and clarify the question as 'now'.
Christian suggests changing it to "Please choose whether you agree
to restart strongSwan immediately", which is ungainly. I'd go for
dropping the recap and just fixing the synopsis:
_Description: Restart strongSwan now?
And s/a good idea/recommended/.
> Template: strongswan/ikev1
> Type: boolean
> Default: true
> -_Description: Do you wish to support IKEv1?
> +_Description: Support IKEv1?
> strongSwan supports both versions of the Internet Key Exchange protocol,
> - IKEv1 and IKEv2. Do you want to start the "pluto" daemon for IKEv1 support
> - when strongSwan is started?
> + IKEv1 and IKEv2. The pluto daemon must be running for IKEv1 support.
> + .
> + Start pluto with strongSwan?
Do the ikev1 and ikev2 templates need to repeat the same
information? How about:
_Description: Start strongSwan's IKEv1 daemon?
The pluto daemon can be run to support version 1 of the Internet Key
Exchange protocol.
_Description: Start strongSwan's IKEv2 daemon?
The charon daemon can be run to support version 2 of the Internet Key
Exchange protocol.
This also avoids the issue with sentence-initial s.
> Template: strongswan/x509_self_signed
> Type: boolean
> Default: true
> -_Description: Do you want to create a self-signed X.509 certificate?
> +_Description: Create a self-signed X.509 certificate?
> This installer can only create self-signed X.509 certificates
> automatically, because otherwise a certificate authority is needed to sign
> the certificate request. If you want to create a self-signed certificate,
> you can use it immediately to connect to other IPSec hosts that support
> X.509 certificate for authentication of IPSec connections. However, if you
> want to use the new PKI features of strongSwan >= 1.91, you will need to
> have all X.509 certificates signed by a single certificate authority to
> create a trust path.
I've de-snipped some of this so I can propose some changes. For a
start, strongSwan's Debian changelog runs from 2.7.0-1 to 4.2.14-1,
so 1.91 is hardly "new"!
Only self-signed X.509 certificates can be created automatically, because
otherwise a certificate authority is needed to sign the certificate
request.
.
If you accept this option, the certificate created can be used
immediately to connect to other IPSec hosts that support authentication
via X.509 certificate. However, using strongSwan's PKI features requires
a trust path created by having all X.509 certificates signed by a single
authority.
> If you do not want to create a self-signed certificate, then this
> installer will only create the RSA private key and the certificate request,
> which you will need to have signed by your certificate authority.
Christian's version tries to avoid letting the installation process
refer to itself as a separate entity, but gets slightly garbled:
| If you do not want to create a self-signed certificate, then
| only the RSA private key and the certificate request will
| be created and
| which you will need to have them signed by a certificate authority.
Excess "and" and confused antecedent to "which" - the certificate
authority doesn't sign my private key (does it?):
If you do not accept this option, only the RSA private key will be
created, along with a certificate request which you will need to have
signed by a certificate authority.
> Template: strongswan/x509_country_code
> Type: string
> @@ -124,9 +131,7 @@
> Please enter the 2 letter country code for your country. This code will be
> placed in the certificate request.
Is that the two-letter code "GB" or "uk"? Clarify as usual to work
around the standards breakage:
Please enter the two-letter ISO3166 country code that should be
used in the certificate request.
If Austrians will get the option of reading a translated version
with a localised example, maybe we could even make the anglophone
example "GB" (in which case the state-or-province name has to be
"Wiltshire"!), but that's not in my patch.
> This field is mandatory, otherwise a certificate cannot be generated.
^
Technically that's a comma-splice, so make it a semicolon.
In the state_name and locality_name templates Christian has:
| Please enter the name of the locality (e.g. city) to inlude
| in the certificate request.
(Typo: "inlude".) I'd prefer something like this throughout:
Please enter the locality name (often a city) that should be used
in the certificate request.
> @@ -162,8 +166,8 @@
> Type: string
> Default:
> _Description: Organizational unit for the X.509 certificate request:
> - Please enter the organizational unit (e.g. section) that the X.509
> - certificate should be created for. This name will be placed in the
> + Please enter the organizational unit (e.g. section) for whom the X.509
> + certificate should be created. This name will be placed in the
> certificate request.
> .
> Example: security group
Treating an organisation or one of its subunits as a "who(m)" seems
odd to me; I actually prefer the original. Presumably you're trying
to avoid ending the sentence with a preposition, but I'd just
standardise it to
Please enter the organizational unit name (often a department) that
should be used in the certificate request.
(Organisational subunits are more often "departments" than
"sections".)
[...]
> _Description: Email address for the X.509 certificate request:
> Please enter the email address of the person or organization who is
> responsible for the X.509 certificate. This address will be placed in the
> certificate request.
Likewise, if it's an o10n it isn't a "who". I ended up with:
Please enter the email address (for the individual or organization
responsible) that should be used in the certificate request.
> @@ -189,14 +193,14 @@
> Template: strongswan/enable-oe
[...]
> + Enable opportunistic encryption?
>
> I'm still unsure about this question. It's very unwieldy, butI'm not
> sure my version is any less so.
It would be nice to know if it's outdated.
> Package: strongswan
[...]
> Description: IPsec VPN solution metapackage
> - strongSwan is a IPsec based VPN solution for the Linux kernel. It uses the
> + strongSwan is an IPsec-based VPN solution for the Linux kernel. It uses the
> native IPsec stack and runs on any recent 2.6 kernel (no patching required).
> It supports both IKEv1 and the newer IKEv2 protocols.
> .
This gives the impression that normal Debian kernels might not be
recent enough. Mind you, if it needs Linux it isn't "Architecture:
all" any longer, is it?
I'm also not sure we need to point out that IKEv2 is newer than v1!
In fact it sounds as if it's trying to distinguish between the newer
IKEv2 protocols and the older ones, meaning v2.0alpha and v2.01...
We could crunch the boilerplate down to:
The strongSwan VPN solution is based on the IPsec stack in standard
Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
> @@ -22,13 +22,13 @@
> .
> This metapackage has dependencies to the IKEv1 daemon pluto and IKEv2 daemon
> charon. It installs the required packages to run IKEv1 and IKEv2 connections
> - using a ipsec.conf/ipsec.secrets based configuration.
> + using a ipsec.conf/ipsec.secrets-based configuration.
Surely "an"? But once I start I want to change lots more:
This metapackage depends on the IKEv1 daemon, pluto, and IKEv2 daemon,
charon. It installs the packages required to run IKEv1 and IKEv2
connections configured via ipsec.conf or ipsec.secrets.
[...]
> Description: strongSwan IKEv1 keying daemon
This is a sense of the word "keying" that I'm not familiar with - it
almost looks like a typo for "keyring daemon". Since other sources
refer simply to an "IKE daemon", and given that IKE means Internet
Key Exchange, I feel I should suggest:
Description: strongSwan Internet Key Exchange (v1) daemon
Then in the long description replace "IPSec IKEv1 keying daemon"
with "IPSec IKEv1 daemon".
> Package: strongswan-nm
[...]
> This plugin provides an interface which allows NetworkManager to configure
> and control the IKEv2 daemon directly through DBUS. It is designed to work
I understand D-Bus just well enough to spell it.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- ../strongswan-4.2.14.pristine/debian/strongswan-starter.templates 2009-04-21 10:05:35.000000000 +0100
+++ debian/strongswan-starter.templates 2009-04-26 13:52:03.000000000 +0100
@@ -1,68 +1,51 @@
Template: strongswan/start_level
Type: select
-_Choices: earliest, "after NFS", "after PCMCIA"
+__Choices: earliest, after NFS, after PCMCIA
Default: earliest
_Description: When to start strongSwan:
- There are three possibilities when strongSwan can start: before or
- after the NFS services and after the PCMCIA services. The correct answer
- depends on your specific setup.
- .
- If you do not have your /usr tree mounted via NFS (either you only mount
- other, less vital trees via NFS or don't use NFS mounted trees at all) and
- don't use a PCMCIA network card, then it's best to start strongSwan at
- the earliest possible time, thus allowing the NFS mounts to be secured by
- IPSec. In this case (or if you don't understand or care about this
- issue), answer "earliest" to this question (the default).
- .
- If you have your /usr tree mounted via NFS and don't use a PCMCIA network
- card, then you will need to start strongSwan after NFS so that all
- necessary files are available. In this case, answer "after NFS" to this
- question. Please note that the NFS mount of /usr can not be secured by
- IPSec in this case.
- .
- If you use a PCMCIA network card for your IPSec connections, then you only
- have to choose to start it after the PCMCIA services. Answer "after
- PCMCIA" in this case. This is also the correct answer if you want to fetch
- keys from a locally running DNS server with DNSSec support.
+ StrongSwan starts during system startup so that it can protect filesystems
+ that are automatically mounted. There are three options for when it can be
+ started:
+ .
+ * earliest: if /usr is not mounted through NFS and you don't use a
+ PCMCIA network card, it is best to start strongSwan as soon as
+ possible, so that NFS mounts can be secured by IPSec;
+ * after NFS: recommended when /usr is mounted through NFS and no
+ PCMCIA network card is used;
+ * after PCMCIA: recommended if the IPSec connection uses a PCMCIA
+ network card, or if it needs keys fetched from a locally running DNS
+ server with DNSSec support.
Template: strongswan/restart
Type: boolean
Default: true
-_Description: Do you wish to restart strongSwan?
- Restarting strongSwan is a good idea, since if there is a security fix, it
- will not be fixed until the daemon restarts. Most people expect the daemon
- to restart, so this is generally a good idea. However this might take down
+_Description: Restart strongSwan now?
+ Restarting strongSwan is recommended, because if there is a security fix, it
+ will not be applied until the daemon restarts. However, this might close
existing connections and then bring them back up.
Template: strongswan/ikev1
Type: boolean
Default: true
-_Description: Do you wish to support IKEv1?
- strongSwan supports both versions of the Internet Key Exchange protocol,
- IKEv1 and IKEv2. Do you want to start the "pluto" daemon for IKEv1 support
- when strongSwan is started?
+_Description: Start strongSwan's IKEv1 daemon?
+ The pluto daemon can be run to support version one of the Internet Key
+ Exchange protocol.
Template: strongswan/ikev2
Type: boolean
Default: true
-_Description: Do you wish to support IKEv2?
- strongSwan supports both versions of the Internet Key Exchange protocol,
- IKEv1 and IKEv2. Do you want to start the "charon" daemon for IKEv2 support
- when strongSwan is started?
+_Description: Start strongSwan's IKEv2 daemon?
+ The charon daemon can be run to support version two of the Internet Key
+ Exchange protocol.
Template: strongswan/create_rsa_key
Type: boolean
Default: true
-_Description: Do you want to create a RSA public/private keypair for this host?
- This installer can automatically create a RSA public/private keypair
- with an X.509 certificate for this host. This can be used to authenticate
- IPSec connections to other hosts and is the preferred way for building up
- secure IPSec connections. The other possibility would be to use pre-shared
- secrets (PSKs, passwords that are the same on both sides of the tunnel) for
- authenticating an connection, but for a larger number of connections RSA
- authentication is easier to administer and more secure. Note that
- having a keypair allows to use both X.509 and PSK authentication for IPsec
- tunnels.
+_Description: Create an RSA public/private keypair for this host?
+ StrongSwan can use a Pre-Shared Key (PSK) or an RSA keypair to authenticate
+ IPSec connections to other hosts. RSA authentication is generally considered
+ more secure and is easier to administer. You can use PSK and RSA authentication
+ simultaneously.
.
If you do not want to create a new public/private keypair, you can choose to
use an existing one in the next step.
@@ -70,133 +53,114 @@
Template: strongswan/existing_x509_certificate
Type: boolean
Default: false
-_Description: Do you have an existing X.509 certificate file for strongSwan?
+_Description: Use an existing X.509 certificate for strongSwan?
This installer can automatically extract the needed information from an
existing X.509 certificate with a matching RSA private key. Both parts can
- be in one file, if it is in PEM format. If you have such an existing
+ be in one file, if it is in PEM format.
+ .
+ You should choose this option if you have such an existing
certificate and key file and want to use it for authenticating IPSec
- connections, then please answer yes.
+ connections.
Template: strongswan/existing_x509_certificate_filename
Type: string
-_Description: File name of your X.509 certificate in PEM format:
+_Description: File name of existing X.509 certificate in PEM format:
Please enter the full location of the file containing your X.509
certificate in PEM format.
Template: strongswan/existing_x509_key_filename
Type: string
-_Description: File name of your X.509 private key in PEM format:
+_Description: File name of existing X.509 private key in PEM format:
Please enter the full location of the file containing the private RSA key
matching your X.509 certificate in PEM format. This can be the same file
- that contains the X.509 certificate.
+ as the X.509 certificate.
Template: strongswan/rsa_key_length
Type: string
Default: 2048
-_Description: The length of the created RSA key (in bits):
- Please enter the length of the created RSA key. It should not be less than
- 1024 bits because this should be considered unsecure and you will probably
- not need anything more than 2048 bits because it only slows the
- authentication process down and is not needed at the moment.
+_Description: RSA key length:
+ Please enter the length of RSA key you wish to generate. A value of less than
+ 1024 bits is not considered secure. A value of more than 2048 bits will
+ probably affect performance.
Template: strongswan/x509_self_signed
Type: boolean
Default: true
-_Description: Do you want to create a self-signed X.509 certificate?
- This installer can only create self-signed X.509 certificates
- automatically, because otherwise a certificate authority is needed to sign
- the certificate request. If you want to create a self-signed certificate,
- you can use it immediately to connect to other IPSec hosts that support
- X.509 certificate for authentication of IPSec connections. However, if you
- want to use the new PKI features of strongSwan >= 1.91, you will need to
- have all X.509 certificates signed by a single certificate authority to
- create a trust path.
- .
- If you do not want to create a self-signed certificate, then this
- installer will only create the RSA private key and the certificate request
- and you will have to get the certificate request signed by your certificate
+_Description: Create a self-signed X.509 certificate?
+ Only self-signed X.509 certificates can be created automatically, because
+ otherwise a certificate authority is needed to sign the certificate
+ request.
+ .
+ If you accept this option, the certificate created can be used
+ immediately to connect to other IPSec hosts that support authentication
+ via X.509 certificate. However, using strongSwan's PKI features requires
+ a trust path created by having all X.509 certificates signed by a single
authority.
+ .
+ If you do not accept this option, only the RSA private key will be
+ created, along with a certificate request which you will need to have
+ signed by a certificate authority.
Template: strongswan/x509_country_code
Type: string
-Default: AT
+_Default: AT
_Description: Country code for the X.509 certificate request:
- Please enter the 2 letter country code for your country. This code will be
- placed in the certificate request.
- .
- You really need to enter a valid country code here, because openssl will
- refuse to generate certificates without one. An empty field is allowed for
- any other field of the X.509 certificate, but not for this one.
+ Please enter the two-letter ISO3166 country code that should be used in
+ the certificate request.
.
- Example: AT
+ This field is mandatory; otherwise a certificate cannot be generated.
Template: strongswan/x509_state_name
Type: string
-Default:
+_Default: Upper Austria
_Description: State or province name for the X.509 certificate request:
- Please enter the full name of the state or province you live in. This name
- will be placed in the certificate request.
- .
- Example: Upper Austria
+ Please enter the full state or province name that should be used in the
+ certificate request.
Template: strongswan/x509_locality_name
Type: string
-Default:
+_Default: Vienna
_Description: Locality name for the X.509 certificate request:
- Please enter the locality (e.g. city) where you live. This name will be
- placed in the certificate request.
- .
- Example: Vienna
+ Please enter the locality name (often a city) that should be used in the
+ certificate request.
Template: strongswan/x509_organization_name
Type: string
-Default:
+_Default: Debian
_Description: Organization name for the X.509 certificate request:
- Please enter the organization (e.g. company) that the X.509 certificate
- should be created for. This name will be placed in the certificate
- request.
+ Please enter the organization name (often a company) that should be used
+ in the certificate request.
.
- Example: Debian
-
Template: strongswan/x509_organizational_unit
Type: string
Default:
_Description: Organizational unit for the X.509 certificate request:
- Please enter the organizational unit (e.g. section) that the X.509
- certificate should be created for. This name will be placed in the
- certificate request.
- .
- Example: security group
+ Please enter the organizational unit name (often a department) that
+ should be used in the certificate request.
Template: strongswan/x509_common_name
Type: string
Default:
_Description: Common name for the X.509 certificate request:
- Please enter the common name (e.g. the host name of this machine) for
- which the X.509 certificate should be created for. This name will be placed
- in the certificate request.
- .
- Example: gateway.debian.org
+ Please enter the common name (often the host name of the machine) that
+ should be used in the certificate request.
Template: strongswan/x509_email_address
Type: string
Default:
_Description: Email address for the X.509 certificate request:
- Please enter the email address of the person or organization who is
- responsible for the X.509 certificate. This address will be placed in the
- certificate request.
+ Please enter the email address (for the individual or organization
+ responsible) that should be used in the certificate request.
Template: strongswan/enable-oe
Type: boolean
Default: false
-_Description: Do you wish to enable opportunistic encryption in strongSwan?
- strongSwan comes with support for opportunistic encryption (OE), which stores
- IPSec authentication information (i.e. RSA public keys) in (preferably
- secure) DNS records. Until this is widely deployed, activating it will
- cause a significant slow-down for every new, outgoing connection. Since
- version 2.0, strongSwan upstream comes with OE enabled by default and is thus
- likely to break your existing connection to the Internet (i.e. your default
- route) as soon as pluto (the strongSwan keying daemon) is started.
- .
- Please choose whether you want to enable support for OE. If unsure, do not
- enable it.
+_Description: Enable opportunistic encryption?
+ This version of strongSwan supports opportunistic encryption (OE), which stores
+ IPSec authentication information in
+ DNS records. Until this is widely deployed, activating it will
+ cause a significant delay for every new outgoing connection.
+ .
+ You should only enable opportunistic encryption if you are sure you want it.
+ It may break the Internet connection (default route) as the pluto daemon
+ starts.
--- ../strongswan-4.2.14.pristine/debian/control 2009-04-21 10:05:35.000000000 +0100
+++ debian/control 2009-04-26 13:52:19.000000000 +0100
@@ -11,28 +11,26 @@
Depends: strongswan-ikev1, strongswan-ikev2
Suggests: network-manager-strongswan
Description: IPsec VPN solution metapackage
- strongSwan is a IPsec based VPN solution for the Linux kernel. It uses the
- native IPsec stack and runs on any recent 2.6 kernel (no patching required).
- It supports both IKEv1 and the newer IKEv2 protocols.
- .
- strongSwan is one of the two remaining forks of the original FreeS/WAN
- project and focuses on IKEv2 support, X.509 authentication and complete PKI
- support. For a focus on Opportunistic Encryption (OE) and interoperability
+ The strongSwan VPN solution is based on the IPsec stack in standard
+ Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
+ .
+ StrongSwan is one of the two remaining forks of the original FreeS/WAN
+ project and focuses on IKEv2 support, X.509 authentication and complete PKI
+ support. For a focus on Opportunistic Encryption (OE) and interoperability
with non-standard IPsec features, see Openswan.
.
- This metapackage has dependencies to the IKEv1 daemon pluto and IKEv2 daemon
- charon. It installs the required packages to run IKEv1 and IKEv2 connections
- using a ipsec.conf/ipsec.secrets based configuration.
+ This metapackage depends on the IKEv1 daemon, pluto, and IKEv2 daemon,
+ charon. It installs the packages required to run IKEv1 and IKEv2
+ connections configured via ipsec.conf or ipsec.secrets.
Package: libstrongswan
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, openssl
Description: strongSwan utility and crypto library
- strongSwan is a IPsec based VPN solution for the Linux kernel. It uses the
- native IPsec stack and runs on any recent 2.6 kernel (no patching required).
- It supports both IKEv1 and the newer IKEv2 protocols.
+ The strongSwan VPN solution is based on the IPsec stack in standard
+ Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
- libstrongswan is the underlying library of charon and other strongSwan
+ This package provides the underlying library of charon and other strongSwan
components. It is built in a modular way and is extendable through various
plugins.
@@ -40,9 +38,8 @@
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libstrongswan, strongswan-ikev1 | strongswan-ikev2
Description: strongSwan daemon starter and configuration file parser
- strongSwan is a IPsec based VPN solution for the Linux kernel. It uses the
- native IPsec stack and runs on any recent 2.6 kernel (no patching required).
- It supports both IKEv1 and the newer IKEv2 protocols.
+ The strongSwan VPN solution is based on the IPsec stack in standard
+ Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
The starter and the associated "ipsec" script control both pluto and charon
from the command line. It parses ipsec.conf and loads the configurations to
@@ -57,12 +54,11 @@
Provides: ike-server
Conflicts: freeswan (<< 2.04-12), openswan
Replaces: openswan
-Description: strongSwan IKEv1 keying daemon
- strongSwan is a IPsec based VPN solution for the Linux kernel. It uses the
- native IPsec stack and runs on any recent 2.6 kernel (no patching required).
- It supports both IKEv1 and the newer IKEv2 protocols.
+Description: strongSwan Internet Key Exchange (v1) daemon
+ The strongSwan VPN solution is based on the IPsec stack in standard
+ Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
- Pluto is a IPsec IKEv1 keying daemon. It was inherited from the FreeS/WAN
+ Pluto is an IPsec IKEv1 daemon. It was inherited from the FreeS/WAN
project, but provides improved X.509 certificate support and other features.
.
Pluto can run in parallel with charon, the newer IKEv2 daemon.
@@ -74,12 +70,11 @@
Suggests: curl
Provides: ike-server
Conflicts: freeswan (<< 2.04-12), openswan
-Description: strongSwan IKEv2 keying daemon
- strongSwan is a IPsec based VPN solution for the Linux kernel. It uses the
- native IPsec stack and runs on any recent 2.6 kernel (no patching required).
- It supports both IKEv1 and the newer IKEv2 protocols.
+Description: strongSwan Internet Key Exchange (v2) daemon
+ The strongSwan VPN solution is based on the IPsec stack in standard
+ Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
- Charon is the IPsec IKEv2 keying daemon of the strongSwan project. It is
+ Charon is an IPsec IKEv2 daemon. It is
written from scratch using a fully multi-threaded design and a modular
architecture. Various plugins provide additional functionality.
.
@@ -90,11 +85,10 @@
Depends: ${shlibs:Depends}, strongswan-ikev2
Recommends: network-manager-strongswan
Description: strongSwan plugin to interact with NetworkManager
- strongSwan is a IPsec based VPN solution for the Linux kernel. It uses the
- native IPsec stack and runs on any recent 2.6 kernel (no patching required).
- It supports both IKEv1 and the newer IKEv2 protocols.
+ The strongSwan VPN solution is based on the IPsec stack in standard
+ Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
This plugin provides an interface which allows NetworkManager to configure
- and control the IKEv2 daemon directly through DBUS. It is designed to work
+ and control the IKEv2 daemon directly through D-Bus. It is designed to work
in conjunction with the network-manager-strongswan package, providing
- a simple graphical frontend to configure IPsec based VPNs.
+ a simple graphical frontend to configure IPsec-based VPNs.
Template: strongswan/start_level
Type: select
__Choices: earliest, after NFS, after PCMCIA
Default: earliest
_Description: When to start strongSwan:
StrongSwan starts during system startup so that it can protect filesystems
that are automatically mounted. There are three options for when it can be
started:
.
* earliest: if /usr is not mounted through NFS and you don't use a
PCMCIA network card, it is best to start strongSwan as soon as
possible, so that NFS mounts can be secured by IPSec;
* after NFS: recommended when /usr is mounted through NFS and no
PCMCIA network card is used;
* after PCMCIA: recommended if the IPSec connection uses a PCMCIA
network card, or if it needs keys fetched from a locally running DNS
server with DNSSec support.
Template: strongswan/restart
Type: boolean
Default: true
_Description: Restart strongSwan now?
Restarting strongSwan is recommended, because if there is a security fix, it
will not be applied until the daemon restarts. However, this might close
existing connections and then bring them back up.
Template: strongswan/ikev1
Type: boolean
Default: true
_Description: Start strongSwan's IKEv1 daemon?
The pluto daemon can be run to support version one of the Internet Key
Exchange protocol.
Template: strongswan/ikev2
Type: boolean
Default: true
_Description: Start strongSwan's IKEv2 daemon?
The charon daemon can be run to support version two of the Internet Key
Exchange protocol.
Template: strongswan/create_rsa_key
Type: boolean
Default: true
_Description: Create an RSA public/private keypair for this host?
StrongSwan can use a Pre-Shared Key (PSK) or an RSA keypair to authenticate
IPSec connections to other hosts. RSA authentication is generally considered
more secure and is easier to administer. You can use PSK and RSA authentication
simultaneously.
.
If you do not want to create a new public/private keypair, you can choose to
use an existing one in the next step.
Template: strongswan/existing_x509_certificate
Type: boolean
Default: false
_Description: Use an existing X.509 certificate for strongSwan?
This installer can automatically extract the needed information from an
existing X.509 certificate with a matching RSA private key. Both parts can
be in one file, if it is in PEM format.
.
You should choose this option if you have such an existing
certificate and key file and want to use it for authenticating IPSec
connections.
Template: strongswan/existing_x509_certificate_filename
Type: string
_Description: File name of existing X.509 certificate in PEM format:
Please enter the full location of the file containing your X.509
certificate in PEM format.
Template: strongswan/existing_x509_key_filename
Type: string
_Description: File name of existing X.509 private key in PEM format:
Please enter the full location of the file containing the private RSA key
matching your X.509 certificate in PEM format. This can be the same file
as the X.509 certificate.
Template: strongswan/rsa_key_length
Type: string
Default: 2048
_Description: RSA key length:
Please enter the length of RSA key you wish to generate. A value of less than
1024 bits is not considered secure. A value of more than 2048 bits will
probably affect performance.
Template: strongswan/x509_self_signed
Type: boolean
Default: true
_Description: Create a self-signed X.509 certificate?
Only self-signed X.509 certificates can be created automatically, because
otherwise a certificate authority is needed to sign the certificate
request.
.
If you accept this option, the certificate created can be used
immediately to connect to other IPSec hosts that support authentication
via X.509 certificate. However, using strongSwan's PKI features requires
a trust path created by having all X.509 certificates signed by a single
authority.
.
If you do not accept this option, only the RSA private key will be
created, along with a certificate request which you will need to have
signed by a certificate authority.
Template: strongswan/x509_country_code
Type: string
_Default: AT
_Description: Country code for the X.509 certificate request:
Please enter the two-letter ISO3166 country code that should be used in
the certificate request.
.
This field is mandatory; otherwise a certificate cannot be generated.
Template: strongswan/x509_state_name
Type: string
_Default: Upper Austria
_Description: State or province name for the X.509 certificate request:
Please enter the full state or province name that should be used in the
certificate request.
Template: strongswan/x509_locality_name
Type: string
_Default: Vienna
_Description: Locality name for the X.509 certificate request:
Please enter the locality name (often a city) that should be used in the
certificate request.
Template: strongswan/x509_organization_name
Type: string
_Default: Debian
_Description: Organization name for the X.509 certificate request:
Please enter the organization name (often a company) that should be used
in the certificate request.
.
Template: strongswan/x509_organizational_unit
Type: string
Default:
_Description: Organizational unit for the X.509 certificate request:
Please enter the organizational unit name (often a department) that
should be used in the certificate request.
Template: strongswan/x509_common_name
Type: string
Default:
_Description: Common name for the X.509 certificate request:
Please enter the common name (often the host name of the machine) that
should be used in the certificate request.
Template: strongswan/x509_email_address
Type: string
Default:
_Description: Email address for the X.509 certificate request:
Please enter the email address (for the individual or organization
responsible) that should be used in the certificate request.
Template: strongswan/enable-oe
Type: boolean
Default: false
_Description: Enable opportunistic encryption?
This version of strongSwan supports opportunistic encryption (OE), which stores
IPSec authentication information in
DNS records. Until this is widely deployed, activating it will
cause a significant delay for every new outgoing connection.
.
You should only enable opportunistic encryption if you are sure you want it.
It may break the Internet connection (default route) as the pluto daemon
starts.
Source: strongswan
Section: net
Priority: optional
Maintainer: Rene Mayrhofer <rmayr@debian.org>
Standards-Version: 3.8.1
Build-Depends: debhelper (>= 7.0.0), libtool, libgmp3-dev, libssl-dev (>= 0.9.8), libcurl4-openssl-dev | libcurl3-dev | libcurl2-dev, libopensc2-dev | libopensc1-dev | libopensc0-dev, libldap2-dev, libpam0g-dev, libkrb5-dev, bison, flex, dpatch, bzip2, po-debconf, hardening-wrapper, network-manager-dev, libfcgi-dev, clearsilver-dev, libxml2-dev, libsqlite3-dev, network-manager-dev (>= 0.7), libnm-glib-vpn-dev (>= 0.7), libnm-util-dev (>= 0.7)
Homepage: http://www.strongswan.org
Package: strongswan
Architecture: all
Depends: strongswan-ikev1, strongswan-ikev2
Suggests: network-manager-strongswan
Description: IPsec VPN solution metapackage
The strongSwan VPN solution is based on the IPsec stack in standard
Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
StrongSwan is one of the two remaining forks of the original FreeS/WAN
project and focuses on IKEv2 support, X.509 authentication and complete PKI
support. For a focus on Opportunistic Encryption (OE) and interoperability
with non-standard IPsec features, see Openswan.
.
This metapackage depends on the IKEv1 daemon, pluto, and IKEv2 daemon,
charon. It installs the packages required to run IKEv1 and IKEv2
connections configured via ipsec.conf or ipsec.secrets.
Package: libstrongswan
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, openssl
Description: strongSwan utility and crypto library
The strongSwan VPN solution is based on the IPsec stack in standard
Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
This package provides the underlying library of charon and other strongSwan
components. It is built in a modular way and is extendable through various
plugins.
Package: strongswan-starter
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libstrongswan, strongswan-ikev1 | strongswan-ikev2
Description: strongSwan daemon starter and configuration file parser
The strongSwan VPN solution is based on the IPsec stack in standard
Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
The starter and the associated "ipsec" script control both pluto and charon
from the command line. It parses ipsec.conf and loads the configurations to
the daemons. While the IKEv2 daemon can use other configuration backends, the
IKEv1 daemon is limited to configurations from ipsec.conf.
Package: strongswan-ikev1
Architecture: any
Pre-Depends: debconf | debconf-2.0
Depends: ${shlibs:Depends}, ${misc:Depends}, strongswan-starter, bsdmainutils, debianutils (>=1.7), ipsec-tools, host, iproute
Suggests: curl
Provides: ike-server
Conflicts: freeswan (<< 2.04-12), openswan
Replaces: openswan
Description: strongSwan Internet Key Exchange (v1) daemon
The strongSwan VPN solution is based on the IPsec stack in standard
Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
Pluto is an IPsec IKEv1 daemon. It was inherited from the FreeS/WAN
project, but provides improved X.509 certificate support and other features.
.
Pluto can run in parallel with charon, the newer IKEv2 daemon.
Package: strongswan-ikev2
Architecture: any
Pre-Depends: debconf | debconf-2.0
Depends: ${shlibs:Depends}, ${misc:Depends}, libstrongswan, strongswan-starter | strongswan-nm, bsdmainutils, debianutils (>=1.7), ipsec-tools, host, iproute
Suggests: curl
Provides: ike-server
Conflicts: freeswan (<< 2.04-12), openswan
Description: strongSwan Internet Key Exchange (v2) daemon
The strongSwan VPN solution is based on the IPsec stack in standard
Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
Charon is an IPsec IKEv2 daemon. It is
written from scratch using a fully multi-threaded design and a modular
architecture. Various plugins provide additional functionality.
.
This build of charon can run in parallel with pluto, the IKEv1 daemon.
Package: strongswan-nm
Architecture: any
Depends: ${shlibs:Depends}, strongswan-ikev2
Recommends: network-manager-strongswan
Description: strongSwan plugin to interact with NetworkManager
The strongSwan VPN solution is based on the IPsec stack in standard
Linux 2.6 kernels. It supports both the IKEv1 and IKEv2 protocols.
.
This plugin provides an interface which allows NetworkManager to configure
and control the IKEv2 daemon directly through D-Bus. It is designed to work
in conjunction with the network-manager-strongswan package, providing
a simple graphical frontend to configure IPsec-based VPNs.
Reply to: