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
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html">
<title>Configuring FreeS/WAN with policy groups</title>
<meta name="keywords"
content="Linux, IPsec, VPN, security, encryption, cryptography, FreeS/WAN, FreeSWAN">
<!--
Written by Claudia Schmeing for the Linux FreeS/WAN project
Freely distributable under the GNU General Public License
More information at www.freeswan.org
Feedback to users@lists.freeswan.org
CVS information:
RCS ID: $Id: policygroups.html,v 1.1 2004/03/15 20:35:24 as Exp $
Last changed: $Date: 2004/03/15 20:35:24 $
Revision number: $Revision: 1.1 $
CVS revision numbers do not correspond to FreeS/WAN release numbers.
-->
</head>
<body>
<h1>How to Configure Linux FreeS/WAN with Policy Groups</h1>
<A NAME="policygroups"></A>
<H2>What are Policy Groups?</H2>
<P><STRONG>Policy Groups</STRONG> are an elegant general mechanism
to configure FreeS/WAN. They are useful for
many FreeS/WAN users.</P>
<P>In previous FreeS/WAN versions, you needed to configure each IPsec
connection explicitly, on both local and remote hosts.
This could become complex.</P>
<P>By contrast, Policy Groups allow you to set local IPsec policy
for lists of remote hosts and networks,
simply by listing the hosts and networks which you wish to
have special treatment in one of several Policy Group files.
FreeS/WAN then internally creates the connections
needed to implement each policy.</P>
<P>In the next section we describe our five Base Policy Groups, which
you can use to configure IPsec in many useful ways. Later, we will
show you how to create an IPsec VPN using one line of configuration for
each remote host or network.</P>
<A NAME="builtin_policygroups"></A><H3>Built-In Security Options</H3>
<P>FreeS/WAN offers these Base Policy Groups:</P>
<DL>
<DT>private</DT>
<DD>
FreeS/WAN only communicates privately with the listed
<A HREF="glossary.html#CIDR">CIDR</A> blocks.
If needed, FreeS/WAN attempts to create a connection opportunistically.
If this fails, FreeS/WAN blocks communication.
Inbound blocking is assumed to be done by the firewall. FreeS/WAN offers
firewall hooks but no modern firewall rules to help with inbound blocking.
</DD>
<DT>private-or-clear</DT>
<DD>
FreeS/WAN prefers private communication with the listed CIDR blocks.
If needed, FreeS/WAN attempts to create a connection opportunistically.
If this fails, FreeS/WAN allows traffic in the clear.
</DD>
<DT>clear-or-private</DT>
<DD>
FreeS/WAN communicates cleartext with the listed CIDR blocks, but
also accepts inbound OE connection requests from them.
Also known as <A HREF="glossary.html#passive.OE">passive OE (pOE)</A>,
this policy may be used to create an
<A HREF="glossary.html#responder">opportunistic responder</A>.
</DD>
<DT>clear</DT>
<DD>
FreeS/WAN only communicates cleartext with the listed CIDR blocks.
</DD>
<DT>block</DT>
<DD>FreeS/WAN blocks traffic to and from and the listed CIDR blocks.
Inbound blocking is assumed to be done by the firewall. FreeS/WAN offers
firewall hooks but no modern firewall rules to help with inbound blocking.
<!-- also called "blockdrop".-->
</DD>
</DL>
<A NAME="policy.group.notes"></A><P>Notes:</P>
<UL>
<LI>Base Policy Groups apply to communication with this host only.</LI>
<LI>The most specific rule (whether policy or pre-configured connection)
applies.
This has several practical applications:
<UL>
<LI>If CIDR blocks overlap, FreeS/WAN chooses
the most specific applicable block.</LI>
<LI>This decision also takes into account any pre-configured connections
you may have.</LI>
<LI>If the most specific connection is a pre-configured connection,
the following procedure applies. If that connection is up, it will be
used. If it is routed, it will be brought up. If it is added,
no action will be taken.</LI>
</UL>
<LI>Base Policy Groups are created using built-in connections.
Details in
<A HREF="manpage.d/ipsec.conf.5.html">man ipsec.conf</A>.</LI>
<LI>All Policy Groups are bidirectional.
<A HREF="src/policy-groups-table.html">This chart</A> shows some technical
details.
FreeS/WAN does not support one-way encryption, since it can give users
a false sense of security.</LI>
</UL>
<H2>Using Policy Groups</H2>
<P>The Base Policy Groups which build IPsec connections rely on Opportunistic
Encryption. To use the following examples, you
must first become OE-capable, as described
in our <A HREF="quickstart.html#quickstart">quickstart guide</A>.
<A NAME="example1"></A><H3>Example 1: Using a Base Policy Group</H3>
<P>Simply place CIDR blocks (<A HREF="#dnswarning">names</A>,
IPs or IP ranges) in /etc/ipsec.d/policies/<VAR>[groupname]</VAR>,
and reread the policy group files.</P>
<P>For example, the <VAR>private-or-clear</VAR> policy tells
FreeS/WAN to prefer encrypted communication to the listed CIDR blocks.
Failing that, it allows talk in the clear.</P>
<P>To make this your default policy, place
<A HREF="glossary.html#fullnet">fullnet</A>
in the <VAR>private-or-clear</VAR> policy group file:</P>
<PRE> [root@xy root]# cat /etc/ipsec.d/policies/private-or-clear
# This file defines the set of CIDRs (network/mask-length) to which
# communication should be private, if possible, but in the clear otherwise.
....
0.0.0.0/0</PRE>
<P>and reload your policies with</P>
<PRE> ipsec auto --rereadgroups</PRE>
<P>Use <A HREF="quickstart.html#opp.test">this test</A> to verify
opportunistic connections.</P>
<A NAME="example2"></A><H3>Example 2: Defining IPsec Security Policy
with Groups</H3>
<P>Defining IPsec security policy with Base Policy Groups is like creating
a shopping list: just put CIDR blocks in the appropriate group files.
For example:</P>
<PRE> [root@xy root]# cd /etc/ipsec.d/policies
[root@xy policies]# cat private
192.0.2.96/27 # The finance department
192.0.2.192/29 # HR
192.0.2.12 # HR gateway
irc.private.example.com # Private IRC server
[root@xy policies]# cat private-or-clear
0.0.0.0/0 # My default policy: try to encrypt.
[root@xy policies]# cat clear
192.0.2.18/32 # My POP3 server
192.0.2.19/32 # My Web proxy
[root@xy policies]# cat block
spamsource.example.com</PRE>
<P>To make these settings take effect, type:</P>
<PRE> ipsec auto --rereadgroups</PRE>
<P>Notes:</P>
<UL>
<LI>For opportunistic connection attempts to succeed, all participating
FreeS/WAN hosts and gateways must be configured for OE.</LI>
<LI>Examples 3 through 5 show how to implement a detailed <VAR>private</VAR>
policy.</LI>
<LI>
<A NAME="dnswarning"></A>
<FONT COLOR=RED>Warning:</FONT> Using DNS names in policy files and ipsec.conf
can be tricky. If the name does not resolve, the policy will not be
implemented for that name.
It is therefore safer either to use IPs, or to put any critical names
in /etc/hosts.
We plan to implement periodic DNS retry to help with this.
<BR>
Names are resolved at FreeS/WAN startup, or when the policies are reloaded.
Unfortunately, name lookup can hold up the startup process.
If you have fast DNS servers, the problem may be less severe.
</LI>
</UL>
<A HREF="example3"></A><H3>Example 3: Creating a Simple IPsec VPN with the
<VAR>private</VAR> Group</H3>
<P>You can create an IPsec VPN between several hosts, with
only one line of configuration per host, using the <VAR>private</VAR>
policy group.</P>
<P>First, use our <A HREF="quickstart.html">quickstart
guide</A> to set up each participating host
with a FreeS/WAN install and OE.</P>
<P>In one host's <VAR>/etc/ipsec.d/policies/private</VAR>,
list the peers to which you wish to protect traffic.
For example:</P>
<PRE> [root@xy root]# cd /etc/ipsec.d/policies
[root@xy policies]# cat private
192.0.2.9 # several hosts at example.com
192.0.2.11
192.0.2.12
irc.private.example.com
</PRE>
<P>Copy the <VAR>private</VAR> file to each host. Remove the local host, and
add the initial host.</P>
<PRE> scp2 /etc/ipsec.d/policies/private root@192.0.2.12:/etc/ipsec.d/policies/private</PRE>
<P>On each host, reread the policy groups with</P>
<PRE> ipsec auto --rereadgroups</PRE>
<P>That's it! You're configured.</P>
<P>Test by pinging between two hosts. After a second or two,
traffic should flow, and</P>
<PRE> ipsec eroute</PRE>
<P>should yield something like</P>
<PRE> 192.0.2.11/32 -> 192.0.2.8/32 => tun0x149f@192.0.2.8</PRE>
<P>where your host IPs are substituted for 192.0.2.11 and 192.0.2.8.</P>
<P>If traffic does not flow, there may be an error in your OE setup.
Revisit our <A HREF="quickstart.html">quickstart guide</A>.</P>
<P>Our next two examples show you how to add subnets to this IPsec VPN.</P>
<A NAME="example4"></A><H3>Example 4: New Policy Groups to Protect a
Subnet</H3>
<P>To protect traffic to a subnet behind your FreeS/WAN gateway,
you'll need additional DNS records, and new policy groups.
To set up the DNS, see our <A HREF="quickstart.html#opp.gate">quickstart
guide</A>. To create five new policy groups for your subnet,
copy these connections to <VAR>/etc/ipsec.conf</VAR>.
Substitute your subnet's IPs for 192.0.2.128/29.</P>
<PRE>
conn private-net
also=private # inherits settings (eg. auto=start) from built in conn
leftsubnet=192.0.2.128/29 # your subnet's IPs here
conn private-or-clear-net
also=private-or-clear
leftsubnet=192.0.2.128/29
conn clear-or-private-net
also=clear-or-private
leftsubnet=192.0.2.128/29
conn clear-net
also=clear
leftsubnet=192.0.2.128/29
conn block-net
also=block
leftsubnet=192.0.2.128/29
</PRE>
<P>Copy the gateway's files to serve as the initial policy group files for the
new groups:</P>
<PRE>
cp -p /etc/ipsec.d/policies/private /etc/ipsec.d/policies/private-net
cp -p /etc/ipsec.d/policies/private-or-clear /etc/ipsec.d/policies/private-or-clear-net
cp -p /etc/ipsec.d/policies/clear-or-private /etc/ipsec.d/policies/clear-or-private-net
cp -p /etc/ipsec.d/policies/clear /etc/ipsec.d/policies/clear-net
cp -p /etc/ipsec.d/policies/block /etc/ipsec.d/policies/block
</PRE>
<P><STRONG>Tip: Since a missing policy group file is equivalent to a file with
no entries, you need only create files for the connections
you'll use.</STRONG></P>
<P>To test one of your new groups, place the fullnet 0.0.0.0/0 in
<VAR>private-or-clear-net</VAR>.
Perform the subnet test in
<A HREF="quickstart.html#opp.test">our quickstart guide</A>. You should
see a connection, and</P>
<PRE> ipsec eroute</PRE>
<P>should include an entry which mentions the subnet node's IP and the
OE test site IP, like this:</P>
<PRE> 192.0.2.131/32 -> 192.139.46.77/32 => tun0x149f@192.0.2.11</PRE>
<A HREF="example5"></A><H3>Example 5: Adding a Subnet to the VPN</H3>
<P>Suppose you wish to secure traffic to a subnet 192.0.2.192/29
behind a FreeS/WAN box 192.0.2.12.</P>
<P>First, add DNS entries to configure 192.0.2.12 as an opportunistic
gateway for that subnet. Instructions are in
our <A HREF="quickstart.html#opp.gate">quickstart guide</A>.
Next, create a <VAR>private-net</VAR> group on 192.0.2.12 as described in
<A HREF="#example4">Example 4</A>.
</P>
<P>On each other host, add the subnet 192.0.2.192/29 to <VAR>private</VAR>,
yielding for example</P>
<PRE> [root@xy root]# cd /etc/ipsec.d/policies
[root@xy policies]# cat private
192.0.2.9 # several hosts at example.com
192.0.2.11
192.0.2.12 # HR department gateway
192.0.2.192/29 # HR subnet
irc.private.example.com
</PRE>
<P>and reread policy groups with </P>
<PRE> ipsec auto --rereadgroups</PRE>
<P>That's all the configuration you need.</P>
<P>Test your VPN by pinging from a machine on 192.0.2.192/29 to any other host:
</P>
<PRE> [root@192.0.2.194]# ping 192.0.2.11</PRE>
<P>After a second or two, traffic should flow, and</P>
<PRE> ipsec eroute</PRE>
<P>should yield something like</P>
<PRE> 192.0.2.11/32 -> 192.0.2.194/32 => tun0x149f@192.0.2.12
</PRE>
<P>Key:</P>
<TABLE>
<TR><TD>1.</TD>
<TD>192.0.2.11/32</TD>
<TD>Local start point of the protected traffic.
</TD></TR>
<TR><TD>2.</TD>
<TD>192.0.2.194/32</TD>
<TD>Remote end point of the protected traffic.
</TD></TR>
<TR><TD>3.</TD>
<TD>192.0.2.12</TD>
<TD>Remote FreeS/WAN node (gateway or host).
May be the same as (2).
</TD></TR>
<TR><TD>4.</TD>
<TD>[not shown]</TD>
<TD>Local FreeS/WAN node (gateway or host),
where you've produced the output.
May be the same as (1).
</TD></TR>
</TABLE>
<P>For additional assurance, you can verify with a packet sniffer
that the traffic is being encrypted.</P>
<P>Note</P>
<UL>
<LI>Because strangers may also connect via OE,
this type of VPN may require a stricter firewalling policy than a
conventional VPN.</LI></UL>
<H2>Appendix</H2>
<A NAME="hiddenconn"></A><H3>Our Hidden Connections</H3>
<P>Our Base Policy Groups are created using hidden connections.
These are spelled out in
<A HREF="manpage.d/ipsec.conf.5.html">man ipsec.conf</A>
and defined in <VAR>/usr/local/lib/ipsec/_confread</VAR>.
</P>
<A NAME="custom_policygroups"></A><H3>Custom Policy Groups</H3>
<P>A policy group is built using a special connection description
in <VAR>ipsec.conf</VAR>, which:</P>
<UL>
<LI>is <STRONG>generic</STRONG>. It uses
<VAR>right=[%group|%opportunisticgroup]</VAR> rather than specific IPs.
The connection is cloned for every name or IP range listed in its Policy Group
file.</LI>
<LI>often has a <STRONG>failure rule</STRONG>. This rule, written
<VAR>failureshunt=[passthrough|drop|reject|none]</VAR>, tells FreeS/WAN
what to do with packets for these CIDRs if it fails to establish the connection.
Default is <VAR>none</VAR>.
</LI>
</UL>
<P>To create a new group:</P>
<OL>
<LI>Create its connection definition in <VAR>ipsec.conf</VAR>.</LI>
<LI>Create a Policy Group file in <VAR>/etc/ipsec.d/policies</VAR>
with the same name as your connection.
</LI>
<LI>Put a CIDR block in that file.</LI>
<LI>Reread groups with <VAR>ipsec auto --rereadgroups</VAR>.</LI>
<LI>Test: <VAR>ping</VAR> to activate any OE connection, and view
results with <VAR>ipsec eroute</VAR>.</LI>
</OL>
<A NAME="disable_oe"></A>
<A NAME="disable_policygroups"></A><H3>Disabling Opportunistic Encryption</H3>
<P>To disable OE (eg. policy groups and packetdefault), cut and paste the following lines
to <VAR>/etc/ipsec.conf</VAR>:</P>
<PRE>conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore</PRE>
<P>Restart FreeS/WAN so that the changes take effect:</P>
<PRE> ipsec setup restart</PRE>
</body>
</html>
|