From owner-freebsd-ipfw@freebsd.org Thu Feb 9 06:08:50 2017 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88061CD7DAA for ; Thu, 9 Feb 2017 06:08:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 776E06E1 for ; Thu, 9 Feb 2017 06:08:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v1968oC5013460 for ; Thu, 9 Feb 2017 06:08:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 216867] IPFW workstation rules block DNSSEC resulting in DNS failure on freebsd.org domains Date: Thu, 09 Feb 2017 06:08:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: conf X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 06:08:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216867 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- CC|freebsd-amd64@FreeBSD.org | Assignee|freebsd-bugs@FreeBSD.org |freebsd-ipfw@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Thu Feb 9 17:46:33 2017 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22363CD7E2D for ; Thu, 9 Feb 2017 17:46:33 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0128018CE for ; Thu, 9 Feb 2017 17:46:32 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-246-6.lns20.per4.internode.on.net [121.45.246.6]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v19HkRBY020051 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 9 Feb 2017 09:46:31 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: How to use IPFW to filter routing To: freebsd-ipfw@freebsd.org References: <3C00AFCB-E2EF-4F89-8FBD-181C99DAC1FF@rakor-net.de> <20170129164035.GB10963@host> <6B3C8792-2FEE-4FCE-952E-F13AF59E0927@rakor-net.de> <20170203164311.L33334@sola.nimnet.asn.au> From: Julian Elischer Message-ID: <9bdc58a2-1915-ffd7-ce83-8bfeaa91b60f@freebsd.org> Date: Fri, 10 Feb 2017 01:46:22 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170203164311.L33334@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:46:33 -0000 On 3/2/17 2:58 pm, Ian Smith wrote: > On Sun, 29 Jan 2017 18:52:58 +0100, Rakor wrote: > > Hi and thanks for your reply! > > Just a couple of points in addition to Thomás' recent reply, which well > covers most aspects .. quoting here went totally weird, so excuse any > strangeness there; I'm just plucking out and reformatting a few bits. > > > Am 29.01.2017 um 17:40 schrieb Thomás : > > > Have you tried something like this? > > > > > > ipfw add deny tcp 10.10.30.0/24 to 10.10.10.0/24 setup keep-state > > > ipfw add deny tcp 10.10.30.0/24 to 10.10.20.0/24 setup keep-state > > > ipfw add allow tcp 10.10.30.0/24 to any 80 setup keep-state > > > This will work. But for any new subnet I˙˙ll have to remember to deny > > it for any other subnets. I think this can become unhandy very soon. > > Thomás mentioned in passing, but I'll emphasise: this is a classic job > for tables. Then you can add or delete entries, on the fly if needed, > and table lookups are faster than traversing multiple rules. > > ipfw deny tcp 10.10.30.0/24 to "table($deniednets)" setup > > (keep-state doesn't make sense on deny rules) > > > If I try the follwing the packets are all rejected. I think the > > inspection is done before the routing, so IPFW does not know it > > should be forwarded using igb2. > > ipfw add allow tcp 10.10.30.0/24 to any 80 out via igb2 setup keep-state > > It's essential to get a picture in your head from ipfw(8) /PACKET FLOW > > On the 'in' pass, as you later guessed, it is not known which interface > might be chosen by routing, which occurs only AFTER the inbound packet > has been accepted and is determined to be non-local .. so you have to > then do this sort of discrimination on the 'out' pass. > > As Thomás suggested, add 'log' to any rule you're not sure about how or > whether they're doing the right thing, setting logamount to default 100. > Once things are working right you can lose the extra logging, but it > often makes obvious some possibly mysterious problems. > > > I also tried it using recv and xmit rules. > > First I tried: > > ipfw add allow tcp from 10.10.30.0/24 to any out recv igb0.30 xmit igb2 setup keep-state > > it does not work. > > and later I tried this > > ipfw add allow tcp from 10.10.30.0/24 to any out xmit igb2 setup keep-state > > also not working > > > Anytime it was caught by my default rule at the end: > > 00150 deny log logamount 5 ip from any to any > > Yes, that's because you have not accepted these packets on their inbound > pass, so they fell through to the deny all rule. The above rules cannot > work inbound, but should on the outbound pass, the form of the first one > being particularly useful. It may be helpful showing the whole ruleset, > or at least a section in context, if you're still having issues? > > > /var/log/security said: > > > > 150 Deny TCP 10.10.30.5:51145 82.193.243.115:80 in via igb0.30 > > > > So to me it looks like he does not know that the packet will be > > transmitted via igb2 at the moment it is inspected. > > Exactly so; it CANNOT know what routing will do with it, as routing only > occurs after it has been accepted, just prior to ipfw's outbound pass. I will add that I find the following scheme works for me to help understand what is going on: on a system with two interfaces $INSIDE and $OUTSIDE I always start my rule sets with somethign like: 100 skipto 1000 ip from any to any in recv $OUTSIDE 110 skipto 2000 ip from any to any out xmit $OUTSIDE 120 skipto 3000 ip from any to any in $INSIDE 130 skipto 4000 ip from any to any out xmit $INSIDE 140 rules for localhost etc. this gives you clear idea of what packet are hitting which rules. you will notice for example that an outgoing packet that is routed form an inside machine first does the rules at 3000 and then the rules at 2000 > Thomás' advice re not being shy about using more deny rules is sound; > even on slow processors the time cost per rule is miniscule compared to > transmission time, unless you're pushing mega PPS over high Mbps links, > in which case you'd be using tables for the utmost advantage anyway. > > cheers, Ian > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > >