From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 05:41:05 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEBA916A4DD for ; Tue, 11 Jul 2006 05:41:04 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7593043D45 for ; Tue, 11 Jul 2006 05:40:59 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 372AF4CE05 for ; Tue, 11 Jul 2006 05:40:50 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 963894CDFF for ; Tue, 11 Jul 2006 05:40:45 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id D5BD68A061; Tue, 11 Jul 2006 15:40:38 +1000 (EST) Received: from [192.168.46.102] (unknown [192.168.46.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id D22248A01F; Tue, 11 Jul 2006 15:40:38 +1000 (EST) Message-ID: <44B339D6.7090401@thebeastie.org> Date: Tue, 11 Jul 2006 15:40:38 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060404 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dmitry Andrianov References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 11 Jul 2006 05:41:05 -0000 Dmitry Andrianov wrote: >Hello. > > > >>I might remove these in the future but just want to at least >>do some testing on a firewall setup for many reasons such as >>it has 2 separate links and want to try changing between the >>links/routes without affecting state. >> >> > >I'm not sure how this should work. If you change outgoing NAT address >(what else "switching the link means"?), everything WILL break. With >both UDP and TCP any stateful firewall on server side will reject >"stream" where address changes in the middle. Even if there is no >stateful firewall on their side, TCP implementation on the server will >not accept these packets. > > > >>Take this rule for example >>pass out on fxp0 proto { tcp, udp, icmp } from any to any >>modulate state. >>What TCP flags rules are being used when you use "modulate >>state" for the TCP protocol? is it the same kind of rules as >>UDP as in as it largely ignores flags (as UDP has none) and >>if any TCP packets are going out then it just tracks that >>state? or is it working on the most popular Flags option rule >>such as "flags S/SA" >> >> > >AFAIK, it does not check flags. > > That still doesn't really answer my question and I also am looking for a flags example of what would guarantee to provide the desired behavior. > > >>If its just any flag this would mean I could just >>/etc/rc.d/pf restart (over resync) on the firewall gateway >>and the users aren't likely to notice anything as the TCP >>protocol would probably just resend its last sent packet >>believing the last one was dropped. >> >> > >Yes, if you restart pf with such a rules, the next _outgoing_ packet >(what has a rule in your firewall) should restore the state. But keep in >mind that a packet in opposite direction will not restore the state >(because it has no separate rule for it and used to match on state >only). So such a packet will be blocked. > >Btw, I'm not sure why you need restarting pf at all. If you need it to >reload the rules, use > >pf -F rules -f /etc/rc.pf > >It will flush all rules and load new from file while keeping all the >states. > > As I said above I am testing, I said restart over any kind of resync, Its far easier and less error prone to just use the built in "/etc/rc.d/pf resync" command to keep state while loading in new rules, compared to typing all that out manually. pf_resync() { $pf_program -f "$pf_rules" $pf_flags } > > >>What is the recommended way to place restrictive rules on >>internal IPs? >> >> > >Why can't you filter incoming packets as they come on internal >interface? IMHO it is more natural because you stop unwanted traffic >early.. > > So your saying that to stop packets going *out* its more "natural" to type up a *block in* firewall rule to achieve the desired result, I think its is a hard point of view to argue, and this was something that was never needed with IPFilter and is probably one of its better remaining features over PF. So to block to block IP 192.168.1.17 from connecting *out* to anything on the internet I have to use a "block in" statement and there is no other way of doing this rule? block in quick on $int_if proto { tcp, udp, icmp } from 192.168.1.17 to any Mike