Merge udptunnelconf branch; cvs up -j branchpoint-2000-12-10-udptunnelconf -j mergepo...
[userv-utils] / ipif / INSTALL
1 This file, INSTALL, is a -*- text -*- file tutorial on how to
2 * install userv ipif and udptunnel,
3 * configure them to create a VPN tunnel between two hosts or
4 networks, or
5 * use udptunnel-reconf to create a multi-site VPN.
6
7
8 See README for details of other available documentation.
9
10
11 BUILD AND INSTALLATION INSTRUCTIONS
12 -----------------------------------
13
14 1. Install userv, 1.0.1 or later. This is in Debian GNU/Linux.
15
16 2. Make sure your Linux kernel has SLIP and CSLIP compiled in.
17 You will need to be using Linux 2.2 (with Unix98-style ptys).
18
19 3. udptunnel works best if your ssh can do ssh-protocol-level
20 keepalives. Currently these are only supported by using a special
21 patch, which can be found (for OpenSSH 1.2.x) at
22 ftp.chiark.greenend.org.uk:/users/ian/openssh+protocolkeepalives.
23
24 4. Obtain a fresh copy of userv-utils, if you haven't already.
25 cd to ipif, and run `make' and (as root) `make install'.
26
27 After you have done this the software will still not do anything, and
28 by default userv ipif will not allow anyone (except root) to create
29 network interfaces.
30
31 The software will probably only work on Linux - in particular, userv
32 ipif's service program (service.c) uses Linux-specific ways of
33 setting up SLIP interfaces. It might be possible in principle to
34 create alternatives for other platforms.
35
36 `slattach' problem:
37
38 There is a problem with some versions of `slattach' on Linux. If you
39 see a message from it about being unable to open /dev/2 or some such,
40 then you need to upgrade or patch your `slattach'. In Debian
41 GNU/Linux it's in the `netbase' package, and the fix is in Debian 2.1
42 in 3.16-3 and later; however the bug has regressed, and is known to
43 be in Debian 2.2's 3.18-4 and earlier. The relevant Debian bug
44 reports are #45515 (now closed) and #45944. A patch to correct
45 3.18-4 is provided here as `slattach.diff', and a fixed binary is
46 available from the author.
47
48
49
50 UDPTUNNEL SETUP TUTORIAL
51 ------------------------
52
53
54 1. BACKGROUND INFORMATION
55
56 Firstly, note that userv ipif and udptunnel are extremely flexible,
57 as they aim to be `Lego brick' networking components. Many much more
58 interesting configurations can be constructed than there is room to
59 document here. If you want to do something strange, consult the
60 README to locate the appropriate reference documentation.
61
62 1.1. About udptunnel
63
64 udptunnel is point-to-point; you need a separate `invocation' for
65 each pair of machines (or networks) you wish to connect.
66
67 It is `one-shot': it will set up a tunnel and keep it going as long
68 as it can, and then exit; if you want a permanent tunnel you must
69 arrange to reinvoke udptunnel.
70
71 It is asymmetric, in that one of the endpoints starts the tunnel, and
72 the other sits and waits to be contacted. We'll call the active
73 endpoint `alice' and the passive endpoint `bob'. Usually alice
74 invokes udptunnel on bob via OpenSSH (`ssh').
75
76 udptunnel does not need root privilege to run. However, you do need
77 to configure userv ipif to know that the user who will be running
78 udptunnel is permitted to use the IP addresses and network ranges
79 which will be used. So, though most of the configuration can be done
80 as the normal users who will run udptunnel on each end, a small
81 amount (editing /etc/userv/ipif-networks) needs to be done as root on
82 each end - and the information configured as root needs to match up
83
84 This tutorial will explain how to do these things.
85
86 1.2. About point-to-point tunnelling in general
87
88 A tunnel is an _additional_ (in the case of udptunnel, encrypted)
89 network link between a pair of machines. Packets are encapsulated at
90 one end, sent over the real network between them, and decoded again
91 at the other end. As with any network connection, it is possible to
92 arrange for networks behind the endpoint machines to be able to
93 communicate via the tunnel.
94
95 Each endpoint machine will have at least two network interfaces:
96 Firstly, the real `physical' interface through which the encapsulated
97 packets will be really sent and received. Secondly, the `virtual'
98 interface created by the tunnelling software, which represents its
99 end of the (encrypted) tunnel link. The physical and virtual
100 interfaces MUST have different addresses.
101
102 Each endpoint machine may also have additional network interfaces;
103 for example, it may be the router for a network which sits behind it,
104 which an interface on that network, or it may be the endpoint for
105 more than one tunnel. It is OK for several tunnels terminating at
106 the same machine to use the same virtual address (provided that the
107 tunnels are not `layered' on top of each other but are `in
108 parallel'), and it is also OK to use as the virtual tunnel address a
109 router's address on a private network which will be sent via the
110 tunnel.
111
112 1.3. Diagram
113
114 ____ ______________ ______________ ____
115 __( )__ |ALICE | | BOB| __( )__
116 ,' ` ' `. | _ | Tunnel | _ | ,' ` ' `.
117 | alice | | |\\ ,- - - - - - - - - -. //| | | bob |
118 `._private _.' | | || | | || | | `._private _.'
119 | networks |==+--------'|| | Public | ||`--------+==| networks |
120 | | | alice | Network | bob | | |
121 `.~ ~.' | virtual +=============+ virtual | `.~ ~.'
122 (__,'`.__) |______________|alice bob|______________| (__,'`.__)
123 physical physical
124 _
125 Key: HOSTNAME +===+ Actual Network |\\ Tunnel
126 Descriptive Text ----- Data Flow | ||Endpoint
127 host or network number - - - Encrypted Data Flow ||
128
129
130 2. INFORMATION COLLECTION AND PRELIMINARY SETUP
131
132 You will need to collect and/or decide upon various information, and
133 make sure that your two endpoint systems can talk to each other over
134 the public network.
135
136 2.1. Find out, or choose, private network numbers
137
138 You need to make sure you know what all of the addresses in the above
139 diagram are going to be.
140
141 Usually you must choose the private and virtual addresses yourself:
142 hosts on the private networks usually won't communicate with the
143 global Internet other than through proxies or masquerading firewalls.
144
145 You MUST choose from the reserved ranges in RFC1918, which are:
146 172.16.0.0/12 192.168.0.0/16 10.0.0.0/8
147 If you do not do so you'll end up reusing someone else's addresses,
148 which can cause lots of hard-to-diagnose and embarrasing problems.
149
150 You should CHOOSE RANDOMLY ! This makes sure that when you decide to
151 connect your VPN to someone else's VPN, your network allocation
152 numbers are unlikely to clash. If you both choose 192.168.0.0/24
153 you'll have to renumber (and will look like fools).
154
155 To help with choosing random network numbers from RFC1918 space, the
156 author maintains a web page at <http://www.ucam.org/cam-grin/>, which
157 can pick network numbers for you.
158
159 Additionally, there is a database there - people in Cambridge (in
160 England) are encouraged to register their network address usage
161 there. Please do not register in the database unless you're likely
162 to want to connect your VPN to others already listed.
163
164 2.2. Find out, or choose, public network numbers
165
166 These are usually specified by your ISP, either statically or
167 dynamically assigned. If the active end (`alice physical') is
168 dynamically assigned you can use the `Wait' option (see below) to
169 avoid specifying it, but otherwise you will need to have some kind of
170 script to find it each time you invoke udptunnel, or use a hostname
171 which automatically tracks the source host using dynamic DNS.
172
173 In some situations you may find yourself using a `public network'
174 which is not actually the public Internet - for example, you may want
175 to run one tunnel `through' another, or your `public network' is
176 actually a `private', but not sufficiently secure, radio LAN. In
177 this case you'll have to choose the addresses to use from
178 RFC1918-space, as above.
179
180 2.3. Decide which user account(s) on alice and bob you will use
181
182 These user accounts will see the plaintext for all network packets
183 going over the tunnel and if compromised will be able steal or forge
184 tunnel traffic. So, they should be reasonably secure.
185
186 Let us assume that the account on alice is called Tbob, and the
187 account on bob is called Talice. (NB that your system may not
188 correctly handle usernames containing uppercase.)
189
190 Each account should be in a group of its own, which will be used for
191 the userv ipif access control.
192
193 Arrange that Tbob@alice can ssh to Talice@bob without needing a
194 passphrase or other user interaction.
195
196 (Obviously, if you need to create accounts, edit groups, or change
197 the sshd configuratioon, you may need to be root.)
198
199 2.4. Decide whether to use `udptunnel-reconf'
200
201 There are two ways to set up a tunnel with udptunnel. Either you can
202 simply give udptunnel the right command, by putting it in an
203 appropriate script and arranging it to be called, or you can have a
204 program `udptunnel-reconf' read some configuration files and do it
205 for you.
206
207 udptunnel-reconf is not as well documented, but its behaviour is
208 somewhat more `cooked'. It is especially useful if you need to
209 maintain many tunnels as part of an organised, multi-site, VPN.
210
211 Using udptunnel directly is somewhat more flexible, and may be easier
212 if you only want one tunnel.
213
214
215 3. SETUP INSTRUCTIONS - USING UDPTUNNEL-RECONF
216
217 Edit or create the following files, as root:
218 /etc/userv/vpn/sites
219 /etc/userv/vpn/tunnels
220 /etc/userv/vpn/global
221
222 Run udptunnel-reconf, as root. This will create:
223 /var/lib/userv/vpn/passive-sites
224 /var/lib/userv/vpn/active-sites
225 /var/lib/userv/vpn/command.<site>
226
227 It will also spit out to stdout two things: firstly, a list of
228 suggested commands to put in your inittab, and secondly a suggested
229 line to put in your /etc/userv/ipif-networks.
230
231 Test that your setup is working, by running (one of) the
232 /var/lib/userv/vpn/command.<site> file(s) by hand - see section 5.
233 If it works, you can put the relevant things in your inittab and say
234 `init q'.
235
236 To find out what all the configuration settings do, look at
237 /usr/local/share/userv/udptunnel-vpn-defaults, which contains the
238 default settings and shows where all the hooks are. Consult section
239 4 of this file to understand what the options to udptunnel do.
240
241
242 4. SETUP INSTRUCTIONS - INVOKING UDPTUNNEL DIRECTLY
243
244 All of these steps can be done using the appropriate normal user
245 accounts, unless otherwise indicated.
246
247 4.1. Configure the private network numbers in /etc/userv/ipif-networks
248
249 (This step needs to be done as root.)
250
251 On alice, in /etc/userv/ipif-networks, put
252 <Tbob-gid>,=<alice-virt-addr>/32, <Tbob-group>, <comment>
253 <Tbob-gid>,<bob-virt-addr>/32, <Tbob-group>, <comment>
254 and for each of bob's private networks
255 <Tbob-gid>,<network>/<prefix-len>, <Tbob-group>, <comment>
256 You can leave out the <bob-virt-addr>/32 line if bob's virtual
257 address is in one of bob's private networks.
258
259 On bob, do the corresponding. In /etc/userv/ipif-networks, put
260 <Talice-gid>,=<bob-virt-addr>/32, <Talice-group>, <comment>
261 <Talice-gid>,<alice-virt-addr>/32, <Talice-group>, <comment>
262 and for each of alice's private networks
263 <Talice-gid>,<network>/<prefix-len>, <Talice-group>, <comment>
264 Again, you can leave out <alice-virt-addr> if one of the virtual
265 networks covers it.
266
267 All the specifications in /etc/userv/ipif-networks must be numerical
268 addresses - hostnames are not allowed. Also, the /32 indicating a
269 specific host cannot be omitted.
270
271 Note the use of `=' for each host's own virtual address, which
272 indicates to userv ipif that it's OK for that gid to create a local
273 interface with that address, but the address may not be assigned to a
274 remote host or route.
275
276 4.2. Construct the udptunnel invocation (on alice)
277
278 udptunnel has a long and complicated command line, rather than a
279 configuration file. The best way to deal with this is to create a
280 shell script which runs udptunnel with the right options. This
281 script will live on alice in ~Tbob, and be run by Tbob. Let us call
282 it `udptunnel-invoke-bob'.
283
284 For the most basic setup, it should look something like this:
285
286 #!/bin/sh
287 set -e
288 set -x
289
290 udptunnel \
291 -e nonce -e timestamp/10/30 \
292 -e pkcs5/8 -e blowfish-cbcmac/128 -e blowfish-cbc/128 \
293 <alice-physical-hostname>,Any \
294 <bob-physical-hostname>,Command \
295 <alice-virtual>,<bob-virtual>,1000,cslip \
296 30,130,1800 \
297 <bob-private-nets> <alice-private-nets> \
298 ssh -o 'BatchMode yes' \
299 -v <Talice>@<bob-physical-hostname> \
300 udptunnel
301
302 You have to fill in the right values for things in angle brackets.
303 (See also section 6. for a moderately complex example, below.)
304
305 4.4.1. Syntax of <alice-private-nets> and <bob-private-nets>
306
307 These arguments to udptunnel are the network address ranges at each
308 end which are to be connected via the tunnel. Let us consider just
309 <alice-private-nets>; <bob-private-nets> is just the same, but for
310 bob's end.
311
312 <alice-private-nets> is a comma-separated list of networks specified
313 as <network>/<prefix-len>. The network address must be numerical,
314 and the prefix length must always be specified.
315
316 If there are no private networks `behind' alice, ie the tunnel is
317 just to connect alice to bob and things at bob's end, then specify
318 `-' for <alice-private-nets>.
319
320 4.4.2. IP masquerading (NAT) at alice's end
321
322 If alice is behind a masquerading (NAT) firewall, you can still get
323 it to work. You need to add an option `-m' before the other
324 arguments. This will make udptunnel on alice tell udptunnel on bob
325 to wait for alice's first encapsulated packet before deciding what
326 alice's physcial address and port number are, as seen by bob. That
327 way alice doesn't need to know what port number the NAT proxy will
328 use.
329
330 4.4.3. Using fixed UDP port numbers (eg to make firewally happy)
331
332 If alice is behind a firewall which will not allow incoming UDP to
333 arbitrary ports, even when sent in reply to packets of alice's, you
334 have to arrange for alice to use a fixed port number. Change
335 <alice-physical-hostname>,Any \
336 to
337 <alice-physical-hostname>,<alice-physical-port> \
338
339 udptunnel will need to be able to bind to the relevant port, so you
340 must either (i) choose a port number over 1024, which risks other
341 processes on alice accidentally using that port, (ii) run udptunnel
342 as root on alice, or (iii) use authbind (authbind is a utility,
343 included in Debian, which can allow non-root programs to bind to low
344 ports in a controlled way).
345
346 If bob is behind such a firewall too, you can replace
347 <bob-physical-hostname>,Command \
348 with
349 <bob-physical-hostname>,<bob-physical-port> \
350
351 4.4.4. Clock skew and excessive delay
352
353 The default configuration given above, which includes this
354 -e nonce -e timestamp/10/30 \
355 will not work if there is more than 10s of clock skew between alice
356 and bob's system clocks, or if the lag in either direction is more
357 than 30s. It is best if your systems run with synchronised clocks
358 (you can run NTP over the tunnel if necessary) and don't have such
359 bad lag, of course.
360
361 However, you can increase these parameters if you really want. To
362 increase the tolerance to clock skew to some amount, make sure that
363 both numbers are at least the amount of clock skew you're willing to
364 tolerate. To increase the tolerance to delay it's only necessary to
365 increase the second number.
366
367 Warning: if you increase these numbers too much there is a risk that
368 packets delayed or repeated by an attacker will be treated as genuine
369 and cause communication or security problems. I would not recommend
370 using a value more than 120 (2 minutes).
371
372 If you really can't get reasonable clock synch at all, you can use
373 sequence number replay detection instead of clock-based replay
374 detection. Replace
375 -e nonce -e timestamp/10/30 \
376 with
377 -e sequence \
378
379 4.4.5. Other things to tweak (it's usually safe to ignore this part)
380
381 Do not mess with the `-e' parameters and arguments except as
382 explained above, unless you are a cryptographer.
383
384 30,130,1800 are timeouts which control the `dead tunnel detection'.
385 The first is the keepalive interval: when one end hasn't sent
386 anything for that many seconds, it will send an empty keepalive
387 packet. The second is the dead tunnel timeout: when one end hasn't
388 received anything for that many seconds, it assumes the tunnel is
389 dead and dies (the other end will then usually die shortly if it
390 hasn't already). The third is the status reporting interval - at
391 intervals of that many seconds each end will report (to udptunnel's
392 stdout) that the tunnel is still open and give some statistics; these
393 diagnostics also prevent the controlling ssh connection's entry in
394 masquerading and firewall tables from timing out.
395
396 1000 (in ...,...,1000,cslip) is the MTU - the maximum size of packet
397 which will be sent through the tunnel. It is best if this number is
398 a certain amount smaller than the path MTU over the physical network,
399 so that encapsulated packets do not get fragmented. (Each packet
400 will be increased in size by 24 bytes + the size of a UDP and IP
401 header + the effects of SLIP duplication of certain bytes.)
402
403 4.5. Testing your script
404
405 After you've written your script, you should run it to see if it
406 works. See section 5 for details.
407
408 4.6. Configure the tunnel to run automatically
409
410 Now that the tunnel works if you invoke it by hand, it is time to
411 arrange to run it automatically.
412
413 If you want the tunnel to run over a dialup link only when the dialup
414 link is up, then I'm afraid you'll have to arrange to start and kill
415 it yourself, probably. I haven't set up such a configuration. More
416 information about this for this document, if you manage to do it,
417 would be good.
418
419 So, I shall assume that you want the tunnel to be up all of the time
420 (or at least, as much as possible). The best way to do this is to
421 run it from `init', by setting it up in inittab.
422
423 For example, you could put something like this in your inittab:
424 t0:23:respawn:su Tbob -c ./udptunnel-invoke-bob 2>&1 | logger -p local2.info -t tunnel-bob
425 (Note that if you have more than one tunnel the `id' field, at the
426 start of the inittab line, must be different for each one.)
427
428 This would use `su' to become bob and run the actual tunnelling
429 software, and arrange for the diagnostic output to be sent to syslog
430 with facility `local2' and priority `info', tagged with `tunnel-bob'.
431 With an appropriate line in /etc/syslog.conf, such as
432 local2.* /var/log/local2-all.log
433 (remember that you have to use tabs in syslog.conf) this will
434 produce, in /var/log/local2-all.log, all the diagnostics, including
435 reassuring messages like this:
436 Sep 18 00:27:48 alice tunnel-bob: udptunnel-forwarder: alice: tunnel still open: received 5262 packets, 5262 bytes
437 Sep 18 00:28:44 alice tunnel-bob: udptunnel-forwarder: bob: tunnel still open: received 5280 packets, 5280 bytes
438
439
440 5. TESTING YOUR UDPTUNNEL INVOCATION SCRIPT
441
442 5.1. Invocation
443
444 Log into alice as Tbob, and run ./udptunnel-invoke-bob.
445 A great deal of diagnostic output will ensue.
446
447 If all is well you will see two messages looking something like this
448 udptunnel-forwarder: bob: tunnel open with peer 127.0.0.3:76543
449 udptunnel-forwarder: alice: tunnel open
450 and the session will just sit there. This means it thinks it's
451 working; go on to section 5.2.
452
453 If it didn't say that, here are some debugging tips:
454
455 * If it just sits there for a minute or two and then udptunnel times
456 out, the physical packets aren't getting back and forth. Use
457 tcpdump, check your firewall and routing (as below), and consult the
458 sections above about NAT and firewalls.
459
460 * If it bombed out, look for an error message in the diagnostics.
461 There will be lots of `subprocess somethingorother exited with
462 nonzero exit status 47', `no details received from remote' and the
463 like, but these are probably not the ones you want to look at,
464 because they're usually just consequences of some other failure.
465
466 Permission denied.
467 udptunnel - alice: fatal error: remote command failed (code ...)
468 Tbob had trouble ssh'ing to Talice@bob. Check that the ssh
469 configuration is set up, and test it separately.
470
471 userv-ipif service: access denied for ...., ....
472 udptunnel - alice: subprocess local command failed with code 2048
473 The arguments to udptunnel don't correspond to
474 /etc/userv/ipif-networks on alice. Either the arguments to
475 udptunnel or the ipif-networks file is wrong. (Or, if the message
476 about `local command failed' mentions bob, look on bob.)
477
478 udptunnel - alice: subprocess forwarder failed with code 14
479 The tunnel timed out - no packets were successfully received for
480 130 seconds. See 2.4.5 above for details of the timeout
481 parameters. (NB, applies to `code 14' only.)
482
483 usage errors from udptunnel or ssh, or sh: ...: unknown command
484 Perhaps you dropped a \ from the udptunnel-invoke-bob script ?
485
486 udptunnel not found, udptunnel-forwarder not found
487 Check that the PATH includes /usr/local/bin. Noninteractive `ssh'
488 invocations (ie, ones with a command specified) often have a
489 different PATH.
490
491 slattach cannot open /dev/2 (or similar messages)
492 Your slattach is buggy. See under `slattach problem' in the build
493 and installation instructions, above.
494
495 slattach cannot change line discipline (or some other weird message)
496 Check whether your kernel is compiled with SLIP and/or CSLIP
497 support.
498
499 * Other messages:
500
501 udptunnel-forwarder: alice: bad packet: blowfish-cbcmac: verify failed
502 This can be caused by actual packet corruption on the physical
503 network (or even by an actual hostile attack), but when using
504 fixed port numbers these messages are common after the tunnel has
505 died and been restarted: they correspond to packets from the
506 previous invocation (which is usung different keys) being rejected
507 because their checksums don't match. In this case they should go
508 away in a minute or two.
509
510 5.2. Testing, once the tunnel claims to be working
511
512 In another session on alice, you should be able to ping bob's virtual
513 interface. If this works, test pinging between hosts on the private
514 networks behind alice and bob. If all is well, go onto step 4.
515
516 If not, here are some troubleshooting hints:
517
518 * Use numerical addresses when testing. This eliminates DNS problems
519 from your test strategy.
520
521 * Use `ifconfig' and `route -n' on alice and bob to check that the
522 interfaces and routes all look right. The tunnel will show up as a
523 `sl<n>' for some <n>.
524
525 * Use `tcpdump -n -i <interface>' to watch the traffic go across some
526 interface, to try to figure out where the traffic is going. Look
527 both for the private traffic before it goes into the tunnel, and the
528 physical traffic, to try to find out where it disappears. The
529 diagnostics will tell you which physical ports it's using, something
530 like this:
531 udptunnel - alice: debug: using remote Wait,Wait local 131.111.232.108,1422
532 udptunnel - bob: debug: using remote 131.111.232.108,1422 local 195.224.38.6,2413
533
534 * alice and bob can see each other but the private networks can't ?
535 Make sure alice and bob both have IP forwarding enabled.
536
537 * Check your firewalls, if you have them. It's most helpful if your
538 firewall configuration arranges to log rejected packets - without
539 that, they can be a complete pain to debug.
540
541
542 6. DNS, firewall, mail, etc.
543
544 When you have IP level connectivity between your two networks, you
545 must also arrange for:
546
547 * An appropriate firewall on each tunnel endpoint (to stop attacks
548 from one network to another) and also at all the borders of each
549 network (to stop traffic that is going to, or looks like it came
550 from, the private networks).
551
552 * DNS configuration so that hosts on both sides of the tunnel can see
553 each other's names, addresses and other information.
554
555 * Mail, news and other application protocols may need to be
556 configured to use the private tunnel connectivity, rather than
557 treating the other private network's names as being `elsewhere' and
558 using unencrypted connectivity via the global Internet.
559
560 How to do these things is beyond the scope of this document.
561
562
563 7. Example
564
565 This example is the tunnel between chiark and Relativity. I'll quote
566 it and explain the details, below. See also the comment at the top of
567 udptunnel.
568
569 authbind udptunnel \
570 -m \
571 -e nonce -e timestamp/10/30 -e pkcs5/8 \
572 -e blowfish-cbcmac/128 -e blowfish-cbc/128 \
573 davenant-external,410 \
574 chiark-public,Command \
575 172.31.80.6,172.31.80.9,1000,cslip \
576 30,120,1800 \
577 - 172.18.45.0/24 \
578 ssh -o 'ForwardAgent no' -o 'ForwardX11 no' \
579 -o 'BatchMode yes' \
580 -i ~ian/.ssh/identity -l ian \
581 -v chiark.greenend.org.uk \
582 udptunnel
583
584 Because at Relativity the tunnel endpoint has to not be our firewall,
585 because the firewall is a 386SX/16 and so not powerful enough,
586 Relativity practically has to be the active partner in any tunnels it
587 is involved in. This also necessitates the use of the `-m' option and
588 various other things.
589
590 Exposition of the example udptunnel invocation:
591
592 > authbind udptunnel \
593
594 `authbind' is used because at Relativity the tunnel endpoint address
595 has to be on a fixed port because our tunnel endpoint is not on the
596 firewall system (if it's not on a fixed port we can't write a good
597 firewall rule to let it through).
598
599 The port we are using is port 410, a low port to prevent other
600 processes `stealing' it, so root privilege or authbind is needed.
601
602 > -m \
603
604 -m tells this invocation of udptunnel that its endpoint address and
605 port (for encapsulated packets) are going to be NATted before the far
606 end sees them. The effect is that instead of supplying this
607 information to the far end, the far end is told to `wait and see'.
608
609 This should not usually be used in other circumstances. (For full
610 details see the comment at the top of udptunnel.)
611
612 > -e nonce -e timestamp/10/30 -e pkcs5/8 \
613 > -e blowfish-cbcmac/128 -e blowfish-cbc/128 \
614
615 This is the crypto configuration.
616
617 > davenant-external,410 \
618
619 This is the local physical address and port. davenant is the tunnel
620 endpoint, and davenant-external is its public address (we run two
621 networks on the wire at Relativity, an internal one and a public
622 one).
623
624 > chiark-public,Command \
625
626 This is the physical remote address and port. `Command' means find
627 out the remote physical address or port by having udptunnel at the
628 far end print its address and port when they have been allocated.
629
630 Another possibility here is to use a fixed remote port number.
631
632 The DNS at GR is configured so that just `chiark' means chiark via
633 the tunnel, so we have to use chiark-public which means its public
634 IP address.
635
636 > 172.31.80.6,172.31.80.9,1000,cslip \
637
638 172.31.80.6 is davenant's virtual address.
639 172.31.80.9 is chiark's virtual address for the Relativity tunnel.
640
641 > 30,130,1800 \
642
643 These are the timing parameters.
644
645 > - 172.18.45.0/24 \
646
647 No remote virtual networks are reachable via chiark. 172.18.45.0/24
648 is the Relativity house ethernet, which is to be reachable via the
649 tunnel from chiark.
650
651 > ssh -o 'ForwardAgent no' -o 'ForwardX11 no' \
652 > -o 'BatchMode yes' \
653 > -i ~ian/.ssh/identity -l ian \
654 > -v chiark.greenend.org.uk \
655 > udptunnel
656
657 This is the ssh invocation to run udptunnel at the far end.
658
659 At Relativity we put the udptunnel invocation in a file and run it
660 out of inittab, like this:
661
662 t0:235:respawn:/usr/local/sbin/really -u ian /usr/local/sbin/udptunnel-invoke 2>&1 | logger -p local2.info -t tunnel-chiark
663
664
665 8. Copyright notice
666
667 Copyright (C) 1999-2000 Ian Jackson
668
669 This is free software; you can redistribute it and/or modify it
670 under the terms of the GNU General Public License as published by
671 the Free Software Foundation; either version 2 of the License, or
672 (at your option) any later version.
673
674 This program is distributed in the hope that it will be useful, but
675 WITHOUT ANY WARRANTY; without even the implied warranty of
676 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
677 General Public License for more details.
678
679 You should have received a copy of the GNU General Public License
680 along with userv-utils; if not, write to the Free Software
681 Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
682
683
684 $Id$