From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::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 A8B6A21F182 for ; Wed, 19 Mar 2014 14:44:09 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so7487587wgh.23 for ; Wed, 19 Mar 2014 14:44:06 -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=TpwegWfGmAIOOi/Zr8zFbKadzvUiIwGGYjpFSsvX9No=; b=F/tjhFRs+rPJSdQ09Xxin40nvcf4oOqgeY1MeCRZJCnNd8wlPLBq8SRqreT4XIoQnG uJQo9Yi7nZs+tSyyAZbPdG5Gi0mF6FlDCP2D1p5K1EyMkBsbfbeZWDhdN+m9ZjUq5YtN s2AByW8pkXugY3ZSQ6yErsmHLLtKOpRrEvlfHoUucdPVNnm0ew5aOqgDlE6Mpn66r531 Tf44WLVIC6Cx8ORvaU/42WnHN3ulwStz/WaGej1oS2vAMMKhy/kWJoh3HoFOd+zSQs18 BY8ALXh6MYeNVpy27u+LagfVVkuFe2ILvt3P9R4P3O7vuoqPmNVXWm5nHwJbpfg9p2Ga AGuw== MIME-Version: 1.0 X-Received: by 10.194.236.9 with SMTP id uq9mr30767075wjc.31.1395265446293; Wed, 19 Mar 2014 14:44:06 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Wed, 19 Mar 2014 14:44:06 -0700 (PDT) In-Reply-To: <87txataord.fsf@toke.dk> References: <87txataord.fsf@toke.dk> Date: Wed, 19 Mar 2014 14:44:06 -0700 Message-ID: From: Dave Taht To: =?ISO-8859-1?Q?Toke_H=F8iland=2DJ=F8rgensen?= , "jow@openwrt.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] BCP38 implementation 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: Wed, 19 Mar 2014 21:44:40 -0000 wow, thx. I was just about to give up and declare cero "baked enough". the core problem remaining is ensuring dhcp request and renew work even with double-nat and that state is retained across a network and firewall re= load. jow is mr firewall at openwrt, cc'd for comments. On Wed, Mar 19, 2014 at 1:59 PM, Toke H=F8iland-J=F8rgensen = wrote: > > So I've hacked a bit on a BCP38 implementation for IPv4, and I think I > sorta have a working prototype. I ran out of steam trying to package > everything up properly, so thought I'd distribute it so that those > adventurous enough to do a manual install could give some feedback. > > Install instructions (for 3.10.32-9 -- dunno if it will work in earlier v= ersions): > 1. Get and install the bcp38 package from > http://archive.tohojo.dk/cerowrt/wndr/3.10.32-9-tohojo/packages/bcp38_2-1= _ar71xx.ipk > -- this will get you the script and it should be run from the firewall. > > 2. Add the following to your /etc/config/firewall, after the last > 'forwarding' section: > > config ipset > option name 'bcp38-ipv4' > option family 'ipv4' > option match 'dest_net' > option storage 'hash' > > config ipset > option name 'bcp38-ipv4-ingress' > option external 'bcp38-ipv4' > option family 'ipv4' > option match 'src_net' > option storage 'hash' > > config rule > option src 'wan' > option ipset 'bcp38-ipv4-ingress' > option family 'ipv4' > option name 'drop-bcp38-ipv4 input' > option target 'DROP' > option proto 'all' > > config rule > option src 'wan' > option dest '*' > option ipset 'bcp38-ipv4-ingress' > option family 'ipv4' > option name 'drop-bcp38-ipv4' > option target 'DROP' > option proto 'all' > > config rule > option dest 'wan' > option ipset 'bcp38-ipv4' > option name 'reject-bcp38-ipv4 output' > option family 'ipv4' > option target 'REJECT' > option proto 'all' > > config rule > option dest 'wan' > option src '*' > option ipset 'bcp38-ipv4' > option name 'reject-bcp38-ipv4' > option family 'ipv4' > option target 'REJECT' > option proto 'all' > > > Those two steps should be enough to enable the basic mechanism. It is > controlled by adding a new option to the firewall config file, in the > defaults section. The option is called 'enable_bcp38'. So adding a line > like: > > option enable_bcp38 '1' > > to the end of the 'defaults' at the top of /etc/config/firewall should > enable the mechanism on firewall reload. > > Additionally, an option called bcp38_whitelist can be set to one or more > CIDR style net addresses (space separated) which will be excluded from > the matching. This can be used to account for double nat'ing, so if your > WAN interface gets an address that would be blocked by the bcp38 rules, > add it here and it should go through. For example, configuring cablemodems commonly relies on 192.168.100.1 being the accessible external-through-nat ip. > > To get a checkbox and a field in the firewall GUI to control this, apply > the following patch to /usr/lib/lua/luci/model/cbi/firewall/zones.lua > (with patch -p1; not sure if that is included in cerowrt, otherwise, > just paste in the added lines manually): > > --- a/zones.lua > +++ b/zones.lua > @@ -32,6 +32,12 @@ > o =3D s:option(Flag, "drop_invalid", translate("Drop invalid packets")) > o.default =3D o.disabled > > +b =3D s:option(Flag, "enable_bcp38", translate("Enable BCP38 filtering")= ) > +b.default =3D b.disabled > + > +bip =3D s:option(Value, "bcp38_whitelist", translate("BCP38 whitelist su= bnet")) > +bip:depends("enable_bcp38", "1") > + > p =3D { > s:option(ListValue, "input", translate("Input")), > s:option(ListValue, "output", translate("Output")), > > > > As I said, the basic functionality should be there, but there's some > outstanding issues. Including, but not necessarily limited to: > > - Should there be a separate configuration page where the included > subnets can be specified? Or is the checkbox on the firewall page > sufficient? I think it logically belongs with the firewall, and indeed > it is needs the firewall config rules to function, but maybe more > configurability is good thing? > > - Managing the different parts of the configuration can be brittle. I.e. > if the mechanism is disabled but the firewall rules are missing, or > vice versa, it's not going to work. If it fails without hurting connectivity I can live with that. > - Some sort of auto-detection of upstream private subnets would probably > be good, unless we risk people having no access before they change the > config manually. My hope was to identify the upstream host and subnet and allow that by hooking into the dhcp request. > - Right now blocked outgoing packets get a 'destination port > unreachable' -- this seems to be a hard-coded feature of the firewall > script setup. Should probably be a 'destination net unreachable' > instead. Theoretically the option to add to the reject statement in the fw3 rules stanze would be: option extra ' --reject-with addr-unreach' the full list of --reject-with options can be seen with: iptables -j REJECT --help it is not obvious what icmp message to send on a reject --reject-with icmp-net-prohibited # or host-prohibited seems logical. I am all in favor of being chatty inside the fw, and not outside. > > > Anyway, comments welcome. :) > > -Toke > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html