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