This repository has been archived by the owner on Apr 15, 2023. It is now read-only.
forked from strongswan/strongswan
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
1514 lines (1058 loc) · 52.3 KB
/
README
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
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
----------------------------
strongSwan - Configuration
----------------------------
Contents
--------
1. Overview
2. Quickstart
2.1 Site-to-Site case
2.2 Host-to-Host case
2.3 Roadwarrior case
2.4 Roadwarrior case with virtual IP
3. Generating X.509 certificates and CRLs
3.1 Generating a CA certificate
3.2 Generating a host or user certificate
3.3 Generating a CRL
3.4 Revoking a certificate
4. Configuring the connections - ipsec.conf
4.1 Configuring my side
4.2 Multiple certificates
4.3 Configuring the peer side using CA certificates
4.4 Handling Virtual IPs and wildcard subnets
4.5 Protocol and port selectors
4.6 IPsec policies based on wildcards
4.7 IPsec policies based on CA certificates
5. Configuring certificates and CRLs
5.1 Installing CA certificates
5.2 Installing optional Certificate Revocation Lists (CRLs)
5.3 Dynamic update of certificates and CRLs
5.4 Local caching of CRLs
5.5 Online Certificate Status Protocol (OCSP)
5.6 CRL policy
5.7 Configuring the peer side using locally stored certificates
6. Configuring the private keys - ipsec.secrets
6.1 Loading private key files in PKCS#1 format
6.2 Entering passphrases interactively
6.3 Multiple private keys
7. Configuring CA properties - ipsec.conf
8. Monitoring functions
9. Firewall support functions
9.1 Environment variables in the updown script
9.2 Automatic insertion and deletion of iptables firewall rules
1. Overview
--------
strongSwan is an OpenSource IPsec solution for Unix based operating systems.
This document is just a short introduction, for more detailed information
consult the manual pages and our wiki:
http://wiki.strongswan.org
2. Quickstart
----------
In the following examples we assume for reasons of clarity that left designates
the local host and that right is the remote host. Certificates for users,
hosts and gateways are issued by a fictitious strongSwan CA. How to generate
private keys and certificates using OpenSSL or the strongSwan PKI tool will be
explained in section 3. The CA certificate "strongswanCert.pem" must be present
on all VPN end points in order to be able to authenticate the peers.
2.1 Site-to-site case
-----------------
In this scenario two security gateways moon and sun will connect the
two subnets moon-net and sun-net with each other through a VPN tunnel
set up between the two gateways:
10.1.0.0/16 -- | 192.168.0.1 | === | 192.168.0.2 | -- 10.2.0.0/16
moon-net moon sun sun-net
Configuration on gateway moon:
/etc/ipsec.d/cacerts/strongswanCert.pem
/etc/ipsec.d/certs/moonCert.pem
/etc/ipsec.secrets:
: RSA moonKey.pem "<optional passphrase>"
/etc/ipsec.conf:
conn net-net
leftsubnet=10.1.0.0/16
leftcert=moonCert.pem
right=192.168.0.2
rightsubnet=10.2.0.0/16
rightid="C=CH, O=strongSwan, CN=sun.strongswan.org"
auto=start
Configuration on gateway sun:
/etc/ipsec.d/cacerts/strongswanCert.pem
/etc/ipsec.d/certs/sunCert.pem
/etc/ipsec.secrets:
: RSA sunKey.pem "<optional passphrase>"
/etc/ipsec.conf:
conn net-net
leftsubnet=10.2.0.0/16
leftcert=sunCert.pem
right=192.168.0.1
rightsubnet=10.1.0.0/16
rightid="C=CH, O=strongSwan, CN=moon.strongswan.org"
auto=start
2.2 Host-to-host case
-----------------
This is a setup between two single hosts which don't have a subnet behind
them. Although IPsec transport mode would be sufficient for host-to-host
connections we will use the default IPsec tunnel mode.
| 192.168.0.1 | === | 192.168.0.2 |
moon sun
Configuration on host moon:
/etc/ipsec.d/cacerts/strongswanCert.pem
/etc/ipsec.d/certs/moonCert.pem
/etc/ipsec.secrets:
: RSA moonKey.pem "<optional passphrase>"
/etc/ipsec.conf:
conn host-host
leftcert=moonCert.pem
right=192.168.0.2
rightid="C=CH, O=strongSwan, CN=sun.strongswan.org"
auto=start
Configuration on host sun:
/etc/ipsec.d/cacerts/strongswanCert.pem
/etc/ipsec.d/certs/sunCert.pem
/etc/ipsec.secrets:
: RSA sunKey.pem "<optional passphrase>"
/etc/ipsec.conf:
conn host-host
leftcert=sunCert.pem
right=192.168.0.1
rightid="C=CH, O=strongSwan, CN=moon.strongswan.org"
auto=start
2.3 Roadwarrior case
----------------
This is a very common case where a strongSwan gateway serves an arbitrary
number of remote VPN clients usually having dynamic IP addresses.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x |
moon-net moon carol
Configuration on gateway moon:
/etc/ipsec.d/cacerts/strongswanCert.pem
/etc/ipsec.d/certs/moonCert.pem
/etc/ipsec.secrets:
: RSA moonKey.pem "<optional passphrase>"
/etc/ipsec.conf:
conn rw
leftsubnet=10.1.0.0/16
leftcert=moonCert.pem
right=%any
auto=add
Configuration on roadwarrior carol:
/etc/ipsec.d/cacerts/strongswanCert.pem
/etc/ipsec.d/certs/carolCert.pem
/etc/ipsec.secrets:
: RSA carolKey.pem "<optional passphrase>"
/etc/ipsec.conf:
conn home
leftcert=carolCert.pem
right=192.168.0.1
rightsubnet=10.1.0.0/16
rightid="C=CH, O=strongSwan, CN=moon.strongswan.org"
auto=start
2.6 Roadwarrior case with virtual IP
--------------------------------
Roadwarriors usually have dynamic IP addresses assigned by the ISP they are
currently attached to. In order to simplify the routing from moon-net back
to the remote access client carol it would be desirable if the roadwarrior had
an inner IP address chosen from a pre-assigned pool.
10.1.0.0/16 -- | 192.168.0.1 | === | x.x.x.x | -- 10.3.0.1
moon-net moon carol virtual IP
In our example the virtual IP address is chosen from the address pool
10.3.0.0/16 which can be configured by adding the parameter
rightsourceip=10.3.0.0/16
to the gateway's ipsec.conf. To request an IP address from this pool a
roadwarrior can use IKEv1 mode config or IKEv2 configuration payloads.
The configuration for both is the same
leftsourceip=%config
Configuration on gateway moon:
/etc/ipsec.d/cacerts/strongswanCert.pem
/etc/ipsec.d/certs/moonCert.pem
/etc/ipsec.secrets:
: RSA moonKey.pem "<optional passphrase>"
/etc/ipsec.conf:
conn rw
leftsubnet=10.1.0.0/16
leftcert=moonCert.pem
right=%any
rightsourceip=10.3.0.0/16
auto=add
Configuration on roadwarrior carol:
/etc/ipsec.d/cacerts/strongswanCert.pem
/etc/ipsec.d/certs/carolCert.pem
/etc/ipsec.secrets:
: RSA carolKey.pem "<optional passphrase>"
/etc/ipsec.conf:
conn home
leftsourceip=%config
leftcert=carolCert.pem
right=192.168.0.1
rightsubnet=10.1.0.0/16
rightid="C=CH, O=strongSwan, CN=moon.strongswan.org"
auto=start
3. Generating certificates and CRLs
--------------------------------
This section is not a full-blown tutorial on how to use OpenSSL or the
strongSwan PKI tool. It just lists a few points that are relevant if you want
to generate your own certificates and CRLs for use with strongSwan.
3.1 Generating a CA certificate
---------------------------
The OpenSSL statement
openssl req -x509 -days 1460 -newkey rsa:4096 \
-keyout strongswanKey.pem -out strongswanCert.pem
creates a 4096 bit RSA private key strongswanKey.pem and a self-signed CA
certificate strongswanCert.pem with a validity of 4 years (1460 days).
openssl x509 -in cert.pem -noout -text
lists the properties of a X.509 certificate cert.pem. It allows you to verify
whether the configuration defaults in openssl.cnf have been inserted correctly.
If you prefer the CA certificate to be in binary DER format then the following
command achieves this transformation:
openssl x509 -in strongswanCert.pem -outform DER -out strongswanCert.der
The statements
ipsec pki --gen -s 4096 > strongswanKey.der
ipsec pki --self --ca --lifetime 1460 --in strongswanKey.der \
--dn "C=CH, O=strongSwan, CN=strongSwan Root CA" \
> strongswanCert.der
ipsec pki --print --in strongswanCert.der
achieve about the same with the strongSwan PKI tool. Unlike OpenSSL the tool
stores keys and certificates in the binary DER format by default. The --outform
option may be used to write PEM encoded files.
The directory /etc/ipsec.d/cacerts contains all required CA certificates either
in binary DER or in base64 PEM format, irrespective of the file suffix the
correct format will be determined.
3.2 Generating a host or user certificate
-------------------------------------
The OpenSSL statement
openssl req -newkey rsa:2048 -keyout hostKey.pem \
-out hostReq.pem
generates a 2048 bit RSA private key hostKey.pem and a certificate request
hostReq.pem which has to be signed by the CA.
If you want to add a subjectAltName field to the host certificate you must edit
the OpenSSL configuration file openssl.cnf and add the following line in the
[ usr_cert ] section:
subjectAltName=DNS:moon.strongswan.org
if you want to identify the host by its Fully Qualified Domain Name (FQDN), or
subjectAltName=IP:192.168.0.1
if you want the ID to be of type IPV4_ADDR. Of course you could include both
ID types with
subjectAltName=DNS:moon.strongswan.org,IP:192.168.0.1
but the use of an IP address for the identification of a host should be
discouraged anyway.
For user certificates the appropriate ID type is RFC822_ADDR which can be
specified as
subjectAltName=email:[email protected]
or if the user's e-mail address is part of the subject's distinguished name
subjectAltName=email:copy
Now the certificate request can be signed by the CA with the command
openssl ca -in hostReq.pem -days 730 -out hostCert.pem -notext
If you omit the -days option then the default_days value (365 days) specified
in openssl.cnf is used. The -notext option avoids that a human readable
listing of the certificate is prepended to the base64 encoded certificate
body.
If you want to use the dynamic CRL fetching feature described in section 4.7
then you may include one or several crlDistributionPoints in your end
certificates. This can be done in the [ usr_cert ] section of the openssl.cnf
configuration file:
crlDistributionPoints=@crl_dp
[ crl_dp ]
URI.1="http://crl.strongswan.org/strongswan.crl"
URI.2="ldap://ldap.strongswan.org/cn=strongSwan Root CA, o=strongSwan,
c=CH?certificateRevocationList"
If you have only a single HTTP distribution point then the short form
crlDistributionPoints="URI:http://crl.strongswan.org/strongswan.crl"
also works.
Again the statements
ipsec pki --gen > moonKey.der
ipsec pki --pub --in moonKey.der | ipsec pki --issue --lifetime 730 \
--cacert strongswanCert.der --cakey strongswanKey.der \
--dn "C=CH, O=strongSwan, CN=moon.strongswan.org" \
--san moon.strongswan.org --san 192.168.0.1 \
--crl http://crl.strongswan.org/strongswan.crl > moonCert.der
do something thing similar using the strongSwan PKI tool.
Usually, a Windows or Mac OS X (or iOS) based VPN client needs its private key,
its host or user certificate, and the CA certificate. The most convenient way
to load this information is to put everything into a PKCS#12 file:
openssl pkcs12 -export -inkey carolKey.pem \
-in carolCert.pem -name "carol" \
-certfile strongswanCert.pem -caname "strongSwan Root CA" \
-out carolCert.p12
3.3 Generating a CRL
----------------
An empty CRL that is signed by the CA can be generated with the command
openssl ca -gencrl -crldays 15 -out crl.pem
If you omit the -crldays option then the default_crl_days value (30 days)
specified in openssl.cnf is used.
If you prefer the CRL to be in binary DER format then this conversion
can be achieved with
openssl crl -in crl.pem -outform DER -out cert.crl
The strongSwan PKI tool provides the ipsec pki --signcrl command to sign CRLs.
The directory /etc/ipsec.d/crls contains all CRLs either in binary DER
or in base64 PEM format, irrespective of the file suffix the correct format
will be determined.
3.4 Revoking a certificate
----------------------
A specific host certificate stored in the file host.pem is revoked with the
command
openssl ca -revoke host.pem
Next the CRL file must be updated
openssl ca -gencrl -crldays 60 -out crl.pem
The content of the CRL file can be listed with the command
openssl crl -in crl.pem -noout -text
in the case of a base64 CRL, or alternatively for a CRL in DER format
openssl crl -inform DER -in cert.crl -noout -text
Again the ipsec pki --signcrl command may be used to create new CRLs containing
additional certificates.
4. Configuring the connections - ipsec.conf
----------------------------------------
4.1 Configuring my side
-------------------
Usually the local side is the same for all connections. Therefore it makes
sense to put the definitions characterizing the strongSwan security gateway into
the conn %default section of the configuration file /etc/ipsec.conf. If we
assume throughout this document that the strongSwan security gateway is left and
the peer is right then we can write
conn %default
leftcert=moonCert.pem
# load connection definitions automatically
auto=add
The X.509 certificate by which the strongSwan security gateway will authenticate
itself by sending it in binary form to its peers as part of the Internet Key
Exchange (IKE) is specified in the line
leftcert=moonCert.pem
The certificate can either be stored in base64 PEM-format or in the binary
DER-format. Irrespective of the file suffix the correct format will be
determined. Therefore
leftcert=moonCert.der
or
leftcert=moonCert.cer
would also be valid alternatives.
When using relative pathnames as in the examples above, the certificate files
must be stored in in the directory /etc/ipsec.d/certs. In order to distinguish
strongSwan's own certificates from locally stored trusted peer certificates
(see section 5.5 for details), they could also be stored in a subdirectory
below /etc/ipsec.d/certs as e.g. in
leftcert=mycerts/moonCert.pem
Absolute pathnames are also possible as in
leftcert=/usr/ssl/certs/moonCert.pem
As an ID for the VPN gateway we recommend the use of a Fully Qualified Domain
Name (FQDN) of the form
conn rw
right=%any
Important: When a FQDN identifier is used it must be explicitly included as a
so called subjectAltName of type dnsName (DNS:) in the certificate indicated
by leftcert. For details on how to generate certificates with subjectAltNames,
please refer to section 3.2.
If you don't want to mess with subjectAltNames, you can use the certificate's
Distinguished Name (DN) instead, which is an identifier of type DER_ASN1_DN
and which can be written e.g. in the LDAP-type format
conn rw
right=%any
leftid="C=CH, O=strongSwan, CN=moon.strongswan.org"
Since the subject's DN is part of the certificate, the leftid does not have to
be declared explicitly. Thus the entry
conn rw
right=%any
automatically assumes the subject DN of leftcert to be the host ID.
4.2 Multiple certificates
---------------------
strongSwan supports multiple local host certificates and corresponding
RSA private keys:
conn rw1
right=%any
leftcert=myCert1.pem
# leftid is DN of myCert1
conn rw2
right=%any
leftcert=myCert2.pem
# leftid is DN of myCert2
When peer1 initiates a connection then strongSwan will send myCert1 and will
sign with myKey1 defined in /etc/ipsec.secrets (see section 6.2) whereas
myCert2 and myKey2 will be used in a connection setup started from peer2.
4.3 Configuring the peer side using CA certificates
-----------------------------------------------
Now we can proceed to define our connections. In many applications we might
have dozens of road warriors connecting to a central strongSwan security
gateway. The following most simple statement:
conn rw
right=%any
defines the general roadwarrior case. The line right=%any literally means that
any IPsec peer is accepted, regardless of its current IP source address and its
ID, as long as the peer presents a valid X.509 certificate signed by a CA the
strongSwan security gateway puts explicit trust in. Additionally, the signature
during IKE gives proof that the peer is in possession of the private RSA key
matching the public key contained in the transmitted certificate.
The ID by which a peer is identifying itself during IKE can by any of the ID
types IPV[46]_ADDR, FQDN, RFC822_ADDR or DER_ASN1_DN. If one of the first
three ID types is used, then the accompanying X.509 certificate of the peer
must contain a matching subjectAltName field of the type ipAddress (IP:),
dnsName (DNS:) or rfc822Name (email:), respectively. With the fourth type
DER_ASN1_DN the identifier must completely match the subject field of the
peer's certificate. One of the two possible representations of a
Distinguished Name (DN) is the LDAP-type format
rightid="C=CH, O=strongSwan IPsec, CN=sun.strongswan.org"
Additional whitespace can be added everywhere as desired since it will be
automatically eliminated by the X.509 parser. An exception is the single
whitespace between individual words, like e.g. in strongSwan IPsec, which is
preserved by the parser.
The Relative Distinguished Names (RDNs) can alternatively be separated by a
slash '/' instead of a comma ','
rightid="/C=CH/O=strongSwan IPsec/CN=sun.strongswan.org"
This is the representation extracted from the certificate by the OpenSSL
command line option
openssl x509 -in sunCert.pem -noout -subject
The following RDNs are supported by strongSwan
+-------------------------------------------------------+
| DC Domain Component |
|-------------------------------------------------------|
| C Country |
|-------------------------------------------------------|
| ST State or province |
|-------------------------------------------------------|
| L Locality or town |
|-------------------------------------------------------|
| O Organization |
|-------------------------------------------------------|
| OU Organizational Unit |
|-------------------------------------------------------|
| CN Common Name |
|-------------------------------------------------------|
| ND NameDistinguisher, used with CN |
|-------------------------------------------------------|
| N Name |
|-------------------------------------------------------|
| G Given name |
|-------------------------------------------------------|
| S Surname |
|-------------------------------------------------------|
| I Initials |
|-------------------------------------------------------|
| T Personal title |
|-------------------------------------------------------|
| E E-mail |
|-------------------------------------------------------|
| Email E-mail |
|-------------------------------------------------------|
| emailAddress E-mail |
|-------------------------------------------------------|
| SN Serial number |
|-------------------------------------------------------|
| serialNumber Serial number |
|-------------------------------------------------------|
| D Description |
|-------------------------------------------------------|
| ID X.500 Unique Identifier |
|-------------------------------------------------------|
| UID User ID |
|-------------------------------------------------------|
| TCGID [Siemens] Trust Center Global ID |
|-------------------------------------------------------|
| UN Unstructured Name |
|-------------------------------------------------------|
| unstructuredName Unstructured Name |
|-------------------------------------------------------|
| UA Unstructured Address |
|-------------------------------------------------------|
| unstructuredAddress Unstructured Address |
|-------------------------------------------------------|
| EN Employee Number |
|-------------------------------------------------------|
| employeeNumber Employee Number |
|-------------------------------------------------------|
| dnQualifier DN Qualifier |
+-------------------------------------------------------+
With the roadwarrior connection definition listed above, an IPsec SA for
the strongSwan security gateway moon.strongswan.org itself can be established.
If any roadwarrior should be able to reach e.g. the two subnets 10.1.0.0/24
and 10.1.3.0/24 behind the security gateway then the following connection
definitions will make this possible
conn rw1
right=%any
leftsubnet=10.1.0.0/24
conn rw3
right=%any
leftsubnet=10.1.3.0/24
For IKEv2 connections this can even be simplified by using
leftsubnet=10.1.0.0/24,10.1.3.0/24
If not all peers in possession of a X.509 certificate signed by a specific
certificate authority shall be given access to the Linux security gateway,
then either a subset of them can be barred by listing the serial numbers of
their certificates in a certificate revocation list (CRL) as specified in
section 5.2 or as an alternative, access can be controlled by explicitly
putting a roadwarrior entry for each eligible peer into ipsec.conf:
conn sun
right=%any
conn carol
right=%any
conn dave
right=%any
rightid="C=CH, O=strongSwan, [email protected]"
When the IP address of a peer is known to be stable, it can be specified as
well. This entry is mandatory when the strongSwan host wants to act as the
initiator of an IPsec connection.
conn sun
right=192.168.0.2
conn carol
right=192.168.0.100
conn dave
right=192.168.0.200
rightid="C=CH, O=strongSwan, [email protected]"
conn venus
right=192.168.0.50
In the last example the ID types FQDN, RFC822_ADDR, DER_ASN1_DN and IPV4_ADDR,
respectively, were used. Of course all connection definitions presented so far
have included the lines in the conn %defaults section, comprising among other
a leftcert entry.
4.4 Handling Virtual IPs and narrowing
----------------------------------
Often roadwarriors are behind NAT-boxes with IPsec passthrough, which causes
the inner IP source address of an IPsec tunnel to be different from the
outer IP source address usually assigned dynamically by the ISP.
Whereas the varying outer IP address can be handled by the right=%any
construct, the inner IP address or subnet must always be declared in a
connection definition. Therefore for the three roadwarriors rw1 to rw3
connecting to a strongSwan security gateway the following entries are
required in /etc/ipsec.conf:
conn rw1
right=%any
righsubnet=10.4.0.5/32
conn rw2
right=%any
rightsubnet=10.4.0.47/32
conn rw3
right=%any
rightsubnet=10.4.0.128/28
Because the charon daemon uses narrowing (even for IKEv1) these three entries
can be reduced to the single connection definition
conn rw
right=%any
rightsubnet=10.4.0.0/24
Any host will be accepted (of course after successful authentication based on
the peer's X.509 certificate only) if it declares a client subnet lying totally
within the brackets defined by the subnet definition (in our example
10.4.0.0/24).
This strongSwan feature can also be helpful with VPN clients getting a
dynamically assigned inner IP from a DHCP server located on the NAT router box.
4.5 Protocol and Port Selectors
---------------------------
strongSwan offer the possibility to restrict the protocol and optionally the
ports in an IPsec SA using the rightprotoport and leftprotoport parameters.
Some examples:
conn icmp
right=%any
rightprotoport=icmp
leftprotoport=icmp
conn http
right=%any
rightprotoport=6
leftprotoport=6/80
conn l2tp # with port wildcard for Mac OS X Panther interoperability
right=%any
rightprotoport=17/%any
leftprotoport=17/1701
conn dhcp
right=%any
rightprotoport=udp/bootpc
leftsubnet=0.0.0.0/0 #allows DHCP discovery broadcast
leftprotoport=udp/bootps
rekey=no
keylife=20s
rekeymargin=10s
auto=add
Protocols and ports can be designated either by their numerical values
or by their acronyms defined in /etc/services.
ipsec status
shows the following connection definitions:
"icmp": 192.168.0.1[@moon.strongswan.org]:1/0...%any:1/0
"http": 192.168.0.1[@moon.strongswan.org]:6/80...%any:6/0
"l2tp": 192.168.0.1[@moon.strongswan.org]:17/1701...%any:17/%any
"dhcp": 0.0.0.0/0===192.168.0.1[@moon.strongswan.org]:17/67...%any:17/68
Based on the protocol and port selectors appropriate policies will be set
up, so that only the specified payload types will pass through the IPsec
tunnel.
4.6 IPsec policies based on wildcards
---------------------------------
In large VPN-based remote access networks there is often a requirement that
access to the various parts of an internal network must be granted selectively,
e.g. depending on the group membership of the remote access user. strongSwan
makes this possible by applying wildcard filtering on the VPN user's
distinguished name (ID_DER_ASN1_DN).
Let's make a practical example:
An organization has a sales department (OU=Sales) and a research group
(OU=Research). In the company intranet there are separate subnets for Sales
(10.0.0.0/24) and Research (10.0.1.0/24) but both groups share a common web
server (10.0.2.100). The VPN clients use Virtual IP addresses that are either
assigned statically or from a dynamic pool. The sales and research departments
use IP addresses from separate address pools (10.1.0.0/24) and (10.1.1.0/24),
respectively. An X.509 certificate is issued to each employee, containing in
its subject distinguished name the country (C=CH), the company (O=ACME),
the group membership(OU=Sales or OU=Research) and the common name (e.g.
CN=Bart Simpson).
The IPsec policy defined above can now be enforced with the following three
IPsec security associations:
conn sales
right=%any
rightid="C=CH, O=ACME, OU=Sales, CN=*"
rightsubnet=10.1.0.0/24 # Sales IP range
leftsubnet=10.0.0.0/24 # Sales subnet
conn research
right=%any
rightid="C=CH, O=ACME, OU=Research, CN=*"
rightsubnet=10.1.1.0/24 # Research IP range
leftsubnet=10.0.1.0/24 # Research subnet
conn web
right=%any
rightid="C=CH, O=ACME, OU=*, CN=*"
rightsubnet=10.1.0.0/23 # Remote access IP range
leftsubnet=10.0.2.100/32 # Web server
rightprotoport=tcp # TCP protocol only
leftprotoport=tcp/http # TCP port 80 only
The '*' character is used as a wildcard in relative distinguished names (RDNs).
In order to match a wildcard template, the ID_DER_ASN1_DN of a peer must contain
the same number of RDNs (selected from the list in section 4.3) appearing in the
exact order defined by the template.
"C=CH, O=ACME, OU=Research, OU=Special Effects, CN=Bart Simpson"
matches the templates
"C=CH, O=ACME, OU=Research, OU=*, CN=*"
"C=CH, O=ACME, OU=*, OU=Special Effects, CN=*"
"C=CH, O=ACME, OU=*, OU=*, CN=*"
but not the template
"C=CH, O=ACME, OU=*, CN=*"
which doesn't have the same number of RDNs.
4.7 IPsec policies based on CA certificates
---------------------------------------
As an alternative to the wildcard based IPsec policies described in section 4.6,
access to specific client host and subnets can be controlled on the basis of
the CA that issued the peer certificate
conn sales
right=%any
rightca="C=CH, O=ACME, OU=Sales, CN=Sales CA"
rightsubnet=10.1.0.0/24 # Sales IP range
leftsubnet=10.0.0.0/24 # Sales subnet
conn research
right=%any
rightca="C=CH, O=ACME, OU=Research, CN=Research CA"
rightsubnet=10.1.1.0/24 # Research IP range
leftsubnet=10.0.1.0/24 # Research subnet
conn web
right=%any
rightca="C=CH, O=ACME, CN=ACME Root CA"
rightsubnet=10.1.0.0/23 # Remote access IP range
leftsubnet=10.0.2.100/32 # Web server
rightprotoport=tcp # TCP protocol only
leftprotoport=tcp/http # TCP port 80 only
In the example above, the connection "sales" can be used by peers
presenting certificates issued by the Sales CA, only. In the same way,
the use of the connection "research" is restricted to owners of certificates
issued by the Research CA. The connection "web" is open to both "Sales" and
"Research" peers because the required "ACME Root CA" is the issuer of the
Research and Sales intermediate CAs. If no rightca parameter is present
then any valid certificate issued by one of the trusted CAs in
/etc/ipsec.d/cacerts can be used by the peer.
The leftca parameter usually doesn't have to be set explicitly because
by default it is set to the issuer field of the certificate loaded via
leftcert. The statement
rightca=%same
sets the CA requested from the peer to the CA used by the left side itself
as e.g. in
conn sales
right=%any
rightca=%same
leftcert=mySalesCert.pem
5. Configuring certificates and CRLs
---------------------------------
5.1 Installing the CA certificates
------------------------------
X.509 certificates received by strongSwan during the IKE protocol are
automatically authenticated by going up the trust chain until a self-signed
root CA certificate is reached. Usually host certificates are directly signed
by a root CA, but strongSwan also supports multi-level hierarchies with
intermediate CAs in between. All CA certificates belonging to a trust chain
must be copied in either binary DER or base64 PEM format into the directory
/etc/ipsec.d/cacerts/
5.2 Installing optional certificate revocation lists (CRLs)
-------------------------------------------------------
By copying a CA certificate into /etc/ipsec.d/cacerts/, automatically all user
or host certificates issued by this CA are declared valid. Unfortunately,
private keys might get compromised inadvertently or intentionally, personal
certificates of users leaving a company have to be blocked immediately, etc.
To this purpose certificate revocation lists (CRLs) have been created. CRLs
contain the serial numbers of all user or host certificates that have been
revoked due to various reasons.
After successful verification of the X.509 trust chain, strongSwan searches its
list of CRLs either obtained by loading them from the /etc/ipsec.d/crls/
directory or fetching them dynamically from a HTTP or LDAP server for the
presence of a CRL issued by the CA that has signed the certificate.
If the serial number of the certificate is found in the CRL then the public key
contained in the certificate is declared invalid and the IPsec SA will not be
established. If no CRL is found or if the deadline defined in the nextUpdate
field of the CRL has been reached, a warning is issued but the public key will
nevertheless be accepted. CRLs must be stored either in binary DER or base64
PEM format in the crls directory.
5.3 Dynamic update of certificates and CRLs
---------------------------------------
strongSwan reads certificates and CRLs from their respective files during system
startup and keeps them in memory. X.509 certificates have a finite life span
defined by their validity field. Therefore it must be possible to replace CA or
OCSP certificates kept in system memory without disturbing established IKE SAs.
Certificate revocation lists should also be updated in the regular intervals
indicated by the nextUpdate field in the CRL body. The following interactive
commands allow the manual replacement of the various files:
+---------------------------------------------------------------------------+
| ipsec rereadsecrets reload file /etc/ipsec.secrets |
|---------------------------------------------------------------------------|
| ipsec rereadcacerts reload all files in /etc/ipsec.d/cacerts/ |
|---------------------------------------------------------------------------|
| ipsec rereadaacerts reload all files in /etc/ipsec.d/aacerts/ |
|---------------------------------------------------------------------------|
| ipsec rereadocspcerts reload all files in /etc/ipsec.d/ocspcerts/ |
|---------------------------------------------------------------------------|
| ipsec rereadacerts reload all files in /etc/ipsec.d/acerts/ |
|---------------------------------------------------------------------------|
| ipsec rereadcrls reload all files in /etc/ipsec.d/crls/ |
|---------------------------------------------------------------------------|
| ipsec rereadall ipsec rereadsecrets |
| rereadcacerts |