From owner-freebsd-pf@FreeBSD.ORG Mon Jul 10 02:10:20 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 29B2A16A4DD for ; Mon, 10 Jul 2006 02:10:20 +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 746F843D4C for ; Mon, 10 Jul 2006 02:10:17 +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 B34B14CDD8 for ; Mon, 10 Jul 2006 02:10:19 +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 05FC04CDD7 for ; Mon, 10 Jul 2006 02:10:19 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id 0160E8A061 for ; Mon, 10 Jul 2006 12:10:15 +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 F20B98A01F for ; Mon, 10 Jul 2006 12:10:14 +1000 (EST) Message-ID: <44B1B706.2030406@thebeastie.org> Date: Mon, 10 Jul 2006 12:10:14 +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: freebsd-pf@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP Subject: 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: Mon, 10 Jul 2006 02:10:20 -0000 Hi all, I have some questions about pf rules, and just want to get some things clear in my mind about how PF works, no doubt some of the answers will be obvious to some. I wanted to create some pf rules for TCP that can withstand loosing state but still utilizing the advantage of single line firewall rules. 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. 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" 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. I haven't tested but I would assume if some one was playing a UDP based game like counter-strike I could do pf restarts and they would probably not notice or have just a little pause in the game since it would only take a split second for the client side of the game to send out a UDP packet reinstating the UDP outgoing state rule, so this should be easy enough to do on TCP with lean flags (if modulate state doesn't do it). I was thinking a minimal interference keep state firewall rule would be based on any flags going out except for the R (reset) flag, is this correct? Also when I used to use IPfilter you could place firewall rules on the external interface for internal NAT IPs, I would use this to filter packets for internal IPs but place the rules on the external interface. pass out on $ext_if proto { tcp, udp, icmp } from 192.168.1.5 to any modulate state. Unlike IPFilter these rules never work with PF and it appears that any rules creating for the $ext_if interface are ignored. As I understand it translation occurs /before/ filtering, if I have NAT set on my external interface, internal IP packet filter rules on the external interface never work since the external interface Never saw any internal IPs reach it, is the correct way to see it? Given that if I used the example firewall rule listed at the bottom on this URL with NAT. http://www.openbsd.org/faq/pf/filter.html What is the recommended way to place restrictive rules on internal IPs? does any one have some examples as there are none on the OpenBSD PF guide. To me it just fits better inside my head to place these rules on the external interface in a keep state manner, while having stateless rules on the internal IPs interface just as this example ruleset has done on that web site. pass in on $int_if from $lan_net to any pass out on $int_if from any to $lan_net Thank you, Mike