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

   1 # $FreeBSD$
   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
 105 default:
 106   set speed 115200
 107   set device /dev/cuad0 /dev/cuad1 /dev/cuad2 /dev/cuad3
 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 echo
 114   set lqrperiod 15
 115
 116 isp1:
 117   set phone "1234567"
 118   set authname "isp1name"
 119   set authkey "isp1key"
 120   add! RIP1/32 HISADDR
 121
 122 isp2:
 123   set phone "2345678"
 124   set authname "isp2name"
 125   set authkey "isp2key"
 126   add! RIP2/32 HISADDR
 127
 128 ispN:
 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
 142 vpn:
 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
 154 vpn1:
 155   rename 1
 156   set device RIP1:ppp/udp
 157
 158 vpn2:
 159   rename 2
 160   set device RIP2:ppp/udp
 161
 162 vpnN:
 163   rename N
 164   set device RIPN:ppp/udp
 165
 166 vpn-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
 187 vpn-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