1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
|
Template: strongswan/start_level
Type: select
_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.
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
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?
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?
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.
.
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: Do you have an existing X.509 certificate file 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
certificate and key file and want to use it for authenticating IPSec
connections, then please answer yes.
Template: strongswan/existing_x509_certificate_filename
Type: string
_Description: File name of your 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:
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.
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.
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
authority.
Template: strongswan/x509_country_code
Type: string
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.
.
Example: AT
Template: strongswan/x509_state_name
Type: string
Default:
_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
Template: strongswan/x509_locality_name
Type: string
Default:
_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
Template: strongswan/x509_organization_name
Type: string
Default:
_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.
.
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
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
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.
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.
|
