From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (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 1829021F226 for ; Thu, 2 Oct 2014 19:41:22 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so300087lab.2 for ; Thu, 02 Oct 2014 19:41:20 -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=PMPWg9c9kibGbmeVRBizAkSdA1tsaLKomEKw0fw6efs=; b=bQs+rmomHPgfyOouGtTGmuf2GJ50v4m8/MiM44g2SeldGC73SkbD8kyRS1LkUgOeiv 5G05K1R5cf/AkuaJXrUPjMb+dfQ9wceGnwzmW8sXaa0L/Ilak9VQZSnaUBiCDCVPyaIR 6VsiZb/0Yv0LlHR2D4E94smIiS7ryqnqeY5sU= 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=PMPWg9c9kibGbmeVRBizAkSdA1tsaLKomEKw0fw6efs=; b=VDPcPaGibdyLWrTE1j2dxENp9PbgQ5aiRm52Pe3Q7QDc/qGVx7f+e+we6lRWK6GyQX CLFLW4xgGaozV4/kPUjtp78J4bgJtgO4kuOVWO9GYUXKabZ3TJWSm+7YQJG2kK6/iWvC y1Vyw8mU3XXVZZ94pzi2ded6AJUK6HSE27lzD/pSDtNXD4SSWahWKHrt0sQrJs1hD1P1 nTo8dKzEOqMD5VtmglxMUPLIBk5DsJavtXRk2EwmqseIvWaFBcqEIvHNAk43/ftUQ1F7 jbhi9PHH8iV1pLhxmQF0GvDoenyya50MYwIl8suvrz4N7AIfQo5VH+RXO6HKs7Or2UU1 /+vg== X-Gm-Message-State: ALoCoQlsJnaWm1spQ12yUoAwSsh3uor1DpfvZ+fbkuy1EiDHWtvSGsIYDhgmOysp0THBXsdNmc/Z X-Received: by 10.112.202.1 with SMTP id ke1mr2329247lbc.33.1412304080427; Thu, 02 Oct 2014 19:41:20 -0700 (PDT) MIME-Version: 1.0 Sender: aenertia@aenertia.net Received: by 10.25.16.220 with HTTP; Thu, 2 Oct 2014 19:41:00 -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:41:00 +1300 X-Google-Sender-Auth: yQghG3-5Vb_L2zAC4sZnTpOYco0 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:41:51 -0000 Most of the time, they just want to access a remote VPS/Torrent Seedbox or $service from their local network. On 3 October 2014 15:38, Joel Wir=C4=81mu Pauling wrote= : > 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 ope= nvpn >> 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 = seems >>>> to be working. The VPN link comes up, tun0 is created. I can access ma= chines >>>> 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 'gu= est' >>>> >>>> sometimes it says: Warning: Section @zone[1] (lan) cannot resolve devi= ce of >>>> network 'vpn0' >>>> >>>> tcpdump sees the ICMP request at se00 and tun0 but not at the remote t= arget. >>>> this leads me to believe that it's probably a firewall problem but I d= on't >>>> know where the logs are. >>>> >>>> This brings me to one of the problem with had making changes in cerowr= t, >>>> namely, how the $##$& do you debug this thing? I've had to reflash thi= s 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