Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: "J. Daniel Ashton" <jdashton@ashtonfam.org>
Cc: "cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] saner defaults for config/firewall
Date: Mon, 24 Feb 2014 11:24:49 -0500	[thread overview]
Message-ID: <CAA93jw6rHU63RaJXyd-waFQ8epWOxTLFukmXoh=ti_uB4j+n0Q@mail.gmail.com> (raw)
In-Reply-To: <530A4791.8080903@ashtonfam.org>

On Sun, Feb 23, 2014 at 2:10 PM, J. Daniel Ashton
<jdashton@ashtonfam.org> wrote:
>
>
> While you're looking at things that ought to be in the default configuration
> (or in "a" default configuration, perhaps available on the wiki), there are
> two use-cases that I would like to see work better out of the box:
>
> mDNS sharing across non-guest segments: my wife on Wi-Fi, I on Ethernet,
> should be able to see each other's iTunes libraries and the mDNS-advertised
> printer.
> Google's new Chromecast device useable from all non-guest segments: it has
> no Ethernet port, so it is on Wi-Fi at 2Mhz, my table on Wi-Fi at 5Mhz, and
> my desktop on Ethernet. Both tablet and desktop should be able to see the
> Chromecast and control it.
>
> I really like the CeroWrt approach to network segmentation: I felt like I
> was learning best practices as I read up on what you chose to do. But the
> above use cases seem to be problematic with this approach.

It was a fortuitous historical accident. We needed to be able to look
at 2.4ghz, 5ghz
and ethernet traffic separately, so we broke apart the bridging
everybody else does.

Just to be able to do tcpdumps and see what the heck was going on....

Solutions to a lot of problems fell out. Multicast became less of a
problem in particular,
we were able to see clearly a bunch of wireless g vs n behaviors,
wireless worked
better in general, we were able to debug different aspects of
different radios, etc.

and see the effects of double nat and of bridging multiple broadcast
domains together
even on a small scale in the home...

And (Sigh) the existing problems that bridging everything had worked
around became more acute and interesting.

We ended up giving some fresh love to routing protocols, coming up with
schemes to distribute and route ipv6 prefixes instead of bridging them,
and finding the most annoying "features" of others like mdns and ssdp and upnp.

In terms of fixing mdns, there is a new set of RFCs and work going on to make
it work better over routed networks. A whole ietf wg, actually. Some drafts:

http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01
http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00

(fixing mdns is certainly important in larger networks, the core
requests are coming
 from colleges)

As for the chromecast I don't know how it presently announces its services,
but if it's mdns, the above stuff will fix it I hope. Eventually.

Some code for this now exists, but it's pretty raw...

>
>
>
> On 2/23/14, 12:21 PM, Dave Taht wrote:
>
> On Fri, Feb 21, 2014 at 12:25:23AM +0100, Vincent Frentzel wrote:
>
> Hi everyone,
>
> After installing ceroWRT the first thing I did was to reconfigure the
> firewall as shown attached. My router is used as home gateway and I wanted
> to lock down the device a bit.
>
> The changes are introduced are as follow:
>
> - LAN (s+) to/from GUEST (g+) is not allowed.
> - GUEST to ROUTER is restricted to DNS/DHCP/NTP.
>
> I note that even dns is a problem in terms of leaking information about
> your network, so is mdns.
>
> the "g+" convention can simplify access to the internet in the rules too.
>
> There are also potential problems in enabling the polipo proxy.
>
> Note that the mesh networking interfaces are also "g", and there is
> something of a conflict between allowing the mesh network and guest
> access.
>
> I used to solve this somewhat with the babel authentication extensions.
>
> http://tools.ietf.org/id/draft-ovsienko-babel-hmac-authentication-06.html
>
> at the moment that code had landed in the quagga branch of babel,
> not babel itself.
>
> - I've tuned the basic IPV6 rules to take the above changes into account
> and allow proto 41 INPUT for 6to/in4 tunnels.
> - LAN to/from ROUTER everything is allowed.
>
> This could be a nice default config.
>
> Feedback welcome.
>
> After getting the last release out I took a break from email, and didn't
> get to this.
>
> There are certainly conflicting desires for how to do firewalling.
> Historically
> we run fairly open by default due to cerowrt's origin as a research project.
>
> In the case where we want to open the network somewhat to house guests,
> being
> able to have reasonably secure (ssh and printing) protocols open to them
> is a help.
>
> In the case where I want to share my network with the neighborhood,
> locking things down as per the above makes more sense. I'd argue for even
> stronger measures, actually, something that an org like openwireless.org
> could recomend so that people can feel safe in sharing their wifi again.
>
> I think we should put up alternet configs like this somewhere on the wiki,
> or in a git tree...
>
> I have a few other desirable configs on the list.
>
> -1) gui support for the + syntax would be good.
>
> 0) I really, really, really want bcp38 support, using ipset. I wouldn't
>    mind a complete switch to ipset for a variety of things, but some
>    benchmarking along the way would be good to compare the existing schemes
>
>    one problem I've run into in turning on bcp38 by default is dealing
>    with double nat on the dhcp'd interfaces.
>
> 1) a more "normal", bridged implementation more like people are used to.
>
> 2) vlan support (I've never managed to make vlans work with babel, btw)
>
> 3) ?
>
> _______________________________________________
> 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
>
>
> --
> Daniel Ashton      PGP key available     http://Daniel.AshtonFam.org
> mailto:Daniel@AshtonFam.org           http://ChamberMusicWeekend.org
>  AIM: FirstFiddl           ICQ# 9445142           http://MDMusic.org
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

  parent reply	other threads:[~2014-02-24 16:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-20 23:25 Vincent Frentzel
2014-02-23 17:21 ` Dave Taht
2014-02-23 19:10   ` J. Daniel Ashton
2014-02-24  8:07     ` Vincent Frentzel
2014-02-24  9:29       ` Sebastian Moeller
2014-02-24 10:05         ` Vincent Frentzel
2014-02-24 10:18           ` Fred Stratton
2014-02-24 11:03             ` Fred Stratton
2014-02-24 11:35               ` Vincent Frentzel
2014-02-24 12:45                 ` Fred Stratton
2014-02-24 12:54                   ` Robert Bradley
2014-02-24 13:05                     ` Vincent Frentzel
2014-02-24 13:48                       ` Robert Bradley
2014-02-24 13:35                 ` Sebastian Moeller
2014-02-24 13:29           ` Sebastian Moeller
2014-02-24 16:24     ` Dave Taht [this message]
2014-03-03 19:41     ` David Lang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA93jw6rHU63RaJXyd-waFQ8epWOxTLFukmXoh=ti_uB4j+n0Q@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=jdashton@ashtonfam.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox