From owner-freebsd-ipfw@freebsd.org Sun Jan 29 16:40:40 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 F153ACC7916 for ; Sun, 29 Jan 2017 16:40:40 +0000 (UTC) (envelope-from thoms3rd@gmail.com) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (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 A41A69E9 for ; Sun, 29 Jan 2017 16:40:40 +0000 (UTC) (envelope-from thoms3rd@gmail.com) Received: by mail-qk0-x244.google.com with SMTP id u25so15570681qki.2 for ; Sun, 29 Jan 2017 08:40:40 -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=wlpNrrZ7yx48qhQbc9sSIvNhY34KFDVl2mpYZQSmSY4=; b=n7YurKlcx+QfTVQY32ulqdiVccqIrDySAuR64kKj+Yprt/pjUEZKwfyeujZDFDyF5J sDBuVdEwsOS+I4dh5OYDb8PnGJ7X/P76x0HXuuPbI3CnXAaEiMX5RuQHzzTwq8vRXXr/ JdEg4ea/jTiY21GT6TOdFEdjYBMo+dlA2P3sn2e+DMys7EYfy4uD6fC7jwGAofaeGnU6 UkKbqkvmPxJR9tuS/Gblcc5wTxA3FyempjZuNHLCb/mlNEnqnnup3/99rKjqYAmTC4AP 2s3zCS3CSrnfxBLM8H8TTc7czTM5sCR4ddrkD1BYy/ZkWrYGf1qYpbiJAAKRsfXZVHFi cBcQ== 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=wlpNrrZ7yx48qhQbc9sSIvNhY34KFDVl2mpYZQSmSY4=; b=qcTFT17YbLqmJZnhOqauF2OXl3UyJNuUK9lHJZt8Mgapdg9JtVEnSqUQE9S9ITMAOQ W7CIZvvnck7Poswbc4erJtuQc7pXv3Y8WCyov+Mhprfs7ijGI942kM6PXsYcbqwVlW72 x48/L4S5VjNH4684jT/oye6s9Hp9pk4lNwJ80qEFkdcFIaJ2d+vYKFCL4zOTqYiC/O4C iHvHqkgG6bEVrJrShyfW6unYPlotwzHksAxCKXFEHRFV2weClENIbK6SeQYus4AUhilZ qBqVL3GWBUgu7IGULcQy6IxfBRXl9v5Xu7HFmkEsL0U2VguEx5aaSuBvQSH/u9/PZb+r pV0Q== X-Gm-Message-State: AIkVDXLv3zCIFn48hpqKt+Slu3Rkt3jTJ+F4eqAdxh1Uydd8FvShdav9hAC4S+XlfvN51w== X-Received: by 10.55.67.135 with SMTP id q129mr12179685qka.98.1485708039855; Sun, 29 Jan 2017 08:40:39 -0800 (PST) Received: from host (189.27.232.179.dynamic.adsl.gvt.net.br. [189.27.232.179]) by smtp.gmail.com with ESMTPSA id p70sm3129101qke.48.2017.01.29.08.40.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2017 08:40:39 -0800 (PST) Date: Sun, 29 Jan 2017 14:40:35 -0200 From: =?iso-8859-1?Q?Thom=E1s?= To: Rakor Cc: freebsd-ipfw@freebsd.org Subject: Re: How to use IPFW to filter routing Message-ID: <20170129164035.GB10963@host> References: <3C00AFCB-E2EF-4F89-8FBD-181C99DAC1FF@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: <3C00AFCB-E2EF-4F89-8FBD-181C99DAC1FF@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: Sun, 29 Jan 2017 16:40:41 -0000 Sat, Jan 28, 2017 at 01:58:01PM +0100, Rakor: > As far as I know a packet is once scanned by IPFW an then first hit wins.= So, if I set the following a packet coming from VLAN3 for port 80 is permi= tted to travel all way it wants, even to VLAN2. Putting an +other rule behind just allowing to travel out using igb2 is not checked, b= ecause the search terminated after first hit. > ipfw add allow tcp 10.10.30.0/24 to any 80 setup keep-state 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 > If I try the follwing the packets are all rejected. I think the inspectio= n 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 IPFW can do routing table lookups as needed. Something else must be going on here. Log rules may be of help to debug and understand your ruleset. > So I don=E2=80=99t know how to filter packets that should be routed in a = exact manner. Can you help me? There are plenty of ways to filter packets in that setup, the "exact" one depends on what you are trying to achieve. Cheers, - Thom=C3=A1s P.S.: sorry for the duplication, I'd forgotten to CC the list. From owner-freebsd-ipfw@freebsd.org Sun Jan 29 17:53:07 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 424B1CC72D6 for ; Sun, 29 Jan 2017 17:53:07 +0000 (UTC) (envelope-from freebsd@rakor-net.de) Received: from mail.denkrobat.de (mail.denkrobat.de [176.9.53.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.denkrobat.de", Issuer "StartCom Class 1 DV Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A56351D8E for ; Sun, 29 Jan 2017 17:53:06 +0000 (UTC) (envelope-from freebsd@rakor-net.de) Received: from martins-mbp.fritz.box (062-142-067-156.ip-addr.inexio.net [156.67.142.62]) by mail.denkrobat.de (OpenSMTPD) with ESMTPSA id e2d87657 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sun, 29 Jan 2017 18:52:58 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: How to use IPFW to filter routing From: Rakor In-Reply-To: <20170129164035.GB10963@host> Date: Sun, 29 Jan 2017 18:52:58 +0100 Cc: freebsd-ipfw@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B3C8792-2FEE-4FCE-952E-F13AF59E0927@rakor-net.de> References: <3C00AFCB-E2EF-4F89-8FBD-181C99DAC1FF@rakor-net.de> <20170129164035.GB10963@host> To: =?utf-8?Q?Thom=C3=A1s?= X-Mailer: Apple Mail (2.3259) 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: Sun, 29 Jan 2017 17:53:07 -0000 Hi and thanks for your reply! > Am 29.01.2017 um 17:40 schrieb Thom=C3=A1s : >=20 > Sat, Jan 28, 2017 at 01:58:01PM +0100, Rakor: >> As far as I know a packet is once scanned by IPFW an then first hit = wins. So, if I set the following a packet coming from VLAN3 for port 80 = is permitted to travel all way it wants, even to VLAN2. Putting an > +other rule behind just allowing to travel out using igb2 is not = checked, because the search terminated after first hit. >> ipfw add allow tcp 10.10.30.0/24 to any 80 setup keep-state >=20 > 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 This will work. But for any new subnet I=E2=80=99ll have to remember to = deny it for any other subnets. I think this can become unhandy very = soon. >> 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 >=20 > IPFW can do routing table lookups as needed. Something else must be > going on here. Log rules may be of help to debug and understand your > ruleset. 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=20 ipfw add allow tcp from 10.10.30.0/24 to any out xmit igb2 setup = keep-state=20 also not working Anytime it was caught by my default rule at the end: 00150 deny log logamount 5 ip from any to any /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. >> So I don=E2=80=99t know how to filter packets that should be routed = in a exact manner. Can you help me? >=20 > There are plenty of ways to filter packets in that setup, the "exact" > one depends on what you are trying to achieve. OK. So I=E2=80=99d like to have deny by default (as ipfw is working). = Then 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 which interface to which interface the traffic is traveling, = because this respects 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). 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 = going to igb2 and deny all the rest." From owner-freebsd-ipfw@freebsd.org Tue Jan 31 03:10:41 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 52055CC9404 for ; Tue, 31 Jan 2017 03:10:41 +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 41AE21EAB for ; Tue, 31 Jan 2017 03:10:41 +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 v0V3Ae4d048790 for ; Tue, 31 Jan 2017 03:10:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 216610] TCP connections stuck forever in FIN_WAIT2 using IPFW Date: Tue, 31 Jan 2017 03:10:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-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: assigned_to cc 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: Tue, 31 Jan 2017 03:10:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216610 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-ipfw@FreeBSD.org CC|freebsd-amd64@FreeBSD.org | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Thu Feb 2 14:08: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 59DC4CCA604 for ; Thu, 2 Feb 2017 14:08:33 +0000 (UTC) (envelope-from franciscoramonhr79@gmail.com) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 12777D72 for ; Thu, 2 Feb 2017 14:08:33 +0000 (UTC) (envelope-from franciscoramonhr79@gmail.com) Received: by mail-qt0-x22e.google.com with SMTP id v23so32171304qtb.0 for ; Thu, 02 Feb 2017 06:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=W/NQkdPPoQlOzIFVtGeWuzYrySI5iklBVopt4dyQNjc=; b=e0DOBHUaiDYABTSuic2MlTRcyejGvXBhcZIEPCpToj6ddkSqHFqtB6MR2sn3gsl942 DY6pdAN+APJwY4vKqWRwoFJkiScO+y6f111GAAC6jw+giTZBymIQRAoWSQJ7KbpOwVIV 0N1PKdrbGH/K04RTuMG7F3wUQB5wTj1u7NHVN31wuNCnxCUt35KpoR05yh9bjnoEX3M0 7gk5l/cQrXYuVam6/FtJQI4rsmEDc8GxYMlk4MNGvw4ldCjh4nLatmL9MHbLSxKAv+i6 AmWJbwdBKROd/7l9uIaR1Uc8Wi2KfxU526W7frNAX5IRuME82/TZo6DC0MGvqqgy/ma8 syfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=W/NQkdPPoQlOzIFVtGeWuzYrySI5iklBVopt4dyQNjc=; b=pJDXRyZxinICObhmk9FQ7SQB8cxav1cXfNXsdJfC/bg9S3C77x+4S2nYA3V0YS7tUG TGF37W1Y3aSMpYtn1vH4+1i+SfPejLf/EpEThgYqrqtrZGsVa/lVqvsjneVfUCcmpUC3 upUaPjTy4m6znxgEcYoRtkraVEmcoidmj3qJ/fp7JbbbuXQocBhtQBueXT1GvUVYVedO 7LkDkk8jXdqgIs4EGEXp/EwlXWD+0OyBxoK+IMuJTKqbVHitUoGa402EN+rCMUYaq8oJ bkXgGa+V130Ue3eAuAt29X4mLkYCI1XLXzTOP16O8NTK1ILpffrSgQXqokavUGH/vboX GHyw== X-Gm-Message-State: AIkVDXI8UotiHCh8tt3nBVT4t81z4uU81Pbhn8uKSiLJxZ/2259MFyw6XSN+OK0QBqYckd4z7FydupmNrftkkg== X-Received: by 10.200.34.155 with SMTP id f27mr7816764qta.129.1486044512079; Thu, 02 Feb 2017 06:08:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.48.3 with HTTP; Thu, 2 Feb 2017 06:08:31 -0800 (PST) From: Francisco Ramon Date: Thu, 2 Feb 2017 12:08:31 -0200 Message-ID: Subject: Reload rules To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 14:08:33 -0000 Hello! I=C2=B4m trying to biuld a IPFW script and i=C2=B4m using some dynamic rule= s (with keep-state). The problem occur when I need to restart the script, to reload new or eddited rules... When I execute the "ipfw -f flush", off course dynamic rules are erased. The problem is: Some or all of then in my case, should not be erased. Is there any possibility to reload the rules, keeping the dynamic rules? Tks! From owner-freebsd-ipfw@freebsd.org Thu Feb 2 14:52:43 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 0F93DCCD5D4 for ; Thu, 2 Feb 2017 14:52:43 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E7DE921 for ; Thu, 2 Feb 2017 14:52:40 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id v12EqTvp005303; Fri, 3 Feb 2017 01:52:29 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 3 Feb 2017 01:52:29 +1100 (EST) From: Ian Smith To: Francisco Ramon cc: freebsd-ipfw@freebsd.org Subject: Re: Reload rules In-Reply-To: Message-ID: <20170203014041.K33334@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 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, 02 Feb 2017 14:52:43 -0000 On Thu, 2 Feb 2017 12:08:31 -0200, Francisco Ramon wrote: > Hello! > I´m trying to biuld a IPFW script and i´m using some dynamic rules > (with keep-state). The problem occur when I need to restart the > script, to reload new or eddited rules... When I execute the "ipfw -f > flush", off course dynamic rules are erased. The problem is: Some or > all of then in my case, should not be erased. Is there any > possibility to reload the rules, keeping the dynamic rules? I don't know (by trying it) whether this will work, but ipfw(8) says: set set_number [..] Set 31 is special in that it cannot be disabled, and rules in set 31 are not deleted by the ipfw flush command (but you can delete them with the ipfw delete set 31 command). Set 31 is also used for the default rule. So you could try adding your dynamic rules to set 31 and check that they (and unexpired dynamic flows) survive a flush, with 'ipfw -ted show' ? cheers, Ian 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 From owner-freebsd-ipfw@freebsd.org Fri Feb 3 06:58:48 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 E0E05CCE687 for ; Fri, 3 Feb 2017 06:58:48 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 379DB17B3 for ; Fri, 3 Feb 2017 06:58:47 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id v136wgjJ038277; Fri, 3 Feb 2017 17:58:43 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 3 Feb 2017 17:58:42 +1100 (EST) From: Ian Smith To: Rakor cc: =?utf-8?Q?Thom=C3=A1s?= , freebsd-ipfw@freebsd.org Subject: Re: How to use IPFW to filter routing In-Reply-To: <6B3C8792-2FEE-4FCE-952E-F13AF59E0927@rakor-net.de> Message-ID: <20170203164311.L33334@sola.nimnet.asn.au> 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=ISO-8859-1 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: Fri, 03 Feb 2017 06:58:49 -0000 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. 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 From owner-freebsd-ipfw@freebsd.org Fri Feb 3 11:48:45 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 F33C7CCE4AA for ; Fri, 3 Feb 2017 11:48:45 +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 E00DD1039 for ; Fri, 3 Feb 2017 11:48:45 +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 v13Bmj3H048426 for ; Fri, 3 Feb 2017 11:48:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 216719] panic: ipfw_check_frame: unknown retval - while trying to ipfw nat incoming packet without translation state (can be L2 firewall related) Date: Fri, 03 Feb 2017 11:48:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me 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: 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: Fri, 03 Feb 2017 11:48:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D216719 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-ipfw@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.=