]>
Commit | Line | Data |
---|---|---|
997358a6 MW |
1 | <html> |
2 | <head> | |
3 | <meta http-equiv="Content-Type" content="text/html"> | |
4 | <title>FreeS/WAN configuration</title> | |
5 | <meta name="keywords" | |
6 | content="Linux, IPsec, VPN, security, FreeSWAN, installation, quickstart"> | |
7 | <!-- | |
8 | ||
9 | Written by Claudia Schmeing for the Linux FreeS/WAN project | |
10 | Freely distributable under the GNU General Public License | |
11 | ||
12 | More information at www.freeswan.org | |
13 | Feedback to users@lists.freeswan.org | |
14 | ||
15 | CVS information: | |
16 | RCS ID: $Id: config.html,v 1.1 2004/03/15 20:35:24 as Exp $ | |
17 | Last changed: $Date: 2004/03/15 20:35:24 $ | |
18 | Revision number: $Revision: 1.1 $ | |
19 | ||
20 | CVS revision numbers do not correspond to FreeS/WAN release numbers. | |
21 | --> | |
22 | </head> | |
23 | <BODY> | |
24 | <H1><A NAME="config">How to configure FreeS/WAN</A></H1> | |
25 | ||
26 | <P>This page will teach you how to configure a simple network-to-network | |
27 | link or a Road Warrior connection between two Linux FreeS/WAN boxes. | |
28 | </P> | |
29 | ||
30 | <P>See also these related documents:</P> | |
31 | <UL> | |
32 | <LI>our <A HREF="quickstart.html#quickstart">quickstart</A> guide | |
33 | to <A HREF="glossary.html#carpediem">opportunistic encryption</A></LI> | |
34 | <LI>our guide to configuration with | |
35 | <A HREF="policygroups.html#policygroups">policy groups</A></LI> | |
36 | <LI>our | |
37 | <A HREF="adv_config.html#adv_config">advanced configuration</A> | |
38 | document</LI> | |
39 | </UL> | |
40 | <P> | |
41 | The network-to-network setup allows you to connect two office | |
42 | networks into one Virtual Private Network, while the Road Warrior | |
43 | connection secures a laptop's telecommute to work. | |
44 | Our examples also show the basic procedure on the Linux FreeS/WAN side where | |
45 | another IPsec peer is in play.</P> | |
46 | ||
47 | <P> | |
48 | Shortcut to <A HREF="#config.netnet">net-to-net</A>.<BR> | |
49 | Shortcut to <A HREF="#config.rw">Road Warrior</A>. | |
50 | </P> | |
51 | ||
52 | <H2>Requirements</H2> | |
53 | ||
54 | <P>To configure the network-to-network connection you must have:</P> | |
55 | <UL> | |
56 | <LI>two Linux gateways with static IPs</LI> | |
57 | <LI>a network behind each gate. Networks must have non-overlapping IP ranges.</LI> | |
58 | <LI>Linux FreeS/WAN <A HREF="install.html#install">installed</A> | |
59 | on both gateways</LI> | |
60 | <LI><A HREF="http://www.tcpdump.org"><VAR>tcpdump</VAR></A> on the local gate, | |
61 | to test the connection</LI> | |
62 | </UL> | |
63 | <P>For the Road Warrior you need:</P> | |
64 | <UL> | |
65 | <LI>one Linux box with a static IP</LI> | |
66 | <LI>a Linux laptop with a dynamic IP</LI> | |
67 | <LI>Linux FreeS/WAN installed on both</LI> | |
68 | <LI>for testing, <VAR>tcpdump</VAR> on your gateway or laptop</LI> | |
69 | </UL> | |
70 | ||
71 | <P>If both IPs are dynamic, your situation is a bit trickier. Your best bet | |
72 | is a variation on the <A HREF="#config.rw">Road Warrior</A>, as described | |
73 | in <A HREF="http://lists.freeswan.org/archives/users/2003-October/msg00282.html">this mailing list message</A>. | |
74 | ||
75 | <H2><A name="config.netnet"></A>Net-to-Net connection</H2> | |
76 | ||
77 | ||
78 | <H3><A name="netnet.info.ex">Gather information</A></H3> | |
79 | ||
80 | <P>For each gateway, compile the following information:</P> | |
81 | <UL> | |
82 | <LI>gateway IP</LI> | |
83 | <LI>IP range of the subnet you will be protecting. This doesn't have to | |
84 | be your whole physical subnet.</LI> | |
85 | <LI>a name by which that gateway can identify itself for IPsec | |
86 | negotiations. Its form is a Fully Qualified Domain Name preceded by | |
87 | an @ sign, ie. @xy.example.com. | |
88 | <BR>It does not need to be within a domain that you own. It can be a made-up | |
89 | name.</LI> | |
90 | </UL> | |
91 | ||
92 | ||
93 | <H4>Get your leftrsasigkey</H4> | |
94 | <P>On your local Linux FreeS/WAN gateway, print your IPsec public key:</P> | |
95 | <PRE> ipsec showhostkey --left</PRE> | |
96 | <P>The output should look like this (with the key shortened for easy | |
97 | reading):</P> | |
98 | <PRE> # RSA 2048 bits xy.example.com Fri Apr 26 15:01:41 2002 | |
99 | leftrsasigkey=0sAQOnwiBPt...</PRE> | |
100 | ||
101 | <P>Don't have a key? Use | |
102 | <A HREF="manpage.d/ipsec_newhostkey.8.html"><VAR>ipsec newhostkey</VAR></A> | |
103 | to create one. | |
104 | ||
105 | <H4>...and your rightrsasigkey</H4> | |
106 | <P>Get a console on the remote side:</P> | |
107 | <PRE> ssh2 ab.example.com</PRE> | |
108 | <P>In that window, type:</P> | |
109 | <PRE> ipsec showhostkey --right</PRE> | |
110 | <P>You'll see something like:</P> | |
111 | <PRE> # RSA 2192 bits ab.example.com Thu May 16 15:26:20 2002 | |
112 | rightrsasigkey=0sAQOqH55O...</PRE> | |
113 | ||
114 | <H3>Edit <VAR>/etc/ipsec.conf</VAR></H3> | |
115 | ||
116 | <P>Back on the local gate, copy our template to <VAR>/etc/ipsec.conf</VAR>. | |
117 | (on Mandrake, <VAR>/etc/freeswan/ipsec.conf</VAR>). | |
118 | Substitute the information you've gathered for our example data.</P> | |
119 | <PRE>conn net-to-net | |
120 | left=192.0.2.2 # Local vitals | |
121 | leftsubnet=192.0.2.128/29 # | |
122 | leftid=@xy.example.com # | |
123 | leftrsasigkey=0s1LgR7/oUM... # | |
124 | leftnexthop=%defaultroute # correct in many situations | |
125 | right=192.0.2.9 # Remote vitals | |
126 | rightsubnet=10.0.0.0/24 # | |
127 | rightid=@ab.example.com # | |
128 | rightrsasigkey=0sAQOqH55O... # | |
129 | rightnexthop=%defaultroute # correct in many situations | |
130 | auto=add # authorizes but doesn't start this | |
131 | # connection at startup</PRE> | |
132 | ||
133 | <P> | |
134 | "Left" and "right" should represent the machines that have FreeS/WAN installed | |
135 | on them, and "leftsubnet" and "rightsubnet" machines that are being protected. | |
136 | /32 is assumed for left/right and left/rightsubnet parameters. | |
137 | </P> | |
138 | ||
139 | <P>Copy <VAR>conn net-to-net</VAR> to the remote-side /etc/ipsec.conf. | |
140 | If you've made no other modifications to either <VAR>ipsec.conf</VAR>, | |
141 | simply:</P> | |
142 | <PRE> scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf</PRE> | |
143 | ||
144 | <H3>Start your connection</H3> | |
145 | ||
146 | <P>Locally, type:</P> | |
147 | <PRE> ipsec auto --up net-to-net</PRE> | |
148 | ||
149 | <P>You should see:</P> | |
150 | <PRE> 104 "net-net" #223: STATE_MAIN_I1: initiate | |
151 | 106 "net-net" #223: STATE_MAIN_I2: sent MI2, expecting MR2 | |
152 | 108 "net-net" #223: STATE_MAIN_I3: sent MI3, expecting MR3 | |
153 | 004 "net-net" #223: STATE_MAIN_I4: ISAKMP SA established | |
154 | 112 "net-net" #224: STATE_QUICK_I1: initiate | |
155 | 004 "net-net" #224: STATE_QUICK_I2: sent QI2, IPsec SA established</PRE> | |
156 | ||
157 | <P>The important thing is <VAR>IPsec SA established</VAR>. If you're | |
158 | unsuccessful, see our | |
159 | <A HREF="trouble.html#trouble">troubleshooting tips</A>.</P> | |
160 | ||
161 | ||
162 | <H3>Do not MASQ or NAT packets to be tunneled</H3> | |
163 | ||
164 | <P>If you are using <A HREF="glossary.html#masq">IP masquerade</A> or | |
165 | <A HREF="glossary.html#NAT.gloss">Network Address Translation (NAT)</A> | |
166 | on either gateway, | |
167 | you must now exempt the packets you wish to tunnel from this treatment. | |
168 | For example, if you have a rule like:</P> | |
169 | ||
170 | <PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE | |
171 | </PRE> | |
172 | ||
173 | <P>change it to something like:</P> | |
174 | <PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE</PRE> | |
175 | ||
176 | <P>This may be necessary on both gateways.</P> | |
177 | ||
178 | ||
179 | <H3>Test your connection</H3> | |
180 | ||
181 | <P>Sit at one of your local subnet nodes (not the gateway), and ping a subnet | |
182 | node on the other (again, not the gateway).</P> | |
183 | ||
184 | <PRE> ping fileserver.toledo.example.com</PRE> | |
185 | ||
186 | <P>While still pinging, go to the local gateway and snoop your outgoing | |
187 | interface, for example:</P> | |
188 | <PRE> tcpdump -i ppp0</PRE> | |
189 | <P>You want to see ESP (Encapsulating Security Payload) packets moving | |
190 | <B>back and forth</B> between the two gateways at the same frequency as | |
191 | your pings:</P> | |
192 | <PRE> 19:16:32.046220 192.0.2.2 > 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3) | |
193 | 19:16:32.085630 192.0.2.9 > 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)</PRE> | |
194 | ||
195 | <P>If you see this, congratulations are in order! You have a tunnel which | |
196 | will protect any IP data from one subnet | |
197 | to the other, as it passes between the two gates. | |
198 | If not, go and <A HREF="trouble.html#trouble">troubleshoot</A>.</P> | |
199 | ||
200 | <P>Note: your new tunnel protects only net-net traffic, not | |
201 | gateway-gateway, or gateway-subnet. If you need this (for example, if | |
202 | machines on one net need to securely contact a fileserver on the | |
203 | IPsec gateway), you'll need to create | |
204 | <A HREF="adv_config.html#adv_config">extra connections</A>.</P> | |
205 | ||
206 | ||
207 | <H3>Finishing touches</H3> | |
208 | ||
209 | <P>Now that your connection works, name it something sensible, like:</P> | |
210 | <PRE>conn winstonnet-toledonet</PRE> | |
211 | <P>To have the tunnel come up on-boot, replace</P> | |
212 | <PRE> auto=add</PRE> | |
213 | <P>with:</P> | |
214 | <PRE> auto=start</PRE> | |
215 | <P>Copy these changes to the other side, for example:</P> | |
216 | <PRE> scp2 ipsec.conf root@ab.example.com:/etc/ipsec.conf</PRE> | |
217 | <P>Enjoy!</P> | |
218 | ||
219 | ||
220 | ||
221 | <H2><A name="config.rw"></A>Road Warrior Configuration</H2> | |
222 | ||
223 | <H3><A name="rw.info.ex">Gather information</A></H3> | |
224 | ||
225 | <P>You'll need to know:</P> | |
226 | <UL> | |
227 | <LI>the gateway's static IP</LI> | |
228 | <LI>the IP range of the subnet behind that gateway</LI> | |
229 | <LI>a name by which each side can identify itself for IPsec | |
230 | negotiations. Its form is a Fully Qualified Domain Name preceded by | |
231 | an @ sign, ie. @road.example.com. | |
232 | <BR>It does not need to be within a domain that you own. It can be a made-up | |
233 | name.</LI> | |
234 | </UL> | |
235 | ||
236 | <H4>Get your leftrsasigkey...</H4> | |
237 | <P>On your laptop, print your IPsec public key:</P> | |
238 | <PRE> ipsec showhostkey --left</PRE> | |
239 | <P>The output should look like this (with the key shortened for easy | |
240 | reading):</P> | |
241 | <PRE> # RSA 2192 bits road.example.com Sun Jun 9 02:45:02 2002 | |
242 | leftrsasigkey=0sAQPIPN9uI...</PRE> | |
243 | ||
244 | <P>Don't have a key? See | |
245 | <A HREF="old_config.html#genrsakey">these instructions</A>. | |
246 | ||
247 | ||
248 | <H4>...and your rightrsasigkey</H4> | |
249 | <P>Get a console on the gateway:</P> | |
250 | <PRE> ssh2 xy.example.com</PRE> | |
251 | <P>View the gateway's public key with:</P> | |
252 | <PRE> ipsec showhostkey --right</PRE> | |
253 | <P>This will yield something like</P> | |
254 | <PRE> # RSA 2048 bits xy.example.com Fri Apr 26 15:01:41 2002 | |
255 | rightrsasigkey=0sAQOnwiBPt...</PRE> | |
256 | ||
257 | ||
258 | <H3>Customize <VAR>/etc/ipsec.conf</VAR></H3> | |
259 | ||
260 | <P>On your laptop, copy this template to <VAR>/etc/ipsec.conf</VAR>. | |
261 | (on Mandrake, <VAR>/etc/freeswan/ipsec.conf</VAR>). | |
262 | Substitute the information you've gathered for our example data.</P> | |
263 | <PRE>conn road | |
264 | left=%defaultroute # Picks up our dynamic IP | |
265 | leftnexthop=%defaultroute # | |
266 | leftid=@road.example.com # Local information | |
267 | leftrsasigkey=0sAQPIPN9uI... # | |
268 | right=192.0.2.10 # Remote information | |
269 | rightsubnet=10.0.0.0/24 # | |
270 | rightid=@xy.example.com # | |
271 | rightrsasigkey=0sAQOnwiBPt... # | |
272 | auto=add # authorizes but doesn't start this | |
273 | # connection at startup</PRE> | |
274 | ||
275 | <P>The template for the gateway is different. Notice how it | |
276 | reverses <VAR>left</VAR> and <VAR>right</VAR>, in keeping with our | |
277 | convention that <STRONG>L</STRONG>eft is <STRONG>L</STRONG>ocal, | |
278 | <STRONG>R</STRONG>ight <STRONG>R</STRONG>emote. Be sure to switch your | |
279 | rsasigkeys in keeping with this.</P> | |
280 | ||
281 | <PRE> ssh2 xy.example.com | |
282 | vi /etc/ipsec.conf</PRE> | |
283 | ||
284 | <P>and add:</P> | |
285 | ||
286 | <PRE>conn road | |
287 | left=192.0.2.2 # Gateway's information | |
288 | leftid=@xy.example.com # | |
289 | leftsubnet=192.0.2.128/29 # | |
290 | leftrsasigkey=0sAQOnwiBPt... # | |
291 | rightnexthop=%defaultroute # correct in many situations | |
292 | right=%any # Wildcard: we don't know the laptop's IP | |
293 | rightid=@road.example.com # | |
294 | rightrsasigkey=0sAQPIPN9uI... # | |
295 | auto=add # authorizes but doesn't start this | |
296 | # connection at startup</PRE> | |
297 | ||
298 | ||
299 | ||
300 | <H3>Start your connection</H3> | |
301 | ||
302 | <P>You must start the connection from the Road Warrior side. On your laptop, | |
303 | type:</P> | |
304 | <PRE> ipsec auto --start net-to-net</PRE> | |
305 | ||
306 | <P>You should see:</P> | |
307 | <PRE>104 "net-net" #223: STATE_MAIN_I1: initiate | |
308 | 106 "road" #301: STATE_MAIN_I2: sent MI2, expecting MR2 | |
309 | 108 "road" #301: STATE_MAIN_I3: sent MI3, expecting MR3 | |
310 | 004 "road" #301: STATE_MAIN_I4: ISAKMP SA established | |
311 | 112 "road" #302: STATE_QUICK_I1: initiate | |
312 | 004 "road" #302: STATE_QUICK_I2: sent QI2, IPsec SA established</PRE> | |
313 | ||
314 | <P>Look for <VAR>IPsec SA established</VAR>. If you're | |
315 | unsuccessful, see our | |
316 | <A HREF="trouble.html#trouble">troubleshooting tips</A>.</P> | |
317 | ||
318 | ||
319 | ||
320 | <H3>Do not MASQ or NAT packets to be tunneled</H3> | |
321 | ||
322 | <P>If you are using <A HREF="glossary.html#masq">IP masquerade</A> or | |
323 | <A HREF="glossary.html#NAT.gloss">Network Address Translation (NAT)</A> | |
324 | on either gateway, | |
325 | you must now exempt the packets you wish to tunnel from this treatment. | |
326 | For example, if you have a rule like:</P> | |
327 | ||
328 | <PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -j MASQUERADE | |
329 | </PRE> | |
330 | ||
331 | <P>change it to something like:</P> | |
332 | <PRE>iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/24 -d \! 192.0.2.128/29 -j MASQUERADE</PRE> | |
333 | ||
334 | ||
335 | <H3>Test your connection</H3> | |
336 | ||
337 | <P>From your laptop, ping a subnet node behind the remote gateway. Do not | |
338 | choose the gateway itself for this test.</P> | |
339 | ||
340 | <PRE> ping ns.winston.example.com</PRE> | |
341 | ||
342 | <P>Snoop the packets exiting the laptop, with a command like:</P> | |
343 | <PRE> tcpdump -i wlan0</PRE> | |
344 | <P>You have success if you see (Encapsulating Security Payload) packets | |
345 | travelling <B>in both directions</B>:</P> | |
346 | ||
347 | <PRE> 19:16:32.046220 192.0.2.2 > 192.0.2.9: ESP(spi=0x3be6c4dc,seq=0x3) | |
348 | 19:16:32.085630 192.0.2.9 > 192.0.2.2: ESP(spi=0x5fdd1cf8,seq=0x6)</PRE> | |
349 | ||
350 | ||
351 | <P>If you do, great! Traffic between your Road Warrior and the net | |
352 | behind your gateway is protected. | |
353 | If not, see our | |
354 | <A HREF="trouble.html#trouble">troubleshooting hints</A>.</P> | |
355 | ||
356 | <P>Your new tunnel protects only traffic addressed to the net, not to | |
357 | the IPsec gateway itself. If you need the latter, you'll want to make an | |
358 | <A HREF="adv_config.html#adv_config">extra tunnel.</A>.</P> | |
359 | ||
360 | <H3>Finishing touches</H3> | |
361 | ||
362 | <P>On both ends, name your connection wisely, like:</P> | |
363 | <PRE>conn mike-to-office</PRE> | |
364 | <P><B>On the laptop only,</B> replace</P> | |
365 | <PRE> auto=add</PRE> | |
366 | <P>with:</P> | |
367 | <PRE> auto=start</PRE> | |
368 | <P>so that you'll be connected on-boot.</P> | |
369 | <P>Happy telecommuting!</P> | |
370 | ||
371 | <H3>Multiple Road Warriors</H3> | |
372 | ||
373 | <P>If you're using RSA keys, as we did in this example, you can add | |
374 | as many Road Warriors as you like. The left/rightid | |
375 | parameter lets Linux FreeS/WAN distinguish between multiple Road Warrior | |
376 | peers, each with its own public key.</P> | |
377 | ||
378 | <P>The situation is different for shared secrets (PSK). During a | |
379 | PSK negotiation, ID information is not available at the time Pluto | |
380 | is trying to determine which secret to use, so, effectively, you can | |
381 | only define one Roadwarrior connection. All your PSK road warriors | |
382 | must therefore share one secret.</P> | |
383 | ||
384 | ||
385 | <H2>What next?</H2> | |
386 | ||
387 | <P>Using the principles illustrated here, you can try variations such as: | |
388 | <UL> | |
389 | <LI>a telecommuter with a static IP</LI> | |
390 | <LI>a road warrior with a subnet behind it</LI> | |
391 | </UL> | |
392 | <P>Or, look at some of our <A HREF="adv_config.html#adv_config">more complex configuration examples.</A>.</P> | |
393 | </BODY> | |
394 | </HTML> |