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