1
2# This advanced ppp configuration file explains how to implement
3# the following:
4#
5#    -------------       -------------       -------------
6#    |   host1   |       |   host2   |       |   host3   |
7#    -------------       -------------       -------------
8#          |                       |               |
9#     |---------------------- LAN ----------------------|
10#                          |
11#                        -------------
12#                        |  Gateway  |
13#                        -------------
14#                              |
15#             -----------------------------------
16#             |          |           |          |
17#            isp1       isp2       isp3       ispN
18#             |          |           |          |
19#             -----------------------------------
20#                              |
21#                         ------------
22#                         | Receiver |
23#                         ------------
24#                              |
25#                          Internet
26#
27# The connection is implemented so that any ISP connection can go down
28# without loss of connectivity between the LAN and the Internet.  It is
29# of course also possible to shut down any link manually.
30#
31# There is a working example in ppp.*.span-isp.working that can be tested
32# on a single machine !
33#
34#
35# Prerequisites:
36#
37# o The Receiver machine must be in the outside world and must be willing
38#   to accept a multilink ppp connection over UDP, assigning a routable IP
39#   number to the Gateway machine.  This probably means that it must be
40#   a *BSD box as I know of no other ppp implementations that can use UDP
41#   as a transport.
42#
43# o The Receiver machine must be multi-homed with at least N+1 addresses
44#   where N is the maximun number of ISPs that you wish to use
45#   simultaneously.  We assume the IP numbers to be RIP1, RIP2 ... RIPN.
46#   REAL-LOCAL-IP is the real IP number of the Receiver machine (and must
47#   not be the same as any of the RIP* numbers).
48#
49# o Both the Gateway and the Receiver machines must have several tun
50#   interfaces configured into the kernel (see below).
51#
52# o Both the Gateway and the Receiver machines must have the following
53#   entry in /etc/services:
54#
55#      ppp 6671/udp
56#
57#   The port number isn't important, but it must be consistent across
58#   machines.
59#
60# o The Receiver machine must have the following entry in
61#   /etc/inetd.conf:
62#
63#      ppp dgram udp wait root /usr/sbin/ppp ppp -direct vpn-in
64#
65#   Note: Because inetd ``wait''s for ppp to finish, a single ppp
66#         invocation receives all incoming packets.  This creates
67#         havoc with LQR magic number checks, so LQR *must not* be
68#         enabled.
69#         Also, -direct invocations of ppp do sendto()s using the
70#         address that was last recvfrom()d.  This means that the
71#         returning traffic is a bit unbalanced.  Perhaps ppp should
72#         be smart enough to automatically clone an existing link
73#         when it detects a new incoming address.... tricky !
74#
75# If you use ppp to connect to your ISPs, the isp* profiles shold be used,
76# resulting in the vpn* profiles being called from ppp.linkup.span-isp.
77# These invocations will bond together into a MP ppp invocation.
78#
79# If the link to your ISP is via another type of interface (cable modem
80# etc), simply configure the interface with a netmask of 0xffffffff and
81# add a route to RIPN via the interface address (no default).  You can
82# then start ppp using the vpn-nic label.
83#
84# The Receiver machine should have N tun interfaces (where N is the maximum
85# number of ISPs that you wish to use simultaneously).  The Gateway machine
86# requires N interfaces plus an additional N interfaces (total 2 * N) if
87# you're using ppp to talk to the ISPs.
88
89# Using ppp to connect to your ISPs (PPP over UDP over PPP):
90#
91# When we connect to our ISPs using ppp, we start the MP ppp invocation
92# from ppp.linkup (see ppp.linkup.span-isp) for each link.  We also remove
93# the link from ppp.linkdown (see ppp.linkdown.span-isp).  This is necessary
94# because relying on our LQR strategy (dropping the link after 5 missing
95# replies) is just too slow to be practical in this environment.
96#
97# This works because the MP invocations are smart enough to recognise that
98# another process is already running and to pass the link over to that
99# running version.
100#
101# Only the ISP links should be started manually.  When they come up, they'll
102# start the MP invocation.
103
104default:
105  set speed 115200
106  set device /dev/cuau0 /dev/cuau1 /dev/cuau2 /dev/cuau3
107  set dial "ABORT BUSY ABORT NO\\sCARRIER ABORT NO\\sDIAL\\sTONE TIMEOUT 4 \
108            \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
109  set login
110  set redial 3 5
111  set timeout 0
112  enable lqr echo
113  set lqrperiod 15
114
115isp1:
116  set phone "1234567"
117  set authname "isp1name"
118  set authkey "isp1key"
119  add! RIP1/32 HISADDR
120
121isp2:
122  set phone "2345678"
123  set authname "isp2name"
124  set authkey "isp2key"
125  add! RIP2/32 HISADDR
126
127ispN:
128  set phone "3456789"
129  set authname "ispNname"
130  set authkey "ispNkey"
131  add! RIPN/32 HISADDR
132
133
134# Our MP version of ppp.  vpn is a generic label used by each of the
135# other vpn invocations by envoking ppp with both labels (see
136# ppp.linkup.span-isp).
137# Each ``set device'' command tells ppp to use UDP packets destined for
138# the given IP/port as the link (transport).  The routing table will
139# ensure that these UDP packets use the correct ISP connection.
140
141vpn:
142  set enddisc LABEL
143  set speed sync
144  set mrru 1500
145  set mru 1504			# Room for the MP header
146  nat enable yes
147  set authname "vpnname"
148  set authkey "vpnkey"
149  add! default HISADDR
150  disable deflate pred1 lqr
151  deny deflate pred1
152
153vpn1:
154  rename 1
155  set device RIP1:ppp/udp
156
157vpn2:
158  rename 2
159  set device RIP2:ppp/udp
160
161vpnN:
162  rename N
163  set device RIPN:ppp/udp
164
165vpn-nic:
166  load vpn
167  clone 1 2 N
168  link deflink rm
169  link 1 set device RIP1:ppp/udp
170  link 2 set device RIP2:ppp/udp
171  link N set device RIPN:ppp/udp
172
173# The Receiver profile is a bit more straight forward, as it doesn't need
174# to get bogged down with sublinks.  Replace REAL-ASSIGNED-IP with the
175# IP number to be assigned to the Gateway machine.  Replace REAL-LOCAL-IP
176# with the real IP number of the Receiver machine.
177#
178# No other entries are required on the Receiver machine, and this entry
179# is not required on the Gateway machine.  The Receiver machine also
180# requires the contents of ppp.secret.span-isp.
181#
182# Of course it's simple to assign an IP block to the client with a simple
183# ``add'' command, and then have the client use those IP numbers on its
184# LAN rather than using ``nat enable yes''.
185
186vpn-in:
187  set enddisc label
188  set speed sync
189  set mrru 1500
190  set mru 1504			# Room for the MP header
191  enable chap
192  disable lqr
193  set ifaddr REAL-LOCAL-IP REAL-ASSIGNED-IP
194