From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6A5DB21F416 for ; Thu, 2 Oct 2014 21:09:09 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id m8so290258obr.7 for ; Thu, 02 Oct 2014 21:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nJFhU4gMl6JqN3E78G72gi1/syOW2qaa334PzphlpuE=; b=z+Yb8VZ/lmSRbWHCiVmePe1i9suP3lvzGzUf9SnKLb/oBpTF/GdNa0HNumetDHe/no sifjDj0QZSAjJbAEeWHHIlFtNR5dnSMPS9lmK2dfwfJ+nU+o8HloVJB9RERO4w6lItyH cmleT1NZwlYdQqKjFp6R3h/CYAkEwlmIBjSTuxHbu2vuc0txoch/MD4OTvPrmr4Lkf7C XaHaYBTfgp6tbapN63AS1xMTw6++vwdPUITfblyByU5VvjbWKHaBiEp//6jX3ZephFkk BVWb9feTS/AY/A9ZNAdhGq3hCSaVEMf0ngW+AmHYrY1T7jPYEkbt3a9NlbETtwW0R0y8 tk9Q== MIME-Version: 1.0 X-Received: by 10.182.87.102 with SMTP id w6mr3455277obz.35.1412309349217; Thu, 02 Oct 2014 21:09:09 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Thu, 2 Oct 2014 21:09:09 -0700 (PDT) In-Reply-To: References: <542DFCCA.7080708@eggo.org> <542E1267.1000208@eggo.org> Date: Thu, 2 Oct 2014 21:09:09 -0700 Message-ID: From: Dave Taht To: "Eric S. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= , cerowrt-devel Subject: Re: [Cerowrt-devel] vpn fw question X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 04:09:38 -0000 hmm. bcp38 postdates the last work I tried with openvpn. In your case you will want to either add to /etc/config/bcp38 list nomatch '10.43.0.0/20' list nomatch '10.42.66.0/24' list nomatch '10.199.188.0/24' or (better) insert and remove them from the ipset list dynamically when the vpn starts/stops. Or kill bcp38 entirely for a while while you debug. On Thu, Oct 2, 2014 at 8:38 PM, Dave Taht wrote: > On Thu, Oct 2, 2014 at 8:05 PM, Eric S. Johansson wrote: >> >> On 10/2/2014 10:24 PM, Joel Wir=C4=81mu Pauling wrote: >>> >>> I.e Your topology looks like this : >>> >>> [(Remote LAN) - VPN Client]---[INTERNET]---(Local >>> LAN)[WAN][LAN][REMOTE-LAN]) >>> >>> Your Local LAN knows nothing about Remote LAN and Vice versa. There is >>> just a single Inteface/Client member that is a member of REMOTE-LAN. >>> So to get traffic from Local LAN to Remote LAN all Local-LAN traffic >>> needs to be masqueraded to that Single interface. >> >> >> ah, thanks for the clarification. my function oriented topology looks l= ike >> this: >> >> [ 34-38 target lan - vpn server - fw ] - - - [ I ] - + -( fw - vpn clien= t - >> - - lan - - - workerbees(6) ) >> + -( rw worker bee ) >> + -( rw worker bee ) >> + -( cerowrt worker bee ) ... >> >> I don't think the natted form is going to work terribly well because all= the >> WB's need access to all the target machines. Also our routing tables are= =E2=80=A6 >> significant > > Personally I find the output of > > ip route show > > to be much more readable and usable nowadays. > >> Kernel IP routing table >> Destination Gateway Genmask Flags MSS Window irtt >> Iface >> 0.0.0.0 73.38.246.1 0.0.0.0 UG 0 0 0 >> ge00 >> 10.42.66.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.1.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.2.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.3.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.4.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.5.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.6.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.7.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.8.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.9.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.10.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.11.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.12.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.13.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.14.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.43.15.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 > > Ideally you should be able to shrink that 10.43 network into a single > 10.43.0.0/20 route. > >> 10.199.188.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> 10.199.188.193 0.0.0.0 255.255.255.255 UH 0 0 0 >> tun0 >> 73.38.246.0 0.0.0.0 255.255.254.0 U 0 0 0 >> ge00 >> 172.30.42.0 0.0.0.0 255.255.255.224 U 0 0 0 >> se00 >> 172.30.42.0 0.0.0.0 255.255.255.0 ! 0 0 0= * >> 172.30.42.64 0.0.0.0 255.255.255.224 U 0 0 0 >> sw00 >> 172.30.42.96 0.0.0.0 255.255.255.224 U 0 0 0 >> sw10 >> 192.168.9.0 10.199.188.193 255.255.255.0 UG 0 0 0 >> tun0 >> >> and WTH is this? >> 172.30.42.0 0.0.0.0 255.255.255.0 ! 0 0 0= * > > That is what is called a "covering route". The interfaces in cerowrt are > all /27s out of a single /24. Just as you could just do a 10.43.0.0/20 ro= ute > instead of the 16 10.43 routes above. > > So we export via babel that single /24 by creating an "unreachable" route > for it, which is visible externally to the router, and internally to the = router > we have the /27s that override the /24, that are not visible outside the > router. > > Clear as mud, right? > > Here is part of my route table. Old Cerowrt used to export 9 routes > visible to other routers.. > > 172.21.0.0/27 dev ge00 proto kernel scope link src 172.21.0.18 > 172.21.0.64/27 via 172.21.0.1 dev ge00 proto babel onlink > 172.21.0.96/27 via 172.21.0.1 dev ge00 proto babel onlink > 172.21.0.128/27 via 172.21.0.1 dev ge00 proto babel onlink > ... add the host gateway and the other 4 interfaces... > > Toronto exports 1 (or 2) depending on the alternate paths available > > The s+ and gw+ devices > > 172.21.18.0/24 via 172.21.0.7 dev ge00 proto babel onlink > > The ge00 device is on another network, covered in this route > > 172.21.3.0/24 via 172.21.0.7 dev ge00 proto babel onlink > > > less exported routes =3D smaller routing packets, smaller routing > tables, faster routing updates, less route lookups while transferring > data, and better use of the distance->vector mechanisms, and so on. > > In terms of scaling factors this makes it feasible to route together > at least 700 boxes without > too much fear of overwhelming anything. (But I haven't got around to > resimulating the results, > like so many other things - and the limit at least used to be some > inefficient code in babeld, > not any inherent limit to the protocol) > >> >> --- eric >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > > -- > Dave T=C3=A4ht > > https://www.bufferbloat.net/projects/make-wifi-fast --=20 Dave T=C3=A4ht https://www.bufferbloat.net/projects/make-wifi-fast