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 $
4 # This advanced ppp configuration file explains how to implement
7 # ------------- ------------- -------------
8 # | host1 | | host2 | | host3 |
9 # ------------- ------------- -------------
11 # |---------------------- LAN ----------------------|
17 # -----------------------------------
21 # -----------------------------------
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.
33 # There is a working example in ppp.*.span-isp.working that can be tested
34 # on a single machine !
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
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).
51 # o Both the Gateway and the Receiver machines must have several tun
52 # interfaces configured into the kernel (see below).
54 # o Both the Gateway and the Receiver machines must have the following
55 # entry in /etc/services:
59 # The port number isn't important, but it must be consistent across
62 # o The Receiver machine must have the following entry in
65 # ppp dgram udp wait root /usr/sbin/ppp ppp -direct vpn-in
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
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 !
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.
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.
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.
91 # Using ppp to connect to your ISPs (PPP over UDP over PPP):
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.
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
103 # Only the ISP links should be started manually. When they come up, they'll
104 # start the MP invocation.
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"
119 set authname "isp1name"
120 set authkey "isp1key"
125 set authname "isp2name"
126 set authkey "isp2key"
131 set authname "ispNname"
132 set authkey "ispNkey"
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.
147 set mru 1504 # Room for the MP header
149 set authname "vpnname"
152 disable deflate pred1 lqr
157 set device RIP1:ppp/udp
161 set device RIP2:ppp/udp
165 set device RIPN:ppp/udp
171 link 1 set device RIP1:ppp/udp
172 link 2 set device RIP2:ppp/udp
173 link N set device RIPN:ppp/udp
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.
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.
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''.
192 set mru 1504 # Room for the MP header
195 set ifaddr REAL-LOCAL-IP REAL-ASSIGNED-IP