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