From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 A49DC21F1DD for ; Thu, 2 Oct 2014 19:38:44 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id f15so286034lbj.11 for ; Thu, 02 Oct 2014 19:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aenertia.net; s=dkimaenertianet; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=4tsHPGtOzpS8b5XaSi52NXTf0+++yumDKOkhUx//jm4=; b=CFPJtEhyLvK6X+QHjcxRA/4AQVOR2/z2L9DEhrAaHsZ+5yDoZqQaP/uK6jFHENXBEF RAli28AZWuiSUviSCeKSCLVKQnk6Iwbbr4Sa8FdIvQmg37QGJKDpJqQ/MP1f7a3ThDM6 wARc82AQBXxejyPy5mSzDIjAXw3V6yC1GV3EQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=4tsHPGtOzpS8b5XaSi52NXTf0+++yumDKOkhUx//jm4=; b=kW9ryS3nl5d3xuSpv1Pi+2ynFvyoRwtb7vEeEziqKqyNrHo/no66j71Cw6uGF1ZY8f yzS6F6hr0SZ5bZMfXG3KqkPWUdzh/nGmV0FRQkoK1NTwSoSH/AFRhl3f6DDAaFJcZy6Y Qem/kVxGJNyOP6PONn6ucWbf3UAeMmFw4+f1OC5LW+xh0MG/kuoOEZrs8LC7CGVhw63N q0UeJiWzwrfQCr8JHhA7jdAsOMdM+A4dbPCMtNKi8kGTfLh9c6vFdpI/NbUd8atqtDIc PmIPHSIBUflxGmbk6/mfWGEnZeJwtKL5smaWM9InC0uBJQkVF6ujQgUGY6o6jFyarNKe Mk+A== X-Gm-Message-State: ALoCoQnvkpy1T6rSaaIZOHoK+mwxhb1xb4jDao4MJROJSfESAivlMxK55+bTbO7NbRXDfx5VYJSK X-Received: by 10.112.13.10 with SMTP id d10mr2515720lbc.10.1412303921766; Thu, 02 Oct 2014 19:38:41 -0700 (PDT) MIME-Version: 1.0 Sender: aenertia@aenertia.net Received: by 10.25.16.220 with HTTP; Thu, 2 Oct 2014 19:38:21 -0700 (PDT) In-Reply-To: References: <542DFCCA.7080708@eggo.org> From: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= Date: Fri, 3 Oct 2014 15:38:21 +1300 X-Google-Sender-Auth: lzWcBuwaK6QR_mjz-YDPkwIiHzM Message-ID: To: Dave Taht Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 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 02:39:13 -0000 Yup - Routing is going to be better on performance. But is definately the more advanced/less common use case from my experience helping users do this. What I've got there tends to be what most users who ask this question are actually after. On 3 October 2014 15:36, Dave Taht wrote: > On Thu, Oct 2, 2014 at 7: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. > > I'm not sure this is actually the case. What I used to do (not using open= vpn > currently, took it down during heartbleed) was push out and pull in a > route or set of routes. > > 'course that requires a routing protocol on the other end... > >> >> >> -Joel >> >> >> >> On 3 October 2014 14:32, Eric S. Johansson wrote: >>> I was trying to setup my cerowrt box as an openvpn client. everything s= eems >>> to be working. The VPN link comes up, tun0 is created. I can access mac= hines >>> on the far end of the link from the AP and vice versa. the openwrt >>> incantation for the vpn says to create an interface called vpn0 >>> >>> network.vpn0=3Dinterface >>> network.vpn0.proto=3Dnone >>> network.vpn0.ifname=3Dtun0 >>> >>> ifconfig says tun0 exists but no vpn0. fw3 reload says: >>> >>> Warning: Section @zone[1] (lan) cannot resolve device of network 'lan' >>> Warning: Section @zone[2] (guest) cannot resolve device of network 'gue= st' >>> >>> sometimes it says: Warning: Section @zone[1] (lan) cannot resolve devic= e of >>> network 'vpn0' >>> >>> tcpdump sees the ICMP request at se00 and tun0 but not at the remote ta= rget. >>> this leads me to believe that it's probably a firewall problem but I do= n't >>> know where the logs are. >>> >>> This brings me to one of the problem with had making changes in cerowrt= , >>> namely, how the $##$& do you debug this thing? I've had to reflash this= box >>> way too many times because I did something that effectively bricked it. >>> right now, I would settle for knowing where to find where logs are put. >>> >>> thanks >>> --- eric >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Cerowrt-devel mailing list >>> Cerowrt-devel@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> _______________________________________________ >> 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