share/examples/ppp/ppp.conf.span-isp

   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
 106 default:
 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
 117 isp1:
 118   set phone "1234567"
 119   set authname "isp1name"
 120   set authkey "isp1key"
 121   add! RIP1/32 HISADDR
 122
 123 isp2:
 124   set phone "2345678"
 125   set authname "isp2name"
 126   set authkey "isp2key"
 127   add! RIP2/32 HISADDR
 128
 129 ispN:
 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
 143 vpn:
 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
 155 vpn1:
 156   rename 1
 157   set device RIP1:ppp/udp
 158
 159 vpn2:
 160   rename 2
 161   set device RIP2:ppp/udp
 162
 163 vpnN:
 164   rename N
 165   set device RIPN:ppp/udp
 166
 167 vpn-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
 188 vpn-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