]>
Commit | Line | Data |
---|---|---|
997358a6 MW |
1 | ---------------------------- |
2 | strongSwan - Configuration | |
3 | ---------------------------- | |
4 | ||
5 | ||
6 | Contents | |
7 | -------- | |
8 | ||
9 | 1. Overview | |
10 | 2. Quickstart | |
11 | 2.1 Site-to-Site case | |
12 | 2.2 Host-to-Host case | |
13 | 2.3 Four Tunnel case | |
14 | 2.4 Four Tunnel case the elegant way with source routing | |
15 | 2.5 Roadwarrior case | |
16 | 2.6 Roadwarrior case with virtual IP | |
17 | 3. Generating X.509 certificates and CRLs with OpenSSL | |
18 | 3.1 Generating a CA certificate | |
19 | 3.2 Generating a host or user certificate | |
20 | 3.3 Generating a CRL | |
21 | 3.4 Revoking a certificate | |
22 | 4. Configuring the connections - ipsec.conf | |
23 | 4.1 Configuring my side | |
24 | 4.2 Multiple certificates | |
25 | 4.3 Configuring the peer side using CA certificates | |
26 | 4.4 Handling Virtual IPs and wildcard subnets | |
27 | 4.5 Protocol and port selectors | |
28 | 4.6 IPsec policies based on wildcards | |
29 | 4.7 IPsec policies based on CA certificates | |
30 | 4.8 Sending certificate requests | |
31 | 4.9 IPsec policies based on group attributes | |
32 | 5. Configuring certificates and CRLs | |
33 | 5.1 Installing CA certificates | |
34 | 5.2 Installing optional Certificate Revocation Lists (CRLs) | |
35 | 5.3 Dynamic update of certificates and CRLs | |
36 | 5.4 Local caching of CRLs | |
37 | 5.5 Online Certificate Status Protocol (OCSP) | |
38 | 5.6 CRL policy | |
39 | 5.7 Configuring the peer side using locally stored certificates | |
40 | 6. Configuring the private keys - ipsec.secrets | |
41 | 6.1 Loading private key files in PKCS#1 format | |
42 | 6.2 Entering passphrases interactively | |
43 | 6.3 Multiple private keys | |
44 | 7. Configuring CA properties - ipsec.conf | |
45 | 8. Smartcard support | |
46 | 8.1 Configuring a smartcard-based connection | |
47 | 8.2 Entering the PIN code | |
48 | 8.3 PIN-pad equipped smartcard readers | |
49 | 8.4 Configuring a smartcard using pkcs15-init | |
50 | 8.5 PKCS#1 proxy functions | |
51 | 9. Configuring the clients | |
52 | 9.1 strongSwan | |
53 | 9.2 PGPnet | |
54 | 9.3 Safenet/Soft-Remote | |
55 | 9.4 SSH Sentinel | |
56 | 9.5 Windows 2000/XP | |
57 | 10. Monitoring functions | |
58 | 11. Firewall support functions | |
59 | 11.1 Environment variables in the updown script | |
60 | 11.2 Automatic insertion and deletion of iptables firewall rules (NEW) | |
61 | 11.3 Sample Linux 2.6 _updown_espmark script for iptables < 1.3.5 | |
62 | 12. Authentication with raw RSA public keys | |
63 | 13. Authentication with OpenPGP certificates | |
64 | 13.1 OpenPGP certificates | |
65 | 13.2 OpenPGP private keys | |
66 | 13.3 Monitoring functions | |
67 | 13.4 Suppression of certificate request messages | |
68 | 14. Additional features | |
69 | 14.1 Authentication and encryption algorithms | |
70 | 14.2 NAT traversal | |
71 | 14.3 Dead peer detection | |
72 | 14.4 IKE Mode Config | |
73 | 15. Copyright statement and acknowledgements | |
74 | ||
75 | ||
76 | 1. Overview | |
77 | -------- | |
78 | ||
79 | strongSwan is an OpenSource IPsec solution for the Linux operating system | |
80 | and currently supports the following features: | |
81 | ||
82 | * runs both on Linux 2.4 (KLIPS) and Linux 2.6 (native IPsec) kernels. | |
83 | ||
84 | * strong 3DES, AES, Serpent, Twofish, or Blowfish encryption. | |
85 | ||
86 | * Authentication based on X.509 certificates or preshared secrets. | |
87 | ||
88 | * IPsec policies based on wildcards or intermediate CAs. | |
89 | ||
90 | * Powerful and flexible IPsec policies based on group attributes. | |
91 | ||
92 | * Retrieval of Certificate Revocation Lists (CRLs) via HTTP or LDAP. | |
93 | ||
94 | * Local caching of fetched CRLs | |
95 | ||
96 | * Full support of the Online Certificate Status Protocol (OCSP, RFC 2560). | |
97 | ||
98 | * CA management functions including OCSP and CRL URIs and default LDAP server. | |
99 | ||
100 | * Optional storage of RSA private keys on smartcards or USB crypto tokens | |
101 | ||
102 | * Standardized PKCS#11 interface with optional proxy functions serving | |
103 | external applications (disc encryption, etc.). | |
104 | ||
105 | * NAT-Traversal (RFC 3947) | |
106 | ||
107 | * Support of Virtual IPs via static configuratin and IKE Mode Config | |
108 | ||
109 | * Support of Delete SA and informational Notification messages. | |
110 | ||
111 | * Dead Peer Detection (DPD, RFC 3706) | |
112 | ||
113 | Compatibility has successfully been tested with peers running the following | |
114 | IPsec clients: | |
115 | ||
116 | FreeS/WAN, Openswan, SafeNet/SoftRemote, NCP Secure Entry Client, | |
117 | SonicWALL Global VPN Client, The GreenBow, Microsoft Windows 2000/XP, etc. | |
118 | ||
119 | Furthermore, interoperability with the following VPN gateways | |
120 | has been demonstrated during the IPsec 2001 Conference in Paris: | |
121 | ||
122 | Cisco IOS Routers, Cisco PIX firewall, Cisco VPN3000, | |
123 | Nortel Contivity VPN Switch, NetScreen (FreeS/WAN as responder only), | |
124 | OpenBSD with isakmpd, Netasq, Netcelo, and 6WIND. | |
125 | ||
126 | Potentially any IPsec implementation with X.509 certificate support can | |
127 | be made to cooperate with strongSwan. The latest addition has been the successful | |
128 | interoperability with the Check Point VPN-1 NG gateway. | |
129 | ||
130 | ||
131 | 2. Quickstart | |
132 | ---------- | |
133 | ||
134 | In the following examples we assume for reasons of clarity that left designates | |
135 | the local host and that right is the remote host. Certificates for users, hosts | |
136 | and gateways are issued by a ficticious strongSwan CA. How to generate private keys | |
137 | and certificates using OpenSSL will be explained in section 3. The CA certificate | |
138 | "strongswanCert.pem" must be present on all VPN end points in order to be able to | |
139 | authenticate the peers. | |
140 | ||
141 | ||
142 | 2.1 Site-to-site case | |
143 | ----------------- | |
144 | ||
145 | In this scenario two security gateways moon and sun will connect the | |
146 | two subnets moon-net and sun-net with each other through a VPN tunnel | |
147 | set up between the two gateways: | |
148 | ||
149 | 10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16 | |
150 | moon-net moon sun sun-net | |
151 | ||
152 | Configuration on gateway moon: | |
153 | ||
154 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
155 | ||
156 | /etc/ipsec.d/certs/moonCert.pem | |
157 | ||
158 | /etc/ipsec.secrets: | |
159 | ||
160 | : RSA moonKey.pem "<optional passphrase>" | |
161 | ||
162 | /etc/ipsec.conf: | |
163 | ||
164 | conn net-net | |
165 | left=%defaultroute | |
166 | leftsubnet=10.1.0.0/16 | |
167 | leftcert=moonCert.pem | |
168 | right=192.168.0.2 | |
169 | rightsubnet=10.2.0.0/16 | |
170 | rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" | |
171 | auto=start | |
172 | ||
173 | Configuration on gateway sun: | |
174 | ||
175 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
176 | ||
177 | /etc/ipsec.d/certs/sunCert.pem | |
178 | ||
179 | /etc/ipsec.secrets: | |
180 | ||
181 | : RSA sunKey.pem "<optional passphrase>" | |
182 | ||
183 | /etc/ipsec.conf: | |
184 | ||
185 | conn net-net | |
186 | left=%defaultroute | |
187 | leftsubnet=10.2.0.0/16 | |
188 | leftcert=sunCert.pem | |
189 | right=192.168.0.1 | |
190 | rightsubnet=10.1.0.0/16 | |
191 | rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" | |
192 | auto=start | |
193 | ||
194 | ||
195 | 2.2 Host-to-host case | |
196 | ----------------- | |
197 | ||
198 | This is a setup between two single hosts which don't have a subnet behind | |
199 | them. Although IPsec transport mode would be sufficient for host-to-host | |
200 | connections we will use the default IPsec tunnel mode. | |
201 | ||
202 | | 192.168.0.1 | === | 192.168.0.2 | | |
203 | moon sun | |
204 | ||
205 | Configuration on host moon: | |
206 | ||
207 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
208 | ||
209 | /etc/ipsec.d/certs/moonCert.pem | |
210 | ||
211 | /etc/ipsec.secrets: | |
212 | ||
213 | : RSA moonKey.pem "<optional passphrase>" | |
214 | ||
215 | /etc/ipsec.conf: | |
216 | ||
217 | conn host-host | |
218 | left=%defaultroute | |
219 | leftcert=moonCert.pem | |
220 | right=192.168.0.2 | |
221 | rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" | |
222 | auto=start | |
223 | ||
224 | Configuration on host sun: | |
225 | ||
226 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
227 | ||
228 | /etc/ipsec.d/certs/sunCert.pem | |
229 | ||
230 | /etc/ipsec.secrets: | |
231 | ||
232 | : RSA sunKey.pem "<optional passphrase>" | |
233 | ||
234 | /etc/ipsec.conf: | |
235 | ||
236 | conn host-host | |
237 | left=%defaultroute | |
238 | leftcert=sunCert.pem | |
239 | right=192.168.0.1 | |
240 | rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" | |
241 | auto=start | |
242 | ||
243 | ||
244 | 2.3 Four Tunnel case | |
245 | ---------------- | |
246 | ||
247 | In a site-to-site setup a system administrator logged into the local gateway | |
248 | often would like to access the peer gateway or a server in the subnet behind | |
249 | the peer gateway over a secure IPsec tunnel.Since IP packets leaving a gateway | |
250 | via the outer network interface carry the IP address of this NIC, four IPsec | |
251 | Security Associations (SAs) must be set up to achieve full connectivity. The | |
252 | example below shows how this can be done without much additional typing work , | |
253 | using the "also" macro which includes connection definitions defined farther | |
254 | down in the ipsec.conf file. | |
255 | ||
256 | 10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16 | |
257 | moon-net moon sun sun-net | |
258 | ||
259 | Configuration on gateway moon: | |
260 | ||
261 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
262 | ||
263 | /etc/ipsec.d/certs/moonCert.pem | |
264 | ||
265 | /etc/ipsec.secrets: | |
266 | ||
267 | : RSA moonKey.pem "<optional passphrase>" | |
268 | ||
269 | /etc/ipsec.conf: | |
270 | ||
271 | conn net-net | |
272 | leftsubnet=10.1.0.0/16 | |
273 | rightsubnet=10.2.0.0/16 | |
274 | also host-host | |
275 | ||
276 | conn net-host | |
277 | leftsubnet=10.1.0.0/16 | |
278 | also host-host | |
279 | ||
280 | conn host-net | |
281 | rightsubnet=10.2.0.0/16 | |
282 | also host-host | |
283 | ||
284 | conn host-host | |
285 | left=%defaultroute | |
286 | leftcert=moonCert.pem | |
287 | right=192.168.0.2 | |
288 | rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" | |
289 | auto=start | |
290 | ||
291 | Configuration on gateway sun: | |
292 | ||
293 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
294 | ||
295 | /etc/ipsec.d/certs/sunCert.pem | |
296 | ||
297 | /etc/ipsec.secrets: | |
298 | ||
299 | : RSA sunKey.pem "<optional passphrase>" | |
300 | ||
301 | /etc/ipsec.conf: | |
302 | ||
303 | conn net-net | |
304 | leftsubnet=10.2.0.0/16 | |
305 | rightsubnet=10.1.0.0/16 | |
306 | also=host-host | |
307 | ||
308 | conn net-host | |
309 | leftsubnet=10.2.0.0/16 | |
310 | also=host-host | |
311 | ||
312 | conn host-net | |
313 | rightsubnet=10.1.0.0/16 | |
314 | also=host-host | |
315 | ||
316 | conn host-host | |
317 | left=%defaultroute | |
318 | leftcert=sunCert.pem | |
319 | right=192.168.0.1 | |
320 | rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" | |
321 | auto=start | |
322 | ||
323 | ||
324 | 2.4 The four tunnel case the elegant way with source routing | |
325 | -------------------------------------------------------- | |
326 | ||
327 | As you certainly agree, the full four tunnel case described in the previous | |
328 | section becomes quite complex. If we could force the source address of the | |
329 | IP packets leaving the gateway through the outer interface to take on the | |
330 | IP address of the inner interface then we could use the single subnet-to-subnet | |
331 | tunnel from section 2.1. Such a setup becomes possible if we use the | |
332 | source routing capabilites of the ip route command that is already used | |
333 | by strongSwan's updown scripts. | |
334 | ||
335 | 10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16 | |
336 | moon-net moon sun sun-net | |
337 | ||
338 | If we assume that the inner IP address of gateway moon is 10.1.0.1 | |
339 | and the inner IP address of gateway sun is 10.2.0.1 then the | |
340 | insertion of the parameter | |
341 | ||
342 | leftsourceip=10.1.0.1 | |
343 | ||
344 | in the connection definition of moon and | |
345 | ||
346 | leftsourceip=10.2.0.1 | |
347 | ||
348 | on sun, respectively, will install source routing on both gateways. | |
349 | As a result the command | |
350 | ||
351 | ping 10.2.0.1 | |
352 | ||
353 | executed on moon will leave the gateway with a source address of | |
354 | 10.1.0.1 and will therefore take the net-net IPsec tunnel. | |
355 | ||
356 | Configuration on gateway moon: | |
357 | ||
358 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
359 | ||
360 | /etc/ipsec.d/certs/moonCert.pem | |
361 | ||
362 | /etc/ipsec.secrets: | |
363 | ||
364 | : RSA moonKey.pem "<optional passphrase>" | |
365 | ||
366 | /etc/ipsec.conf: | |
367 | ||
368 | conn net-net | |
369 | left=%defaultroute | |
370 | leftsourceip=10.1.0.1 | |
371 | leftsubnet=10.1.0.0/16 | |
372 | leftcert=moonCert.pem | |
373 | right=192.168.0.2 | |
374 | rightsubnet=10.2.0.0/16 | |
375 | rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" | |
376 | auto=start | |
377 | ||
378 | Configuration on gateway sun: | |
379 | ||
380 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
381 | ||
382 | /etc/ipsec.d/certs/sunCert.pem | |
383 | ||
384 | /etc/ipsec.secrets: | |
385 | ||
386 | : RSA sunKey.pem "<optional passphrase>" | |
387 | ||
388 | /etc/ipsec.conf: | |
389 | ||
390 | conn net-net | |
391 | left=%defaultroute | |
392 | leftsubnet=10.2.0.0/16 | |
393 | leftsourceip=10.2.0.1 | |
394 | leftcert=sunCert.pem | |
395 | right=192.168.0.1 | |
396 | rightsubnet=10.1.0.0/16 | |
397 | rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" | |
398 | auto=start | |
399 | ||
400 | ||
401 | 2.5 Roadwarrior case | |
402 | ---------------- | |
403 | ||
404 | This is a very common case where a strongSwan gateway serves an arbitrary number | |
405 | of remote VPN clients usually having dynamic IP addresses. | |
406 | ||
407 | 10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | | |
408 | moon-net moon carol | |
409 | ||
410 | Configuration on gateway moon: | |
411 | ||
412 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
413 | ||
414 | /etc/ipsec.d/certs/moonCert.pem | |
415 | ||
416 | /etc/ipsec.secrets: | |
417 | ||
418 | : RSA moonKey.pem "<optional passphrase>" | |
419 | ||
420 | /etc/ipsec.conf: | |
421 | ||
422 | conn rw | |
423 | left=%defaultroute | |
424 | leftsubnet=10.1.0.0/16 | |
425 | leftcert=moonCert.pem | |
426 | right=%any | |
427 | auto=add | |
428 | ||
429 | Configuration on roadwarrior carol: | |
430 | ||
431 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
432 | ||
433 | /etc/ipsec.d/certs/carolCert.pem | |
434 | ||
435 | /etc/ipsec.secrets: | |
436 | ||
437 | : RSA carolKey.pem "<optional passphrase>" | |
438 | ||
439 | /etc/ipsec.conf: | |
440 | ||
441 | conn home | |
442 | left=%defaultroute | |
443 | leftcert=carolCert.pem | |
444 | right=192.168.0.1 | |
445 | rightsubnet=10.1.0.0/16 | |
446 | rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" | |
447 | auto=start | |
448 | ||
449 | ||
450 | 2.6 Roadwarrior case with virtual IP | |
451 | -------------------------------- | |
452 | ||
453 | Roadwarriors usually have dynamic IP addresses assigned by the ISP they are | |
454 | currently attached to. In order to simplify the routing from moon-net back | |
455 | to the remote access client carol it would be desirable if the roadwarrior had | |
456 | an inner IP address chosen from a pre-assigned pool. | |
457 | ||
458 | 10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | -- 10.3.0.1 | |
459 | moon-net moon carol virtual IP | |
460 | ||
461 | This virtual IP address can be assigned to a strongSwan roadwarrior by adding | |
462 | the parameter | |
463 | ||
464 | leftsourceip=10.3.0.1 | |
465 | ||
466 | to the roadwarrior's ipsec.conf. Of course the virtual IP of each roadwarrior | |
467 | must be distinct. In our example it is chosen from the address pool | |
468 | ||
469 | rightsubnetwithin=10.3.0.0/16 | |
470 | ||
471 | which can be added to the gateway's ipsec.conf so that a single connection | |
472 | definition can handle multiple roadwarriors. | |
473 | ||
474 | Configuration on gateway moon: | |
475 | ||
476 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
477 | ||
478 | /etc/ipsec.d/certs/moonCert.pem | |
479 | ||
480 | /etc/ipsec.secrets: | |
481 | ||
482 | : RSA moonKey.pem "<optional passphrase>" | |
483 | ||
484 | /etc/ipsec.conf: | |
485 | ||
486 | conn rw | |
487 | left=%defaultroute | |
488 | leftsubnet=10.1.0.0/16 | |
489 | leftcert=moonCert.pem | |
490 | right=%any | |
491 | rightsubnetwithin=10.3.0.0/16 | |
492 | auto=add | |
493 | ||
494 | Configuration on roadwarrior carol: | |
495 | ||
496 | /etc/ipsec.d/cacerts/strongswanCert.pem | |
497 | ||
498 | /etc/ipsec.d/certs/carolCert.pem | |
499 | ||
500 | /etc/ipsec.secrets: | |
501 | ||
502 | : RSA carolKey.pem "<optional passphrase>" | |
503 | ||
504 | /etc/ipsec.conf: | |
505 | ||
506 | conn home | |
507 | left=%defaultroute | |
508 | leftsourceip=10.3.0.1 | |
509 | leftcert=carolCert.pem | |
510 | right=192.168.0.1 | |
511 | rightsubnet=10.1.0.0/16 | |
512 | rightid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" | |
513 | auto=start | |
514 | ||
515 | ||
516 | 3. Generating certificates and CRLs with OpenSSL | |
517 | --------------------------------------------- | |
518 | ||
519 | This section is not a full-blown tutorial on how to use OpenSSL. It just lists | |
520 | a few points that are relevant if you want to generate your own certificates | |
521 | and CRLs for use with strongSwan. | |
522 | ||
523 | ||
524 | 3.1 Generating a CA certificate | |
525 | --------------------------- | |
526 | ||
527 | The OpenSSL statement | |
528 | ||
529 | openssl req -x509 -days 1460 -newkey rsa:2048 \ | |
530 | -keyout strongswanKey.pem -out strongswanCert.pem | |
531 | ||
532 | creates a 2048 bit RSA private key strongswanKey.pem and a self-signed CA | |
533 | certificate strongswanCert.pem with a validity of 4 years (1460 days). | |
534 | ||
535 | openssl x509 -in cert.pem -noout -text | |
536 | ||
537 | lists the properties of a X.509 certificate cert.pem. It allows you to verify | |
538 | whether the configuration defaults in openssl.cnf have been inserted correctly. | |
539 | ||
540 | If you prefer the CA certificate to be in binary DER format then the following | |
541 | command achieves this transformation: | |
542 | ||
543 | openssl x509 -in strongswanCert.pem -outform DER -out strongswanCert.der | |
544 | ||
545 | The directory /etc/ipsec.d/cacerts contains all required CA certificates either | |
546 | in binary DER or in base64 PEM format. Irrespective of the file suffix, Pluto | |
547 | "automagically" determines the correct format. | |
548 | ||
549 | ||
550 | 3.2 Generating a host or user certificate | |
551 | ------------------------------------- | |
552 | ||
553 | The OpenSSL statement | |
554 | ||
555 | openssl req -newkey rsa:1024 -keyout hostKey.pem \ | |
556 | -out hostReq.pem | |
557 | ||
558 | generates a 1024 bit RSA private key hostKey.pem and a certificate request | |
559 | hostReq.pem which has to be signed by the CA. | |
560 | ||
561 | If you want to add a subjectAltName field to the host certificate you must edit | |
562 | the OpenSSL configuration file openssl.cnf and add the following line in the | |
563 | [ usr_cert ] section: | |
564 | ||
565 | subjectAltName=DNS:moon.strongswan.org | |
566 | ||
567 | if you want to identify the host by its Fully Qualified Domain Name (FQDN ), or | |
568 | ||
569 | subjectAltName=IP:192.168.0.1 | |
570 | ||
571 | if you want the ID to be of type IPV4_ADDR. Of course you could include both | |
572 | ID types with | |
573 | ||
574 | subjectAltName=DNS:moon.strongswan.org,IP:192.168.0.1 | |
575 | ||
576 | but the use of an IP address for the identification of a host should be | |
577 | discouraged anyway. | |
578 | ||
579 | For user certificates the appropriate ID type is USER_FQDN which can be | |
580 | specified as | |
581 | ||
582 | subjectAltName=email:carol@strongswan.org | |
583 | ||
584 | or if the user's e-mail address is part of the subject's distinguished name | |
585 | ||
586 | subjectAltName=email:copy | |
587 | ||
588 | Now the certificate request can be signed by the CA with the command | |
589 | ||
590 | openssl ca -in hostReq.pem -days 730 -out hostCert.pem -notext | |
591 | ||
592 | If you omit the -days option then the default_days value (365 days) specified | |
593 | in openssl.cnf is used. The -notext option avoids that a human readable | |
594 | listing of the certificate is prepended to the base64 encoded certificate | |
595 | body. | |
596 | ||
597 | If you want to use the dynamic CRL fetching feature described in section 4.7 | |
598 | then you may include one or several crlDistributionPoints in your end | |
599 | certificates. This can be done in the [ usr_cert ] section of the openssl.cnf | |
600 | configuration file: | |
601 | ||
602 | crlDistributionPoints= @crl_dp | |
603 | ||
604 | [ crl_dp ] | |
605 | ||
606 | URI.1="http://crl.strongswan.org/strongswan.crl" | |
607 | URI.2="ldap://ldap.strongswan.org/cn=strongSwan Root CA, o=Linux strongSwan | |
608 | , c=CH?certificateRevocationList" | |
609 | ||
610 | If you have only a single http distribution point then the short form | |
611 | ||
612 | crlDistributionPoints="URI:http://crl.strongswan.org/strongswan.crl" | |
613 | ||
614 | also works. Due to a known bug in OpenSSL this notation fails with ldap URIs. | |
615 | ||
616 | Usually a Windows-based VPN client needs its private key, its host or | |
617 | user certificate, and the CA certificate. The most convenient way to load | |
618 | this information is to put everything into a PKCS#12 file: | |
619 | ||
620 | openssl pkcs12 -export -inkey carolKey.pem \ | |
621 | -in carolCert.pem -name "carol" \ | |
622 | -certfile strongswanCert.pem -caname "strongSwan Root CA" \ | |
623 | -out carolCert.p12 | |
624 | ||
625 | ||
626 | 3.3 Generating a CRL | |
627 | ---------------- | |
628 | ||
629 | An empty CRL that is signed by the CA can be generated with the command | |
630 | ||
631 | openssl ca -gencrl -crldays 15 -out crl.pem | |
632 | ||
633 | If you omit the -crldays option then the default_crl_days value (30 days) | |
634 | specified in openssl.cnf is used. | |
635 | ||
636 | If you prefer the CRL to be in binary DER format then this conversion | |
637 | can be achieved with | |
638 | ||
639 | openssl crl -in crl.pem -outform DER -out cert.crl | |
640 | ||
641 | The directory /etc/ipsec.d/crls contains all CRLs either in binary DER | |
642 | or in base64 PEM format. Irrespective of the file suffix, Pluto | |
643 | "automagically" determines the correct format. | |
644 | ||
645 | ||
646 | 3.4 Revoking a certificate | |
647 | ---------------------- | |
648 | ||
649 | A specific host certificate stored in the file host.pem is revoked with the | |
650 | command | |
651 | ||
652 | openssl ca -revoke host.pem | |
653 | ||
654 | Next the CRL file must be updated | |
655 | ||
656 | openssl ca -gencrl -crldays 60 -out crl.pem | |
657 | ||
658 | The content of the CRL file can be listed with the command | |
659 | ||
660 | openssl crl -in crl.pem -noout -text | |
661 | ||
662 | in the case of a base64 CRL, or alternatively for a CRL in DER format | |
663 | ||
664 | openssl crl -inform DER -in cert.crl -noout -text | |
665 | ||
666 | ||
667 | ||
668 | 4. Configuring the connections - ipsec.conf | |
669 | ---------------------------------------- | |
670 | ||
671 | 4.1 Configuring my side | |
672 | ------------------- | |
673 | ||
674 | Usually the local side is the same for all connections. Therefore it makes | |
675 | sense to put the definitions characterizing the strongSwan security gateway into | |
676 | the conn %default section of the configuration file /etc/ipsec.conf. If we | |
677 | assume throughout this document that the strongSwan security gateway is left and | |
678 | the peer is right then we can write | |
679 | ||
680 | conn %default | |
681 | # my side is left - the freeswan security gateway | |
682 | left=%defaultroute | |
683 | leftcert=moonCert.pem | |
684 | # load connection definitions automatically | |
685 | auto=add | |
686 | ||
687 | The X.509 certificate by which the strongSwan security gateway will authenticate | |
688 | itself by sending it in binary form to its peers as part of the Internet Key | |
689 | Exchange (IKE) is specified in the line | |
690 | ||
691 | leftcert=moonCert.pem | |
692 | ||
693 | The certificate can either be stored in base64 PEM-format or in the binary | |
694 | DER-format. Irrespective of the file suffix, Pluto "automagically" determines | |
695 | the correct format. Therefore | |
696 | ||
697 | leftcert=moonCert.der | |
698 | ||
699 | or | |
700 | ||
701 | leftcert=moonCert.cer | |
702 | ||
703 | would also be valid alternatives. | |
704 | ||
705 | When using relative pathnames as in the examples above, the certificate files | |
706 | must be stored in in the directory /etc/ipsec.d/certs. In order to distinguish | |
707 | strongSwan's own certificates from locally stored trusted peer certificates | |
708 | (see section 5.5 for details), they could also be stored in a subdirectory | |
709 | below /etc/ipsec.d/certs as e.g. in | |
710 | ||
711 | leftcert=mycerts/moonCert.pem | |
712 | ||
713 | Absolute pathnames are also possible as in | |
714 | ||
715 | leftcert=/usr/ssl/certs/moonCert.pem | |
716 | ||
717 | As an ID for the VPN gateway we recommend the use of a Fully Qualified Domain | |
718 | Name (FQDN) of the form | |
719 | ||
720 | conn rw | |
721 | right=%any | |
722 | leftid=@moon.strongswan.org | |
723 | ||
724 | Important: When an FQDN identifier is used it must be explicitly included as a | |
725 | so called subjectAltName of type dnsName (DNS:) in the certificate indicated | |
726 | by leftcert. For details on how to generate certificates with subjectAltNames, | |
727 | please refer to section 7.2. | |
728 | ||
729 | If you don't want to mess with subjectAltNames, you can use the certificate's | |
730 | Distinguished Name (DN) instead, which is an identifier of type DER_ASN1_DN | |
731 | and which can be written e.g. in the LDAP-type format | |
732 | ||
733 | conn rw | |
734 | right=%any | |
735 | leftid="C=CH, O=Linux strongSwan, CN=moon.strongswan.org" | |
736 | ||
737 | Since the subject's DN is part of the certificate, the leftid does not have to | |
738 | be declared explicitly. Thus the entry | |
739 | ||
740 | conn rw | |
741 | right=%any | |
742 | ||
743 | automatically assumes the subject DN of leftcert to be the host ID. | |
744 | ||
745 | ||
746 | 4.2 Multiple certificates | |
747 | --------------------- | |
748 | ||
749 | strongSwan supports multiple local host certificates and corresponding | |
750 | RSA private keys: | |
751 | ||
752 | conn rw1 | |
753 | right=%any | |
754 | rightid=@peer1.domain1 | |
755 | leftcert=myCert1.pem | |
756 | # leftid is DN of myCert1 | |
757 | ||
758 | conn rw2 | |
759 | right=%any | |
760 | rightid=@peer2.domain2 | |
761 | leftcert=myCert2.pem | |
762 | # leftid is DN of myCert2 | |
763 | ||
764 | When peer1 initiates a connection then strongSwan will send myCert1 and will | |
765 | sign with myKey1 defined in /etc/ipsec.secrets (see section 6.2) whereas | |
766 | myCert2 and myKey2 will be used in a connection setup started from peer2. | |
767 | ||
768 | ||
769 | 4.3 Configuring the peer side using CA certificates | |
770 | ----------------------------------------------- | |
771 | ||
772 | Now we can proceed to define our connections. In many applications we might | |
773 | have dozens of mostly Windows-based road warriors connecting to a central | |
774 | strongSwan security gateway. The following most simple statement: | |
775 | ||
776 | conn rw | |
777 | right=%any | |
778 | ||
779 | defines the general roadwarrior case. The line right=%any literally means that | |
780 | any IPSec peer is accepted, regardless of its current IP source address and its | |
781 | ID, as long as the peer presents a valid X.509 certificate signed by a CA the | |
782 | strongSwan security gateway puts explicit trust in. Additionally the signature | |
783 | during IKE main mode gives proof that the peer is in possession of the private | |
784 | RSA key matching the public key contained in the transmitted certificate. | |
785 | ||
786 | The ID by which a peer is identifying itself during IKE main mode can by any of | |
787 | the ID types IPV4_ADDR, FQDN, USER_FQDN or DER_ASN1_DN. If one of the first | |
788 | three ID types is used, then the accompanying X.509 certificate of the peer | |
789 | must contain a matching subjectAltName field of the type ipAddress (IP:), | |
790 | dnsName (DNS:) or rfc822Name (email:), respectively. With the fourth type | |
791 | DER_ASN1_DN the identifier must completely match the subject field of the | |
792 | peer's certificate. One of the two possible representations of a | |
793 | Distinguished Name (DN) is the LDAP-type format | |
794 | ||
795 | rightid="C=CH, O=Linux strongSwan, CN=sun.strongswan.org" | |
796 | ||
797 | Additional whitespace can be added everywhere as desired since it will be | |
798 | automatically eliminated by the X.509 parser. An exception is the single | |
799 | whitespace between individual words , like e.g. in Linux strongSwan, which is | |
800 | preserved by the parser. | |
801 | ||
802 | The Relative Distinguished Names (RDNs) can alternatively be separated by a | |
803 | slash '/' instead of a comma ',' | |
804 | ||
805 | rightid="/C=CH/O=Linux strongSwan/CN=sun.strongswan.org" | |
806 | ||
807 | This is the representation extracted from the certificate by the OpenSSL | |
808 | command line option | |
809 | ||
810 | openssl x509 -in sunCert.pem -noout -subject | |
811 | ||
812 | The following RDNs are supported by strongSwan | |
813 | ||
814 | +---------------------------------------------------+ | |
815 | | DC Domain Component | | |
816 | |---------------------------------------------------| | |
817 | | C Country | | |
818 | |---------------------------------------------------| | |
819 | | ST State or province | | |
820 | |---------------------------------------------------| | |
821 | | L Locality or town | | |
822 | |---------------------------------------------------| | |
823 | | O Organisation | | |
824 | |---------------------------------------------------| | |
825 | | OU Organisational Unit | | |
826 | |---------------------------------------------------| | |
827 | | CN Common Name | | |
828 | |---------------------------------------------------| | |
829 | | ND NameDistinguisher, used with CN | | |
830 | |---------------------------------------------------| | |
831 | | N Name | | |
832 | |---------------------------------------------------| | |
833 | | G Given name | | |
834 | |---------------------------------------------------| | |
835 | | S Surname | | |
836 | |---------------------------------------------------| | |
837 | | I Initials | | |
838 | |---------------------------------------------------| | |
839 | | T Personal title | | |
840 | |---------------------------------------------------| | |
841 | | E E-mail | | |
842 | |---------------------------------------------------| | |
843 | | Email E-mail | | |
844 | |---------------------------------------------------| | |
845 | | emailAddress E-mail | | |
846 | |---------------------------------------------------| | |
847 | | SN Serial number | | |
848 | |---------------------------------------------------| | |
849 | | serialNumber Serial number | | |
850 | |---------------------------------------------------| | |
851 | | D Description | | |
852 | |---------------------------------------------------| | |
853 | | ID X.500 Unique Identifier | | |
854 | |---------------------------------------------------| | |
855 | | UID User ID | | |
856 | |---------------------------------------------------| | |
857 | | TCGID [Siemens] Trust Center Global ID | | |
858 | |---------------------------------------------------| | |
859 | | unstructuredName Unstructured Name | | |
860 | |---------------------------------------------------| | |
861 | | UN Unstructured Name | | |
862 | |---------------------------------------------------| | |
863 | | employeeNumber Employee Number | | |
864 | |---------------------------------------------------| | |
865 | | EN Employee Number | | |
866 | +---------------------------------------------------+ | |
867 | ||
868 | With the roadwarrior connection definition listed above, an IPsec SA for | |
869 | the strongSwan security gateway moon.strongswan.org itself can be established. | |
870 | If any roadwarrior should be able to reach e.g. the two subnets 10.1.0.0/24 | |
871 | and 10.1.3.0/24 behind the security gateway then the following connection | |
872 | definitions will make this possible | |
873 | ||
874 | conn rw1 | |
875 | right=%any | |
876 | leftsubnet=10.1.0.0/24 | |
877 | ||
878 | conn rw3 | |
879 | right=%any | |
880 | leftsubnet=10.1.3.0/24 | |
881 | ||
882 | If not all peers in possession of a X.509 certificate signed by a specific | |
883 | certificate authority shall be given access to the Linux security gateway, | |
884 | then either a subset of them can be barred by listing the serial numbers of | |
885 | their certificates in a certificate revocation list (CRL) as specified in | |
886 | section 5.2 or as an alternative, access can be controlled by explicitly | |
887 | putting a roadwarrior entry for each eligible peer into ipsec.conf: | |
888 | ||
889 | conn sun | |
890 | right=%any | |
891 | rightid=@sun.strongswan.org | |
892 | ||
893 | conn carol | |
894 | right=%any | |
895 | rightid=carol@strongswan.org | |
896 | ||
897 | conn dave | |
898 | right=%any | |
899 | rightid="C=CH, O=Linux strongSwan, CN=dave@strongswan.org" | |
900 | ||
901 | When the IP address of a peer is known to be stable, it can be specified as | |
902 | well. This entry is mandatory when the strongSwan host wants to act as the | |
903 | initiator of an IPSec connection. | |
904 | ||
905 | conn sun | |
906 | right=192.168.0.2 | |
907 | rightid=@sun.strongswan.org | |
908 | ||
909 | conn carol | |
910 | right=192.168.0.100 | |
911 | rightid=carol@strongswan.org | |
912 | ||
913 | conn dave | |
914 | right=192.168.0.200 | |
915 | rightid="C=CH, O=Linux strongSwan, CN=dave@strongswan.org" | |
916 | ||
917 | conn venus | |
918 | right=192.168.0.50 | |
919 | ||
920 | In the last example the ID types FQDN, USER_FQDN, DER_ASN1_DN and IPV4_ADDR, | |
921 | respectively, were used. Of course all connection definitions presented so far | |
922 | have included the lines in the conn %defaults section, comprising among other | |
923 | a left and leftcert entry. | |
924 | ||
925 | ||
926 | 4.4 Handling Virtual IPs and wildcard subnets | |
927 | ----------------------------------------- | |
928 | ||
929 | Often roadwarriors are behind NAT-boxes with IPsec passthrough, which causes | |
930 | the inner IP source address of an IPsec tunnel to be different from the | |
931 | outer IP source address usually assigned dynamically by the ISP. | |
932 | Whereas the varying outer IP address can be handled by the right=%any | |
933 | construct, the inner IP address or subnet must always be declared in a | |
934 | connection definition. Therefore for the three roadwarriors rw1 to rw3 | |
935 | connecting to a strongSwan security gateway the following entries are | |
936 | required in /etc/ipsec.conf: | |
937 | ||
938 | conn rw1 | |
939 | right=%any | |
940 | righsubnet=10.4.0.5/32 | |
941 | ||
942 | conn rw2 | |
943 | right=%any | |
944 | rightsubnet=10.4.0.47/32 | |
945 | ||
946 | conn rw3 | |
947 | right=%any | |
948 | rightsubnet=10.4.0.128/28 | |
949 | ||
950 | With the wildcard parameter rightsubnetwithin these three entries can be | |
951 | reduced to the single connection definition | |
952 | ||
953 | conn rw | |
954 | right=%any | |
955 | rightsubnetwithin=10.4.0.0/24 | |
956 | ||
957 | Any host will be accepted (of course after successful authentication based on | |
958 | the peer's X.509 certificate only) if it declares a client subnet lying totally | |
959 | within the brackets defined by the wildcard subnet definition (in our example | |
960 | 10.4.0.0/24). For each roadwarrior a connection instance tailored to the | |
961 | subnet of the particular client will be created,based on the generic | |
962 | rightsubnetwithin template. | |
963 | ||
964 | This strongSwan feature can also be helpful with VPN clients getting a | |
965 | dynamically assigned inner IP from a DHCP server located on the NAT router box. | |
966 | ||
967 | ||
968 | 4.5 Protocol and Port Selectors | |
969 | --------------------------- | |
970 | ||
971 | strongSwan offer the possibility to restrict the protocol and optionally the | |
972 | ports in an IPsec SA using the rightprotoport and leftprotoport parameters. | |
973 | ||
974 | Some examples: | |
975 | ||
976 | conn icmp | |
977 | right=%any | |
978 | rightprotoport=icmp | |
979 | left=%defaultroute | |
980 | leftid=@moon.strongswan.org | |
981 | leftprotoport=icmp | |
982 | ||
983 | conn http | |
984 | right=%any | |
985 | rightprotoport=6 | |
986 | left=%defaultroute | |
987 | leftid=@moon.strongswan.org | |
988 | leftprotoport=6/80 | |
989 | ||
990 | conn l2tp # with port wildcard for Mac OS X Panther interoperability | |
991 | right=%any | |
992 | rightprotoport=17/%any | |
993 | left=%defaultroute | |
994 | leftid=@moon.strongswan.org | |
995 | leftprotoport=17/1701 | |
996 | ||
997 | conn dhcp | |
998 | right=%any | |
999 | rightprotoport=udp/bootpc | |
1000 | left=%defaultroute | |
1001 | leftid=@moon.strongswan.org | |
1002 | leftsubnet=0.0.0.0/0 #allows DHCP discovery broadcast | |
1003 | leftprotoport=udp/bootps | |
1004 | rekey=no | |
1005 | keylife=20s | |
1006 | rekeymargin=10s | |
1007 | auto=add | |
1008 | ||
1009 | Protocols and ports can be designated either by their numerical values | |
1010 | or by their acronyms defined in /etc/services. | |
1011 | ||
1012 | ipsec status | |
1013 | ||
1014 | shows the following connection definitions: | |
1015 | ||
1016 | "icmp": 192.168.0.1[@moon.strongswan.org]:1/0...%any:1/0 | |
1017 | "http": 192.168.0.1[@moon.strongswan.org]:6/80...%any:6/0 | |
1018 | "l2tp": 192.168.0.1[@moon.strongswan.org]:17/1701...%any:17/%any | |
1019 | "dhcp": 0.0.0.0/0===192.168.0.1[@moon.strongswan.org]:17/67...%any:17/68 | |
1020 | ||
1021 | Based on the protocol and port selectors appropriate eroutes will be set | |
1022 | up, so that only the specified payload types will pass through the IPsec | |
1023 | tunnel. | |
1024 | ||
1025 | ||
1026 | 4.6 IPsec policies based on wildcards | |
1027 | --------------------------------- | |
1028 | ||
1029 | In large VPN-based remote access networks there is often a requirement that | |
1030 | access to the various parts of an internal network must be granted selectively, | |
1031 | e.g. depending on the group membership of the remote access user. strongSwan | |
1032 | makes this possible by applying wildcard filtering on the VPN user's | |
1033 | distinguished name (ID_DER_ASN1_DN). | |
1034 | ||
1035 | Let's make a practical example: | |
1036 | ||
1037 | An organization has a sales department (OU=Sales) and a research group | |
1038 | (OU=Research). In the company intranet there are separate subnets for Sales | |
1039 | (10.0.0.0/24) and Research (10.0.1.0/24) but both groups share a common web | |
1040 | server (10.0.2.100). The VPN clients use Virtual IP addresses that are either | |
1041 | assigned statically or via DHCP-over-IPsec. The sales and research departments | |
1042 | use IP addresses from separate DHCP address pools (10.1.0.0/24) and (10.1.1.0/24), | |
1043 | respectively. An X.509 certificate is issued to each employee, containing in its | |
1044 | subject distinguished name the country (C=CH), the company (O=ACME), | |
1045 | the group membership(OU=Sales or OU=Research) and the common name (e.g. | |
1046 | CN=Bart Simpson). | |
1047 | ||
1048 | The IPsec policy defined above can now be enforced with the following three | |
1049 | IPsec security associations: | |
1050 | ||
1051 | conn sales | |
1052 | right=%any | |
1053 | rightid="C=CH, O=ACME, OU=Sales, CN=*" | |
1054 | rightsubnetwithin=10.1.0.0/24 # Sales DHCP range | |
1055 | leftsubnet=10.0.0.0/24 # Sales subnet | |
1056 | ||
1057 | conn research | |
1058 | right=%any | |
1059 | rightid="C=CH, O=ACME, OU=Research, CN=*" | |
1060 | rightsubnetwithin=10.1.1.0/24 # Research DHCP range | |
1061 | leftsubnet=10.0.1.0/24 # Research subnet | |
1062 | ||
1063 | conn web | |
1064 | right=%any | |
1065 | rightid="C=CH, O=ACME, OU=*, CN=*" | |
1066 | rightsubnetwithin=10.1.0.0/23 # Remote access DHCP range | |
1067 | leftsubnet=10.0.2.100/32 # Web server | |
1068 | rightprotoport=tcp # TCP protocol only | |
1069 | leftprotoport=tcp/http # TCP port 80 only | |
1070 | ||
1071 | Of course group specific tunneling could be implemented on the | |
1072 | basis of the Virtual IP range specified by the rightsubnetwithin | |
1073 | parameter alone, but the wildcard matching mechanism guarantees that | |
1074 | only authorized user can access the corresponding subnets. | |
1075 | ||
1076 | The '*' character is used as a wildcard in relative distinguished names (RDNs). | |
1077 | In order to match a wildcard template, the ID_DER_ASN1_DN of a peer must contain | |
1078 | the same number of RDNs (selected from the list in section 4.3) appearing in the | |
1079 | exact order defined by the template. | |
1080 | ||
1081 | "C=CH, O=ACME, OU=Research, OU=Special Effects, CN=Bart Simpson" | |
1082 | ||
1083 | matches the templates | |
1084 | ||
1085 | "C=CH, O=ACME, OU=Research, OU=*, CN=*" | |
1086 | ||
1087 | "C=CH, O=ACME, OU=*, OU=Special Effects, CN=*" | |
1088 | ||
1089 | "C=CH, O=ACME, OU=*, OU=*, CN=*" | |
1090 | ||
1091 | but not the template | |
1092 | ||
1093 | "C=CH, O=ACME, OU=*, CN=*" | |
1094 | ||
1095 | which doesn't have the same number of RDNs. | |
1096 | ||
1097 | ||
1098 | 4.7 IPsec policies based on CA certificates | |
1099 | --------------------------------------- | |
1100 | ||
1101 | As an alternative to the wildcard based IPsec policies described in section 4.6, | |
1102 | access to specific client host and subnets can abe controlled on the basis of | |
1103 | the CA that issued the peer certificate | |
1104 | ||
1105 | ||
1106 | conn sales | |
1107 | right=%any | |
1108 | rightca="C=CH, O=ACME, OU=Sales, CN=Sales CA" | |
1109 | rightsubnetwithin=10.1.0.0/24 # Sales DHCP range | |
1110 | leftsubnet=10.0.0.0/24 # Sales subnet | |
1111 | ||
1112 | conn research | |
1113 | right=%any | |
1114 | rightca="C=CH, O=ACME, OU=Research, CN=Research CA" | |
1115 | rightsubnetwithin=10.1.1.0/24 # Research DHCP range | |
1116 | leftsubnet=10.0.1.0/24 # Research subnet | |
1117 | ||
1118 | conn web | |
1119 | right=%any | |
1120 | rightca="C=CH, O=ACME, CN=ACME Root CA" | |
1121 | rightsubnetwithin=10.1.0.0/23 # Remote access DHCP range | |
1122 | leftsubnet=10.0.2.100/32 # Web server | |
1123 | rightprotoport=tcp # TCP protocol only | |
1124 | leftprotoport=tcp/http # TCP port 80 only | |
1125 | ||
1126 | In the example above, the connection "sales" can be used by peers | |
1127 | presenting certificates issued by the Sales CA, only. In the same way, | |
1128 | the use of the connection "research" is restricted to owners of certificates | |
1129 | issued by the Research CA. The connection "web" is open to both "Sales" and | |
1130 | "Research" peers because the required "ACME Root CA" is the issuer of the | |
1131 | Research and Sales intermediate CAs. If no rightca parameter is present | |
1132 | then any valid certificate issued by one of the trusted CAs in | |
1133 | /etc/ipsec.d/cacerts can be used by the peer. | |
1134 | ||
1135 | The leftca parameter usually doesn't have to be set explicitly because | |
1136 | by default it is set to the issuer field of the certificate loaded via | |
1137 | leftcert. The statement | |
1138 | ||
1139 | rightca=%same | |
1140 | ||
1141 | sets the CA requested from the peer to the CA used by the left side itself | |
1142 | as e.g. in | |
1143 | ||
1144 | conn sales | |
1145 | right=%any | |
1146 | rightca=%same | |
1147 | leftcert=mySalesCert.pem | |
1148 | ||
1149 | ||
1150 | 4.8 Sending certificate requests | |
1151 | ---------------------------- | |
1152 | ||
1153 | The presence of a rightca parameter also causes the CA to be sent as | |
1154 | part of the certificate request message when strongSwan is the initiator. | |
1155 | A special case occurs when strongSwan responds to a roadwarrior. If several | |
1156 | roadwarrior connections based on different CAs are defined then all eligible | |
1157 |