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