From owner-freebsd-ipfw@freebsd.org Thu Feb 2 22:37:57 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 7018BCCE524 for ; Thu, 2 Feb 2017 22:37:57 +0000 (UTC) (envelope-from thoms3rd@gmail.com) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B2E6656 for ; Thu, 2 Feb 2017 22:37:57 +0000 (UTC) (envelope-from thoms3rd@gmail.com) Received: by mail-qt0-x243.google.com with SMTP id h53so521219qth.3 for ; Thu, 02 Feb 2017 14:37:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=cetyKSEFNEE0Mz+SAMcinaeshoap/tRO2ak/mCtp774=; b=ShE6aO4F1PeIASqmczjO/tg9XRyKyqF9Nf5ZorN2ucmRA4yVhG3qz17YNTWayoTjCA YwlZPhh148PVg5Bp9JroOg0ro48LHlXlZhR14d7QMAaaONyA6lUerCQOuTperc640ItT /JCJSRy8olutZdhGJKnR8F/o5f9HJrTJK3HBYqfQqm1Ey54oybSRmsEATo8mjHeIJ/9Y GDKeZSN25yvtRXso6hOMB5Qy0k4fjXWgfCndcWe7No0c2QTGOKq5avte2ZZnzrTstROU Y5vHNotBK7kkNIadl04gt7KG9o3QUtON9AELFLFmC89JmqRd1VBJib1HfdPQ0++VCRRd a41Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=cetyKSEFNEE0Mz+SAMcinaeshoap/tRO2ak/mCtp774=; b=VqhRpgmwAFACOROpm+LwX3XmdsHsgx1i/Vc8Vg7T8c1RnnzFBFTZdT7cw5uSdUAn7Z ER43K1gXVJDRVO8uOXbwY5ObPPBqSuNuCWd8W93EcqmIujzjkGYQgb/s55jx7TKIJJ2I O5YTFsZZxp29tlkX+3hhRqj82iwgr/5Q2qaHlFRCF7xktOF9FaAFWWPLowXJUdatHjbv mT7sNeAQHzkcYXuE97pJOlTO+Go/suDoknlvnJvlDb6zRwnHTdaj/RI7aElskMAD0ASy 8PugManKEwwd5CEBDzoZCZYZM69OFTVzQx/bHO2ehYUdAv3khN/Pg0MyN8LCVqgp9+Jc OouQ== X-Gm-Message-State: AIkVDXJLJQH2WKEPa0KUOHQAMemEUtKQDDqTM0x+lVX8KnlGRnGTGoJJR7QJyE786p1e0Q== X-Received: by 10.200.56.164 with SMTP id f33mr10967612qtc.158.1486075076287; Thu, 02 Feb 2017 14:37:56 -0800 (PST) Received: from host ([177.97.64.221]) by smtp.gmail.com with ESMTPSA id y189sm22656896qky.39.2017.02.02.14.37.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 14:37:55 -0800 (PST) Date: Thu, 2 Feb 2017 20:37:46 -0200 From: Thomas To: Rakor Cc: freebsd-ipfw@freebsd.org Subject: Re: How to use IPFW to filter routing Message-ID: <20170202223746.GA8102@host> References: <3C00AFCB-E2EF-4F89-8FBD-181C99DAC1FF@rakor-net.de> <20170129164035.GB10963@host> <6B3C8792-2FEE-4FCE-952E-F13AF59E0927@rakor-net.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <6B3C8792-2FEE-4FCE-952E-F13AF59E0927@rakor-net.de> 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, 02 Feb 2017 22:37:57 -0000 Sun, Jan 29, 2017 at 06:52:58PM +0100, Rakor: > Hi and thanks for your reply! Hello! Sorry for not following up, I was busy and forgot. > I also tried it using recv and xmit rules. > [...]=20 > So to me it looks like he does not know that the packet will be transmitt= ed via igb2 at the moment it is inspected. Yeah, if via doesn't work, recv and xmit probably won't either. I can't tell at a glance why your out rule is not working =3D\. > > Have you tried something like this? > >=20 > > 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 >=20 > This will work. But for any new subnet I=E2=80=99ll have to remember to d= eny it for any other subnets. I think this can become unhandy very soon. > [...] > OK. So I=E2=80=99d like to have deny by default (as ipfw is working). The= n I=E2=80=99d like to say exactly which traffic is allowed. So in my mind I= =E2=80=99ll have no additional deny-rules. I=E2=80=99d like to say from whi= ch interface to which interface the traffic is traveling, because this resp= ects my VLANs. OK, because there is an IP attached to the devices using the= subnets would do it also (but I feel more comfortable seeing my interfaces= - maybe it=E2=80=99s stupid). >=20 > So the rules I=E2=80=99d like to write say: > "allow tcp from VLAN3 to Internet using ports 80,443 coming from igb0.3 g= oing to igb2 and deny all the rest." Of course, our mileages will be different, but avoiding deny rules can make things more complicated. A simpler, more explicit ruleset, even if it's a little longer, is generally safer and better. Performance (if it's at all a concern to you) may also suffer, as packets traverse more rules. As far as the number of subnets becoming unhandy, that is unavoidable if you're managing them individually like that. It may help to group them into zones and write your ruleset in terms of that. Use variables in your firewall script, and tables; "skipto" also comes in handy. Finally, filtering based on interfaces is good, but it's seldom enough. At least *I* could never avoid having addresses in the rules and still manage to filter everything I needed to. Also, using only the in/out interfaces in your rules makes them much more broad, and less flexible. Hope some of the above is useful to you, as it is to me when writing my rulesets. Cheers, - Thom=C3=A1s