From owner-freebsd-pf@freebsd.org Thu May 19 15:26:05 2016 Return-Path: Delivered-To: freebsd-pf@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 586E2B413FF for ; Thu, 19 May 2016 15:26:05 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (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 19F0B1454 for ; Thu, 19 May 2016 15:26:04 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-qg0-x236.google.com with SMTP id f92so45223218qgf.0 for ; Thu, 19 May 2016 08:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=vVFeexzD3qteXOvMvpTwIXiziNDulv/sCWVk9Cu45bc=; b=KR4o5RS+xUX3rT5frMNh21uZ49r/bbJiL0yPRdRQS7I8xvXdCTXTCSY4+h87KkYJLS NTYLeKGyCraSqQZ2ot5HPstivQ05wmUxWmwujxPHoQ7iUBZa2L+8nfhzzcVb+E1TuOEG Yn0pxoob6HZUYc0i8ZS3ZIZ6svJPIROx3uG7ijI2bFfj2pyZeIIlvKgrPgZv/X7UdzIb TnaBdrTgeo87lYcX+g7JqchGaW+ICxDAQ++cFktqhMx5bMrJxK5c3rSCWrG0MB8y1afo GaoenjCoX2wCiT3saSq358dv8eb74N6TUL7qWCrxHykSdi1flM9IdFVcSHW7QcBP4Z+6 QLaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=vVFeexzD3qteXOvMvpTwIXiziNDulv/sCWVk9Cu45bc=; b=UwjiHUQM4lMDDD2he3vNW7vCLI/OiKzwRxVFKiEsQBSbLN0QMYHf8U4f0qlzZikE0k 4n5fNPJDrOegYhJ8fRbMOdzgOaWCNCGBLrRf5SWzPS96SLtwcKIE8fc1sxw6heN5QMkM AB4/XOARV4r8MK2alC9q1WizhBkbQXEQAw/TCw+NTFJImla+uSYtA297M0kdAZN9CAla OnU+z/FFRm9jVDT6uuJteuIxTUle+wOseTabbj9+bU2W8EKXsj7pmOGZkdenv5I9fyZt 7uAM84+zxQn2UVnQjpgJX5sb8Zaj0u+9WHU3eKEhJiG/nihXVHaKkJA4lptkcgJpOqLo HDxA== X-Gm-Message-State: AOPr4FVxRgnx5f/BWxQ1FqeVjGvFpNROTrrE/8BOmTcxDGvQIBT27Pa2JxpxzSyvq0aJrmT5kP+LqP9KUwDmH0idNGuOry+cJslH7TKb0giD6KroICwtR86kKfi+YgI9e41viXCIm1F2OLAAzFE17w3sQSncffAzksh98+4lbvi9KFMRoR+/nSbuXq4Y6RRjOH7hOQ== X-Received: by 10.140.87.116 with SMTP id q107mr14164581qgd.61.1463671563522; Thu, 19 May 2016 08:26:03 -0700 (PDT) Received: from zen.clue.co.za ([64.53.114.172]) by smtp.gmail.com with ESMTPSA id e11sm6775875qkb.39.2016.05.19.08.26.02 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2016 08:26:02 -0700 (PDT) Subject: Re: Traffic shaping incomming traffic for all vlans To: freebsd-pf@freebsd.org References: <262ED41F8198C0409ACB79946570FFCD1AA134055F@EXCHANGE.mail.starnet.cz> From: Ian FREISLICH Message-ID: Date: Thu, 19 May 2016 11:26:02 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <262ED41F8198C0409ACB79946570FFCD1AA134055F@EXCHANGE.mail.starnet.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 15:26:05 -0000 On 05/19/16 05:48, Radek Krej=C4=8Da wrote: > I have freebsd router with pf for NAT and firewall. There are 2 NICs, one= for incomming traffic from internet and second for traffic to clients. On = internal NIC are a lot of vlans. > > I need to make traffic shaping for all users based on src ip from interne= t. But I have problem, it doesnt work. > > Working rule for block all traffic is: > > block quick proto { tcp, udp } from 192.168.52.0/24=20 > > but the same rule with externa nic dosnt match: block quick on $ext_if pr= oto { tcp, udp } from 192.168.52.0/24 > Why? Remember that with PF the *last* rule to match wins and that the state table is checked *before* rules are evaluated. If there is a state, rules won't be checked. If there is a later rule that allows the traffic that rule will be used. The quick modifier prevents further evaluation of rules, but if you're using quick all over the place perhaps an earlier rule allows the traffic. Unless you set 'state-policy if-bound' the default state-policy of floating will apply and then any rule that matches allowing traffic into an interface will result in matching state that will allow the traffic out of another interface without the rules being checked. > And second problem - how to set up (on which interface) altq queues? The trouble with pf's bandwidth management is that it relies on state to apply traffic flows to a queue. While this is nice in some respects I've always had trouble implementing traffic rates in specific directions. What happens is that you can only assign a rate to a class of traffic, ie www gets 10Mbps total for traffic in both directions. In the end I used PF for packet filtering and ipfw + dummynet for bandwidth management. I'd suggest to carefully read the 'QUEUEING' section in pf.conf(5) and if you can't make it work post your rules. Ian --=20 Ian Freislich --=20 =20 Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the system manager.= =20 This message contains confidential information and is intended only for the= =20 individual named. If you are not the named addressee you should not=20 disseminate, distribute or copy this e-mail. Please notify the sender=20 immediately by e-mail if you have received this e-mail by mistake and=20 delete this e-mail from your system. If you are not the intended recipient= =20 you are notified that disclosing, copying, distributing or taking any=20 action in reliance on the contents of this information is strictly=20 prohibited.