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