From owner-freebsd-pf@FreeBSD.ORG Sun Jul 12 14:20:51 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DF3F106564A for ; Sun, 12 Jul 2009 14:20:51 +0000 (UTC) (envelope-from apetar@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id F40BA8FC08 for ; Sun, 12 Jul 2009 14:20:50 +0000 (UTC) (envelope-from apetar@gmail.com) Received: by fxm24 with SMTP id 24so1444738fxm.43 for ; Sun, 12 Jul 2009 07:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=AdMDUoLHrCvZhmbz/c0AGwQ5RMMlXXxPjI3FY8H0ZFQ=; b=eTBaYfaBnVeLFo/w5w3XUNobJFwuCeEdBJ/fSriFz/NZBXbY7R0FFqjB3jE0j24tcK i74dHhlMQLy0WkMcW+DoToHExLLdf1V1/dwGUa1yHxzg/3prRQLWZnvkv4qzV3hb0ys1 vID+DDQKOHGEQQ3k85WF0tL992JIU+den0vDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=NuuQ63sYoAk9I6R5mYzPHYeOENKfuMYngYhhG97JIcfIzyeOuc9K+x9G2Qnv3DITTh c9pl+wmg2WPmXBa5Kf+Ha3EtDk13s0wjmDn9qbMpi38w+bGMIVqAea397NEa1+cKRTHn DgwWQsNyMHgYGidrSkdM4vCpUStJzR9nw2Ce0= Received: by 10.86.93.11 with SMTP id q11mr2557335fgb.6.1247407158876; Sun, 12 Jul 2009 06:59:18 -0700 (PDT) Received: from overlord ([91.150.111.233]) by mx.google.com with ESMTPS id 4sm2972310fge.2.2009.07.12.06.59.17 (version=SSLv3 cipher=RC4-MD5); Sun, 12 Jul 2009 06:59:18 -0700 (PDT) Date: Sun, 12 Jul 2009 15:57:06 +0200 From: Aleksic Predrag To: freebsd-pf@freebsd.org Message-ID: <20090712155707.4925813c@overlord> In-Reply-To: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> References: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: pf between two lans 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: Sun, 12 Jul 2009 14:20:52 -0000 Hi all. I've got two networks setup. 192.168.0.x and 192.168.2.x and I have an freebsd firewall between the two. Problem is people on the 192.168.0.x and 192.168.2.x. cant talk to each other. tzarlazar@192.168.2.248 $ ssh -p 22 -l tzarlazar 192.168.0.246 [root@192.168.0.1 ~]# tcpdump -n -e -vv -i pflog0 port 22 tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 15:49:54.633735 rule 0/0(match): block in on vr1: (tos 0x0, ttl 64, id 18042, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.246.22 > 192.168.2.248.53047: tcp 40 [bad hdr length 0 - too short, < 20] 15:50:00.632597 rule 0/0(match): block in on vr1: (tos 0x0, ttl 64, id 27911, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.246.22 > 192.168.2.248.53047: tcp 40 [bad hdr length 0 - too short, < 20] 15:50:12.832179 rule 0/0(match): block in on vr1: (tos 0x0, ttl 64, id 36732, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.246.22 > 192.168.2.248.53047: tcp 40 [bad hdr length 0 - too short, < 20] 15:50:36.828468 rule 0/0(match): block in on vr1: (tos 0x0, ttl 64, id 27440, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.246.22 > 192.168.2.248.53047: tcp 40 [bad hdr length 0 - too short, < 20] 15:51:05.754673 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 40476, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] 15:51:05.956165 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 2615, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 32 [bad hdr length 0 - too short, < 20] 15:51:06.362872 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 21085, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] 15:51:07.176242 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 59723, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 32 [bad hdr length 0 - too short, < 20] 15:51:08.803001 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 25347, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] 15:51:12.056479 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 57211, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] 15:51:18.563581 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 64430, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] 15:51:25.021046 rule 0/0(match): block in on vr1: (tos 0x0, ttl 64, id 4002, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.246.22 > 192.168.2.248.53047: tcp 24 [bad hdr length 16 - too short, < 20] 15:51:31.577586 rule 0/0(match): block out on vr1: (tos 0x0, ttl 63, id 65157, offset 0, flags [DF], proto TCP (6), length 52) 192.168.2.248.53047 > 192.168.0.246.22: tcp 16 [bad hdr length 16 - too short, < 20] Does anyone have any ideas why this is happening? And how to fix it? I've attached my pf.conf. If you need more info, please let me know as I'm new to playing with pf and the like. intIF = "vr0" intIF2 = "vr1" extIF = "sk0" tcpPubServices = "{ 22, 80 }" torrentPort = "57277" IcmpTypes = "echoreq" myNet = "192.168.0.0/16" myLaptop = "192.168.2.248" table persist table persist file "/etc/pf.blocked.sites.conf" set block-policy drop set skip on lo0 scrub in all fragment reassemble random-id no nat on $extIF inet proto {tcp, udp} from $intIF:network to $intIF2:network no nat on $extIF inet proto {tcp, udp} from $intIF2:network to $intIF:network nat on $extIF inet proto {tcp, udp} from $intIF:network to any -> (sk0) port 1024:32255 nat on $extIF inet proto {tcp, udp} from $intIF2:network to any -> (sk0) port 32255:65535 rdr on $extIF proto { tcp, udp } from any to any port $torrentPort -> $myLaptop block log (all, to pflog0) all block drop out log (all) quick on $extIF from any to block drop in log (all) quick on $extIF from to any pass in on $extIF inet proto { tcp, udp } from any to $myLaptop port $torrentPort pass out on $extIF proto { udp, tcp } from $myLaptop port $torrentPort pass in on $extIF inet proto { udp, tcp } from any to any port 80 pass quick proto { tcp, udp } from any to any port 22 \ flags S/SA keep state \ (max-src-conn 100, max-src-conn-rate 10/3, \ overload flush global) pass out on $extIF proto tcp all modulate state flags S/SA pass out on $extIF proto { udp, icmp } all keep state pass out on $extIF proto esp from any to any keep state pass in on $intIF from $intIF:network to any keep state pass out on $intIF from any to $intIF:network keep state pass in on $intIF2 from $intIF2:network to any keep state pass out on $intIF2 from any to $intIF2:network keep state From owner-freebsd-pf@FreeBSD.ORG Mon Jul 13 04:15:39 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D8D7106564A for ; Mon, 13 Jul 2009 04:15:39 +0000 (UTC) (envelope-from rmaglasang@infoweapons.com) Received: from infoweapons.com (mail0.infoweapons.org [204.2.248.50]) by mx1.freebsd.org (Postfix) with ESMTP id D8BBB8FC13 for ; Mon, 13 Jul 2009 04:15:38 +0000 (UTC) (envelope-from rmaglasang@infoweapons.com) Received: from ([58.71.34.146]) by mail0.infoweapons.com with ESMTP id 4321444.4119991; Mon, 13 Jul 2009 00:00:14 -0400 Received: from sho2.cebu.infoweapons.com ([10.3.1.42]) by cebexch01.cebu.infoweapons.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 12:00:13 +0800 Message-ID: <4A5AB160.8040306@infoweapons.com> Date: Mon, 13 Jul 2009 12:00:32 +0800 From: Ronnel Maglasang User-Agent: Thunderbird 2.0.0.21 (X11/20090706) MIME-Version: 1.0 To: tt-list@simplenet.com References: <4A4D2010.4020908@simplenet.com> <4A4F0950.7020005@simplenet.com> <4A518B6B.1010407@simplenet.com> <4A518F07.1070209@simplenet.com> <4A5190C1.2060205@infoweapons.com> <4A582BE5.8020300@simplenet.com> In-Reply-To: <4A582BE5.8020300@simplenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 04:00:13.0661 (UTC) FILETIME=[6C9720D0:01CA036E] Cc: freebsd-pf@freebsd.org Subject: Re: Extremely simple redirect rule doesnt appear to be working 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, 13 Jul 2009 04:15:39 -0000 Tim Traver wrote: >>> am I missing something ? >>> >>> >> Yes, I believe so. >> >> rdr works only for incoming traffic. To redirect outgoing traffic >> locally you >> need to re-route the traffic using the route-to option. >> >> Try these rules. >> >> -- >> rdr pass on lo0 inet proto tcp from any to 209.131.36.158 port 80 -> >> port 80 >> pass out log quick on lo0 no state >> pass in log quick on lo0 no state >> >> pass out quick on route-to (lo0 ) >> inet proto tcp from any to 209.131.36.158 port 80 keep state >> -- >> >> > Hmmm...I tried that configuration, but it still doesn't seem to produce > anything : > > here is the exact config that I am using based on your statements : > > rdr pass on lo0 inet proto tcp from any to 209.131.36.158 port 80 -> > 209.132.4.203 port 80 > pass out log quick on lo0 no state > pass in log quick on lo0 no state > > pass out quick on fxp0 route-to 127.0.0.1 inet proto tcp from any to > 209.131.36.158 port 80 keep state > > when I reload pf, it looks like the rules and nat stuff is indeed in > place, but I get nothing when I attempt from the command line to telnet > to 209.131.36.158 on port 80 > > I was expecting it to get answered on the local 127.0.0.1 port 80 which > is indeed responding... > > any other ideas on how to accomplish this? > > Once again, I'm trying to make it so that any calls out from this box to > certain IP's get redirected to a local IP on the box, so it never > actually leaves the server... > > I have similar setup and appears to be working... Please attach the output of the following commands: ifconfig -a sockstat pfctl -sa > Thanks, > > Tim. > > > > > From owner-freebsd-pf@FreeBSD.ORG Mon Jul 13 11:07:02 2009 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B99EB106567A for ; Mon, 13 Jul 2009 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8C4728FC25 for ; Mon, 13 Jul 2009 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n6DB72Wj040718 for ; Mon, 13 Jul 2009 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n6DB71A5040712 for freebsd-pf@FreeBSD.org; Mon, 13 Jul 2009 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Jul 2009 11:07:01 GMT Message-Id: <200907131107.n6DB71A5040712@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org 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, 13 Jul 2009 11:07:03 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 34 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Jul 13 12:05:24 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB18610656DD for ; Mon, 13 Jul 2009 12:05:24 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-defer01.adhost.com (mail-defer01.adhost.com [216.211.128.176]) by mx1.freebsd.org (Postfix) with ESMTP id C47FD8FC15 for ; Mon, 13 Jul 2009 12:05:24 +0000 (UTC) (envelope-from mksmith@adhost.com) Received: from mail-in04.adhost.com (mail-in04.adhost.com [10.212.3.14]) by mail-defer01.adhost.com (Postfix) with ESMTP id 95AB178144 for ; Mon, 13 Jul 2009 04:47:32 -0700 (PDT) (envelope-from mksmith@adhost.com) Received: from ad-exh01.adhost.lan (exchange.adhost.com [216.211.143.69]) by mail-in04.adhost.com (Postfix) with ESMTP id 9DA68614F80; Mon, 13 Jul 2009 04:47:31 -0700 (PDT) (envelope-from mksmith@adhost.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2009 04:47:27 -0700 Message-ID: <17838240D9A5544AAA5FF95F8D520316065A8437@ad-exh01.adhost.lan> In-Reply-To: <20090712155707.4925813c@overlord> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: pf between two lans Thread-Index: AcoC/AiOPpojH1azQVmBRwCzzuS/0QAs0wCQ References: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> <20090712155707.4925813c@overlord> From: "Michael K. Smith - Adhost" To: "Aleksic Predrag" , Cc: Subject: RE: pf between two lans 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, 13 Jul 2009 12:05:31 -0000 Hello Aleksic: >=20 > no nat on $extIF inet proto {tcp, udp} from $intIF:network to > $intIF2:network > no nat on $extIF inet proto {tcp, udp} from $intIF2:network to > $intIF:network >=20 If nothing else, these rules won't match because the traffic isn't traversing the External Interface. no nat on $intIF2 inet proto {tcp, udp} from $intIF:network to $intIF2:network no nat on $intIF inet proto {tcp, udp} from $infIF2:network to $intIF:network Regards, Mike From owner-freebsd-pf@FreeBSD.ORG Tue Jul 14 00:47:36 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6136A106564A for ; Tue, 14 Jul 2009 00:47:36 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id DE5328FC08 for ; Tue, 14 Jul 2009 00:47:35 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: by ey-out-2122.google.com with SMTP id 9so595436eyd.3 for ; Mon, 13 Jul 2009 17:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ZA7/Z0BwmAxOugvsHfRbhsre7DceQgo7sZ6aCViXqeI=; b=QjuilCxtElf9IMekd+RTgFh1MNwSvul2rvE0hDiwN1zFTQRvJ/iHBfFtqq2l5Sz/cl QNTSaugml5oyWmq75qAN3thlSNkGki0dMymLmHu1a30XEA1gzFHdU8R8BAZAyozgvqUi makVtKfsCSZp9izaTBi0ircsnfusvD+7qbBUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=CqUbzSELF0MsM/lJUHmvuIK123BMfOBNkxr4o33hYnIjaqTCltPoRaUi51zFGsuyq8 ciB7tQdIELfVt0SmHzdj4yspe3hriUbjHALMt7GCZ6JQBKGv5NWQCtEmyghroiZ2+CL9 EXr8T9du6s5Uq37QYIq/HtlCuAB4aZq2b2RMo= MIME-Version: 1.0 Sender: allicient3141@googlemail.com Received: by 10.210.118.13 with SMTP id q13mr6980704ebc.45.1247530926922; Mon, 13 Jul 2009 17:22:06 -0700 (PDT) In-Reply-To: <17838240D9A5544AAA5FF95F8D520316065A8437@ad-exh01.adhost.lan> References: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> <20090712155707.4925813c@overlord> <17838240D9A5544AAA5FF95F8D520316065A8437@ad-exh01.adhost.lan> Date: Tue, 14 Jul 2009 01:22:06 +0100 X-Google-Sender-Auth: af30c68766af6cd0 Message-ID: <7731938b0907131722v460e5429ve4906ff822b2719@mail.gmail.com> From: Peter Maxwell To: freebsd-pf@freebsd.org, apetar@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: pf between two lans 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, 14 Jul 2009 00:47:36 -0000 Hi Aleksic, On a cursory glance, your pf.conf looks ok. The tcpdump you supplied is showing both incoming and outgoing packets being blocked which is wierd - why would there be a return packet if the initial SYN didn't get through? Can you post the output of: pfctl -s r What happens if you try things without pf loaded, and with pf loaded but a pass all ruleset? Have you got gateway_enable set in your rc.conf (I think it shows as net.inet.ip.forwarding being set to 1 in your sysctl)? Can you post the results of the same tcpdump with a larger window size ( -s 1024 ) and/or a tcpdump on the network interface itself? There's probably a simple explanation I'm not seeing, but those are the kind of things I'd try/check. Peter 2009/7/13 Michael K. Smith - Adhost : > Hello Aleksic: >> >> no nat on $extIF inet proto {tcp, udp} from $intIF:network to >> $intIF2:network >> no nat on $extIF inet proto {tcp, udp} from $intIF2:network to >> $intIF:network >> > If nothing else, these rules won't match because the traffic isn't > traversing the External Interface. > > no nat on $intIF2 inet proto {tcp, udp} from $intIF:network to > $intIF2:network > no nat on $intIF inet proto {tcp, udp} from $infIF2:network to > $intIF:network > > Regards, > > Mike > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From owner-freebsd-pf@FreeBSD.ORG Tue Jul 14 08:04:37 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E897F106564A for ; Tue, 14 Jul 2009 08:04:37 +0000 (UTC) (envelope-from mandrei05@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 478BE8FC18 for ; Tue, 14 Jul 2009 08:04:37 +0000 (UTC) (envelope-from mandrei05@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so548730fgb.12 for ; Tue, 14 Jul 2009 01:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=fcZtaQGq6x6Sya+fDfu6TXhGZJhAPDiBIVuAgixZFWI=; b=UshRX/CcpRwYwJ8YviBEvz6cud1OaYap9K1SUX7zTi46reKDshLsZt21ASlgNaLWA4 DCyarTlJwSDHhjW4I9n7GUpoT5IEEOjLnRDeNXEvBTWb3NzjM1xxqcEAdyFgHMEwkPAR jnmNqlmKF6fAyaPOEJ+2yZbMMY9TUNsiCLSrk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dwYjcP86QaRhRWXTKvpd6T0NwdkqQy5DyducBrOLbeDTvCbebDx3V5Jd7C6jRZKqx+ za+f+mdyHdqMmt4eq7Hjirbter5/FDsaKo581KugCNVIGstPHRMJ1YXO16xX/2kVix5j ODz70axPHzP3lHLdElw9qb9thseH2qcxhyduo= MIME-Version: 1.0 Received: by 10.239.157.147 with SMTP id q19mr493566hbc.61.1247557380283; Tue, 14 Jul 2009 00:43:00 -0700 (PDT) Date: Tue, 14 Jul 2009 09:43:00 +0200 Message-ID: From: Andrei Manescu To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: pftpx + pf issue 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, 14 Jul 2009 08:04:38 -0000 Hello. 2nd message to this list because from my first subscribtion I get: delivery 328: deferral: 69.147.83.52_does_not_like_recipient./Remote_host_said:_450_4.7.1_:_Recipient_address_rejected:_Service_is_unavailable/Giving_up_on_69.147.83.52./ I'm trying to setup an ftp-proxy (pftpx) with PF. I have set up the nat anchors and rdr in pf.conf. My setup: +-------------+ | INTERNET | +-------------+ | | | +-------------+ | PF | | pftpx | +-------------+ | | | +-------------+ | PRFTPD | +-------------+ The client in internet: 52.125.11.51 PF External IP address: 81.157.22.26 FTP Server: 192.168.1.10 The rules in pf added by pftpx: # pfctl -v -a `pfctl -sA -v | grep -v "pftpx$"` -sr; pfctl -vvv -a `pfctl -sA -v | grep -v "pftpx$"` -sn pass in log quick inet proto tcp from 52.125.11.51 to 192.168.1.10 port = 65186 flags S/FSRA keep state (max 1) [ Evaluations: 2 Packets: 0 Bytes: 0 States: 0 ] pass out log quick inet proto tcp from 192.168.1.10 to 192.168.1.10 port = 65186 flags S/FSRA keep state (max 1) [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @0 nat inet proto tcp from 52.125.11.51 to 192.168.1.10 port = 65186 -> 192.168.1.10 [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @0 rdr inet proto tcp from 52.125.11.51 to 81.157.22.26 port = 53266 -> 192.168.1.10 port 65186 [ Evaluations: 3 Packets: 2 Bytes: 80 States: 1 ] Proftpd ouput: domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_tls domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_rewrite domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - in dir_check_full(): path = '/', fullpath = '/usr/home/www/test_dir/'. domain.com (192.168.1.10[192.168.1.10]) - ROOT PRIVS at inet.c:237 domain.com (192.168.1.10[192.168.1.10]) - RELINQUISH PRIVS at inet.c:254 domain.com (192.168.1.10[192.168.1.10]) - Entering Extended Passive Mode (|||65186|) domain.com (192.168.1.10[192.168.1.10]) - dispatching POST_CMD command 'EPSV' to mod_sql domain.com (192.168.1.10[192.168.1.10]) - dispatching LOG_CMD command 'EPSV' to mod_sql domain.com (192.168.1.10[192.168.1.10]) - dispatching LOG_CMD command 'EPSV' to mod_log domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_tls domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_rewrite domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_ratio domain.com (192.168.1.10[192.168.1.10]) - dispatching CMD command 'LIST' to mod_ls domain.com (192.168.1.10[192.168.1.10]) - SECURITY VIOLATION: Passive connection from 52.125.11.51 rejected. FTP Client: 230 User test_user logged in Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 229 Entering Extended Passive Mode (|||53266|) 421 Service not available, remote server has closed connection. ftp> ftp> ^D PFTPX output: #1 server: 230 User test_user logged in\r\n #1 client: SYST\r\n #1 server: 215 UNIX Type: L8\r\n #1 client: FEAT\r\n #1 server: 211-Featuresn #1 server: MDTM\n #1 server: MFMT\n #1 server: MFF modify;UNIX.group;UNIX.mode;\n #1 server: MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX .mode*;UNIX.owner*;\n #1 server: REST STREAM\n #1 server: SIZE\r\n #1 server: 211 End\r\n #1 client: PWD\r\n #1 server: 257 "/" is the current directory\r\n #1 client: EPSV\r\n #1 server: 229 Entering Extended Passive Mode (|||65186|)\r\n #1 passive: client to server port 65186 via port 53266 #1 proxy: 229 Entering Extended Passive Mode (|||53266|)\r\n #1 client: LIST\r\n ^Cpftpx exiting on signal 2 #1 ending session As you can see, pftpx adds correct rules in PF, but the client's IP (52.125.11.51) isn't nated (proftpd complains: Passive connection from 52.125.11.51 rejected). The packets from the client are being redirected to ftp server, but the nat rule isn't applied to them. First part of my pf.conf: ext_if1="xl0" # replace with actual external interface name i.e., dc0 int_if1="dc0" # replace with actual internal interface name i.e., dc1 WEB_HOST="192.168.1.10" SMTP_HOST="192.168.1.11" internal_net1="192.168.1.0/24" external_addr1="81.157.22.26" icmp_types="echoreq" set optimization normal set block-policy drop set state-policy if-bound set skip on lo0 scrub all reassemble tcp scrub in all fragment reassemble scrub out all random-id nat-anchor "pftpx/*" rdr on {$ext_if1,$int_if1} proto tcp from any to {$ext_adr1, $ext_adr2, $external_addr1} port 80 -> 192.168.1.10 port 80 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 6122 -> 192.168.1.10 port 22 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 6123 -> 192.168.1.11 port 22 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 25 -> 192.168.1.11 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 993 -> 192.168.1.11 rdr on {$ext_if1,$int_if1} proto tcp from any to {$ext_adr1, $external_addr1} port 443 -> 192.168.1.11 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 33890 -> 192.168.1.1 port 33890 rdr-anchor "pftpx/*" rdr pass on $ext_if1 proto tcp from any to $external_addr1 port 21 -> $external_addr1 port 8021 nat on $ext_if1 inet from $internal_net1 to any -> $ext_if1 block drop log-all all block drop in log quick from block drop in log quick from block drop in log quick from any os {SCO, NMAP} to any pass out quick on $gre_if from any to 192.168.25.0/24 flags S/SA keep state queue ssh pass in quick on $gre_if from 192.168.25.0/24 to any flags S/SA keep state queue ssh block drop in log quick proto tcp from any to any flags FUP/FUP block drop in log quick proto tcp from any to any flags SAFRPU/SAFRPU block drop in log quick proto tcp from any to any flags SAFRU/SAFRU block drop in log quick proto tcp from any to any flags SF/SF block drop in log-all quick proto tcp from any to any flags SR/SR block drop in log-all quick proto tcp from any to any flags SF/SFRA block drop in log-all quick proto tcp from any to any flags /SFRA antispoof log quick for $ext_if1 inet antispoof log quick for lo0 inet Any hints on why the nat rule added by pftpx isn't evaluated even ([ Evaluations: 0)? From owner-freebsd-pf@FreeBSD.ORG Tue Jul 14 10:47:20 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F11C106566C for ; Tue, 14 Jul 2009 10:47:20 +0000 (UTC) (envelope-from andrei.manescu@ivorde.ro) Received: from mail.ivorde.ro (ivorde.ro [82.137.33.36]) by mx1.freebsd.org (Postfix) with ESMTP id B050F8FC18 for ; Tue, 14 Jul 2009 10:47:19 +0000 (UTC) (envelope-from andrei.manescu@ivorde.ro) Received: (qmail 4186 invoked by uid 0); 14 Jul 2009 10:37:25 +0300 Received: from mail.ivorde.ro (andrei.manescu@ivorde.ro@mail.ivorde.ro) by mail.ivorde.ro (envelope-from , uid 1001) with qmail-scanner-2.06st (clamdscan: 0.94.2/8872. spamassassin: 3.2.5. perlscan: 2.05st. Clear:RC:1(192.168.1.11):. Processed in 1.978057 secs); 14 Jul 2009 07:37:25 -0000 Received: from mail.ivorde.ro (andrei.manescu@ivorde.ro@192.168.1.11) by mail.ivorde.ro with SMTP; 14 Jul 2009 10:37:22 +0300 Received: from 62.168.56.1 (SquirrelMail authenticated user andrei.manescu@ivorde.ro) by mail.ivorde.ro with HTTP; Tue, 14 Jul 2009 09:37:22 +0200 (CEST) Message-ID: <2b4d7fa39913928c4086e754656e9f7e.squirrel@mail.ivorde.ro> Date: Tue, 14 Jul 2009 09:37:22 +0200 (CEST) From: "Andrei Manescu - Ivorde" To: freebsd-pf@freebsd.org User-Agent: SquirrelMail/1.4.17 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: pftpx + pf issue X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: andrei.manescu@ivorde.ro 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, 14 Jul 2009 10:47:20 -0000 Hello. I'm trying to setup an ftp-proxy (pftpx) with PF. I have set up the nat anchors and rdr in pf.conf. My setup: +-------------+ | INTERNET | +-------------+ | | | +-------------+ | PF | | pftpx | +-------------+ | | | +-------------+ | PRFTPD | +-------------+ The client in internet: 52.125.11.51 PF External IP address: 81.157.22.26 FTP Server: 192.168.1.10 The rules in pf added by pftpx: # pfctl -v -a `pfctl -sA -v | grep -v "pftpx$"` -sr; pfctl -vvv -a `pfctl -sA -v | grep -v "pftpx$"` -sn pass in log quick inet proto tcp from 52.125.11.51 to 192.168.1.10 port = 65186 flags S/FSRA keep state (max 1) [ Evaluations: 2 Packets: 0 Bytes: 0 States: 0 ] pass out log quick inet proto tcp from 192.168.1.10 to 192.168.1.10 port = 65186 flags S/FSRA keep state (max 1) [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @0 nat inet proto tcp from 52.125.11.51 to 192.168.1.10 port = 65186 -> 192.168.1.10 [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] @0 rdr inet proto tcp from 52.125.11.51 to 81.157.22.26 port = 53266 -> 192.168.1.10 port 65186 [ Evaluations: 3 Packets: 2 Bytes: 80 States: 1 ] Proftpd ouput: domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_tls domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_rewrite domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching CMD command 'EPSV' to mod_core domain.com (192.168.1.10[192.168.1.10]) - in dir_check_full(): path = '/', fullpath = '/usr/home/www/test_dir/'. domain.com (192.168.1.10[192.168.1.10]) - ROOT PRIVS at inet.c:237 domain.com (192.168.1.10[192.168.1.10]) - RELINQUISH PRIVS at inet.c:254 domain.com (192.168.1.10[192.168.1.10]) - Entering Extended Passive Mode (|||65186|) domain.com (192.168.1.10[192.168.1.10]) - dispatching POST_CMD command 'EPSV' to mod_sql domain.com (192.168.1.10[192.168.1.10]) - dispatching LOG_CMD command 'EPSV' to mod_sql domain.com (192.168.1.10[192.168.1.10]) - dispatching LOG_CMD command 'EPSV' to mod_log domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_tls domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_rewrite domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_core domain.com (192.168.1.10[192.168.1.10]) - dispatching PRE_CMD command 'LIST' to mod_ratio domain.com (192.168.1.10[192.168.1.10]) - dispatching CMD command 'LIST' to mod_ls domain.com (192.168.1.10[192.168.1.10]) - SECURITY VIOLATION: Passive connection from 52.125.11.51 rejected. FTP Client: 230 User test_user logged in Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 229 Entering Extended Passive Mode (|||53266|) 421 Service not available, remote server has closed connection. ftp> ftp> ^D PFTPX output: #1 server: 230 User test_user logged in\r\n #1 client: SYST\r\n #1 server: 215 UNIX Type: L8\r\n #1 client: FEAT\r\n #1 server: 211-Featuresn #1 server: MDTM\n #1 server: MFMT\n #1 server: MFF modify;UNIX.group;UNIX.mode;\n #1 server: MLST modify*;perm*;size*;type*;unique*;UNIX.group*;UNIX .mode*;UNIX.owner*;\n #1 server: REST STREAM\n #1 server: SIZE\r\n #1 server: 211 End\r\n #1 client: PWD\r\n #1 server: 257 "/" is the current directory\r\n #1 client: EPSV\r\n #1 server: 229 Entering Extended Passive Mode (|||65186|)\r\n #1 passive: client to server port 65186 via port 53266 #1 proxy: 229 Entering Extended Passive Mode (|||53266|)\r\n #1 client: LIST\r\n ^Cpftpx exiting on signal 2 #1 ending session As you can see, pftpx adds correct rules in PF, but the client's IP (52.125.11.51) isn't nated (proftpd complains: Passive connection from 52.125.11.51 rejected). The packets from the client are being redirected to ftp server, but the nat rule isn't applied to them. First part of my pf.conf: ext_if1="xl0" # replace with actual external interface name i.e., dc0 int_if1="dc0" # replace with actual internal interface name i.e., dc1 WEB_HOST="192.168.1.10" SMTP_HOST="192.168.1.11" internal_net1="192.168.1.0/24" external_addr1="81.157.22.26" icmp_types="echoreq" set optimization normal set block-policy drop set state-policy if-bound set skip on lo0 scrub all reassemble tcp scrub in all fragment reassemble scrub out all random-id nat-anchor "pftpx/*" rdr on {$ext_if1,$int_if1} proto tcp from any to {$ext_adr1, $ext_adr2, $external_addr1} port 80 -> 192.168.1.10 port 80 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 6122 -> 192.168.1.10 port 22 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 6123 -> 192.168.1.11 port 22 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 25 -> 192.168.1.11 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 993 -> 192.168.1.11 rdr on {$ext_if1,$int_if1} proto tcp from any to {$ext_adr1, $external_addr1} port 443 -> 192.168.1.11 rdr on $ext_if1 proto tcp from any to {$ext_adr1, $external_addr1} port 33890 -> 192.168.1.1 port 33890 rdr-anchor "pftpx/*" rdr pass on $ext_if1 proto tcp from any to $external_addr1 port 21 -> $external_addr1 port 8021 nat on $ext_if1 inet from $internal_net1 to any -> $ext_if1 block drop log-all all block drop in log quick from block drop in log quick from block drop in log quick from any os {SCO, NMAP} to any pass out quick on $gre_if from any to 192.168.25.0/24 flags S/SA keep state queue ssh pass in quick on $gre_if from 192.168.25.0/24 to any flags S/SA keep state queue ssh block drop in log quick proto tcp from any to any flags FUP/FUP block drop in log quick proto tcp from any to any flags SAFRPU/SAFRPU block drop in log quick proto tcp from any to any flags SAFRU/SAFRU block drop in log quick proto tcp from any to any flags SF/SF block drop in log-all quick proto tcp from any to any flags SR/SR block drop in log-all quick proto tcp from any to any flags SF/SFRA block drop in log-all quick proto tcp from any to any flags /SFRA antispoof log quick for $ext_if1 inet antispoof log quick for lo0 inet Any hints on why the nat rule added by pftpx isn't evaluated even ([ Evaluations: 0)? From owner-freebsd-pf@FreeBSD.ORG Tue Jul 14 11:27:15 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAC441065673 for ; Tue, 14 Jul 2009 11:27:15 +0000 (UTC) (envelope-from apetar@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id F34188FC16 for ; Tue, 14 Jul 2009 11:27:14 +0000 (UTC) (envelope-from apetar@gmail.com) Received: by fxm24 with SMTP id 24so2425716fxm.43 for ; Tue, 14 Jul 2009 04:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=OMCBc5noMMifCIddyA5MWRoMcbvrCz2tfRyis+0VJHg=; b=VU03Fam1ETdPTHtvqC/CNtl6zBvqKR6cSK+27gOFB7mpomg02OkGLq0LtI5JLrsBih MhswkVOW2DgEotNz3EvAXGLPnKrD29+xJ17HlwRnclqrnAtSiEPoSCZkWrQvZAZoGq2J nHGsSc+g+vTFPRdPrNnByQQjI2fcoi9BVJJ2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=EV0lYeyjBDAJNH7E8HJQN408d4gWLacuX6frbS7WmyaLf7yLiw4F2tWC5M2vtoFOd5 x8BhjOBWeZTULL+A6bdeAxeWxFcZvf6Xqm/IPYr4otU0dAI0GSi9+ynjpbLtjTiuH6QK qeru3sKevZDee2mS2UF1QFDVuVQy/CMIWJeTg= Received: by 10.86.35.18 with SMTP id i18mr4113574fgi.8.1247570834071; Tue, 14 Jul 2009 04:27:14 -0700 (PDT) Received: from overlord ([93.87.172.208]) by mx.google.com with ESMTPS id 12sm6307040fgg.19.2009.07.14.04.26.52 (version=SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 04:27:12 -0700 (PDT) Date: Tue, 14 Jul 2009 13:24:30 +0200 From: Aleksic Predrag To: Peter Maxwell , freebsd-pf@freebsd.org Message-ID: <20090714132430.75bb46c8@overlord> In-Reply-To: <7731938b0907131722v460e5429ve4906ff822b2719@mail.gmail.com> References: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> <20090712155707.4925813c@overlord> <17838240D9A5544AAA5FF95F8D520316065A8437@ad-exh01.adhost.lan> <7731938b0907131722v460e5429ve4906ff822b2719@mail.gmail.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/76/3bukzBOcdNv5+7ZTa1p+" Cc: Subject: Re: pf between two lans 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, 14 Jul 2009 11:27:16 -0000 --MP_/76/3bukzBOcdNv5+7ZTa1p+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tue, 14 Jul 2009 01:22:06 +0100 Peter Maxwell wrote: > Can you post the output of: pfctl -s r # pfctl -sr scrub in all random-id fragment reassemble block drop log (all) all block drop in on sk0 inet proto icmp all icmp-type echoreq block drop out log (all) quick on sk0 from any to block drop in log (all) quick on sk0 from to any pass in on sk0 inet proto tcp from any to 192.168.2.248 port = 57277 flags S/SA keep state pass in on sk0 inet proto udp from any to 192.168.2.248 port = 57277 keep state pass out on sk0 inet proto udp from 192.168.2.248 port = 57277 to any keep state pass out on sk0 inet proto tcp from 192.168.2.248 port = 57277 to any flags S/SA keep state pass in on sk0 inet proto udp from any to any port = http keep state pass in on sk0 inet proto tcp from any to any port = http flags S/SA keep state pass in on sk0 proto udp from any to any port = 2706 keep state pass in on sk0 proto tcp from any to any port = 2706 flags S/SA keep state pass quick proto tcp from any to any port = ssh flags S/SA keep state (source-track rule, max-src-conn 10, max-src-conn-rate 1/3, overload flush global, src.track 3) pass quick proto udp from any to any port = ssh keep state (source-track rule, max-src-conn 10, max-src-conn-rate 1/3, overload flush global, src.track 3) pass out on sk0 proto tcp all flags S/SA modulate state pass out on sk0 proto udp all keep state pass out on sk0 proto icmp all keep state pass out on sk0 proto esp all keep state pass in on vr0 inet from 192.168.2.0/24 to any flags S/SA keep state pass out on vr0 inet from any to 192.168.2.0/24 flags S/SA keep state pass in on vr1 inet from 192.168.0.0/24 to any flags S/SA keep state pass out on vr1 inet from any to 192.168.0.0/24 flags S/SA keep state Should i replace netmask to /16 in last four rules? > What happens if you try things without pf loaded > and with pf loaded but a pass all ruleset? With pf loaded i can open almost anything but not ssh connection. I can ping, browse shares and printers between lans. Without pf loaded i can do all that and ssh. Yesterday i changed default ssh port on remote box and it let me in with the same pf rules loaded. Now, I'm also suspicious about remote box, it is CentOS box with untouched config files, maybe SELinux is preventing ssh login. > Have you got gateway_enable set in your rc.conf (I think it shows as > net.inet.ip.forwarding being set to 1 in your sysctl)? sysctl -a | grep net.inet.ip.forwarding net.inet.ip.forwarding: 1 > Can you post the results of the same tcpdump with a larger window size > ( -s 1024 ) and/or a tcpdump on the network interface itself? see attachment > > > > > > > 2009/7/13 Michael K. Smith - Adhost : > > Hello Aleksic: > >> > >> no nat on $extIF inet proto {tcp, udp} from $intIF:network to > >> $intIF2:network > >> no nat on $extIF inet proto {tcp, udp} from $intIF2:network to > >> $intIF:network > >> > > If nothing else, these rules won't match because the traffic isn't > > traversing the External Interface. > > > > no nat on $intIF2 inet proto {tcp, udp} from $intIF:network to > > $intIF2:network > > no nat on $intIF inet proto {tcp, udp} from $infIF2:network to > > $intIF:network > > > > Regards, > > > > Mike > > _______________________________________________ > > freebsd-pf@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > > To unsubscribe, send any mail to > > "freebsd-pf-unsubscribe@freebsd.org" > > --MP_/76/3bukzBOcdNv5+7ZTa1p+ Content-Type: application/octet-stream; name=vr1 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=vr1 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAYmZcSoXvBwCfAAAAnwAAAAAFXWpMvQDgGP87xwgARQAA kQAAQABAEXD5wKgA9sP8Q8io2G+LAH0IUpCXAhMX7cQQVqooZ7bGHffEYI4tY+yMvpqT2SWt1s6T yRylGXCYJRB1jviHZ4gfJVbvL3fIwiMcIXQvOnCH0C7k+I4QgGLphjUU0esgOH0K5QeL/1TLU+wl yV8Hhxq2mJk2z41Vb2HphZRlax7kZFZCbY57ZmJmXErg8gcATgAAAE4AAAAABV1qTL0A4Bj/O8cI AEUAAEAAAEAAQBGh2cCoAPZEkJKlqNgHmAAsLRuQmQJvAJxlaLe4XXwruXtWUwQ/+pSqfZQYav5o uwOX0h4+pr9iZlxKJfMHAEoAAABKAAAAAAVdaky9AOAY/zvHCABFAAA8AABAAEARZn/AqAD2X5yy 96jYDgkAKLRnkJsCh9OgUkAbZvHgu3INRUIiCvYS1D6CYGGucD04RqdiZlxKP9cIAFgAAABYAAAA AOAY/zvHAAVdaky9CABFAABKHssAAHIRYHXD/EPIwKgA9m+LqNgANj4zCtwCcs/+3AGA5zP0tzD/ SW0wjYXErQxB92Fth+SPerj3U4Tj+fj2PiO6HWp9eGJmXEqL2wgASgAAAEoAAAAA4Bj/O8cABV1q TL0IAEUAADxetEAAPwZXycCoAvjAqAD22nkAFiLRvA8AAAAAoAIW0JtDAAACBAW0BAIICgXJUXUA AAAAAQMDBmJmXEpD3AgASgAAAEoAAAAABV1qTL0A4Bj/O8cIAEUAADwAAEAAQAa1fcCoAPbAqAL4 ABbaeRZzORQi0bwQoBIWoHaaAAACBAW0BAIICgxByQEFyVF1AQMDBGJmXEozXgkA/gEAAP4BAAAA 4Bj/O8cABV1qTL0IAEUAAfDKggAAchGoSF+csvfAqAD2Dgmo2AHces9XGQLfjKYRkh11Pjf3JxCM ZBPcxsszPlBnSVUAIWfyPWgTUGlQswjC63UI7Fjn57SKmDliCghn8j4iD5sa6nH6aXt3W4w2JGcM xppdErbg0DblwBIH7K2De6hxMIP5Gfy5eJfYwreWSWw/9fkNQHW9JdvsXOgkt/+zurwDCyyyp9Z4 9A93sdiYm/ubHinVEVkNTsdGwBWc0mO0Ut0aV66bXKGqoWb+eU33xfVocf8c+YlXZPe00xzAIxay QTwrAUcAP+pSo8lOMiwfuHitzf1dM+66IXERdnsmsy4kifDU4XZJy6V0Ujl2xmxORo56cHtxolVm jAH4nHBeyl2jsEfOLH1dE5MGAaj6laLsWmRHgOkd07K323+d7vtlyprl1rLKBtPGC//8blR93ADF i4/vMsq86mrZ6Z8VOcX7f8D5tWQZpvF481Zp7Yl6BI4aFLzLZEE/EN3liERDne2ZyXi8G4yPd/pC CVKuhmwLHexSyoJiG/L9ZF6p9HBgRrqegtNYEv0ZmHGHWeeBPtowWcUknXXVOhaSe8xh8zNIjTF/ MMad6X42lkd6rT8Q7h1wgFRB5AdneV+Hz1gZ545v0+krl5Z1wlyhU6HL2oaf8ZkpH3qbrD9iZlxK jW4JAJoAAACaAAAAAAVdaky9AOAY/zvHCABFAACMAABAAEAR03nAqAD21MjQgKjYoWUAeCQMkJ0C I+3OG1CN6tv+Dvr0/NsltvgcG1RPnfHzjkS1ieMidD/mCTOuQx7fBr9qwiGTeYwLJeYDAmQ6b4h5 MkauqyEjVt25fqY6kyedrn9Fjw/PrauSf7eVxY8by6aMmdhyqhw/5amqpOqJV96/x7QQ3GJmXEph BAoAPgAAAD4AAAAA4Bj/O8cABV1qTL0IAEUAADAvtQAAdBGwINTI0IDAqAD2oWWo2AAcHw4ECAK2 iYgfN8cfwuHs3vMN9v0fGGJmXEqE1AsAPAAAADwAAAAA4Bj/O8cABV1qTL0IAEUAAC4o9AAAZxGR 90SQkqXAqAD2B5io2AAaj5NWoQJF5Kibs1XoaReA1pxQcXhiZlxKOtsLAKAAAACgAAAAAAVdaky9 AOAY/zvHCABFAACSAABAAEARoZLAqAD2zdMJV6jYDdUAfvxBkJ8CpwCtEB5qia/zPgE7VJV2PNqU zEQStCVC6xuPB3G6xKdAZvY+wZ46zm5E0s0/m/hPqf0X8JR75ModKRhYn3qNBZtvunoIeJZ6x+nq tBZRjdREGQdVUwc1kIImUEgmiNLrEvbJEWCPFPGzxa4JW3D35GjXq2JmXErBsw4APgAAAD4AAAAA 4Bj/O8cABV1qTL0IAEUAADDQsQAAbhHjQs3TCVfAqAD2DdWo2AAcLtNTWwIrt/v3TQdMoiS3DaA0 ijzxrGVmXErYBQoASgAAAEoAAAAABV1qTL0A4Bj/O8cIAEUAADwAAEAAQAa1fcCoAPbAqAL4ABba eRZzORQi0bwQoBIWoGqVAAACBAW0BAIICgxB1QYFyVF1AQMDBGZmXEpP0gsA0QAAANEAAAD///// //8A4Bj/O8cIAEUAAMMAAEAAQBG25MCoAPbAqAD/AncCdwCvh3s5MDE2IDMgaXBwOi8vMTkyLjE2 OC4wLjI0Njo2MzEvcHJpbnRlcnMvSFBfTGFzZXJKZXRfUDEwMDYgIiIgIkFkZGVkIGJ5IEhBTCIg IkhQIExhc2VySmV0IFAxMDA2IEZvb21hdGljL2ZvbzJ4cXggKHJlY29tbWVuZGVkKSIgam9iLXNo ZWV0cz1ub25lLG5vbmUgbGVhc2UtZHVyYXRpb249MzAwCmdmXEog7QcAPAAAADwAAAAABV1qTL0A 4Bj/O8cIBgABCAAGBAABAOAY/zvHwKgA9gAAAAAAAMCoAAEAAAAAAAAAAAAAAAAAAAAAAABnZlxK MO0HADwAAAA8AAAAAOAY/zvHAAVdaky9CAYAAQgABgQAAgAFXWpMvcCoAAEA4Bj/O8fAqAD2AAAA AAAAAAAAAAAAAAAAAAAAa2ZcSlYBCgBKAAAASgAAAAAFXWpMvQDgGP87xwgARQAAPAAAQABABrV9 wKgA9sCoAvgAFtp5FnM5FCLRvBCgEhagUyUAAAIEBbQEAggKDEHsdgXJUXUBAwMEdmZcSlvvCABG AAAARgAAAAAFXWpMvQDgGP87xwgARQAAOOojQABABstdwKgA9sCoAvgAi8g+tcL4V5Fpl4WAGAK5 dE8AAAEBCAoMQhcpBcUsZoUAAAB3ZlxKgjEHAE4BAABOAQAAAAVdaky9AOAY/zvHCABFAAFAEr1A AEAGcLjAqAD2W5KZEraISjUcc54bHG7u8YAYB6K0QwAAAQEICgxCGp8AGPMPtWpJ0UQtxQBeTQc9 /KdYgIbqrNBbOUUs+2iIOwW4gv6JtZJLDpNo3nx2OAA/dBdeULiii2ZpGk9ky18L3RhgObFO0mxi 143iNkdTJxLuaCLUSxs3AZg5e5aLIHQt1uL4/GF8owF8JKlZSosl/5rT6TRFkM5LF9h3SfqUeae8 D52nKVtWSd4+vhi9De8UjH32X1wuYbkSmca6rdIHqdcIaSyvni3aRhwiiKz53r9xNibqaPkPVkKn x+S/pLJi3+Zk/TZl/8xfhoeaiW8ezrQqINdLmdWHqkTf3/lsHAQ5ocL+KrKMvG9NVD1m+AXhKSDo a/dXL37B70QHi7OPsNecf6QEKudPojJ2Rgct8HdmXEo/EgoARgAAAEYAAAAA4Bj/O8cABV1qTL0I AEUAADjAnUAAcwaQ31uSmRLAqAD2SjW2iBxu7vEcc58ngBg8NClxAAABAQgKABj1ZwxCGp/f25bT d2ZcSuMSCgBCAAAAQgAAAAAFXWpMvQDgGP87xwgARQAANBK+QABABnHDwKgA9luSmRK2iEo1HHOf Jxxu7vWAEAei0/0AAAEBCAoMQhtcABj1Z3dmXEoSDQ0ASgAAAEoAAAAABV1qTL0A4Bj/O8cIAEUA ADwAAEAAQAa1fcCoAPbAqAL4ABbaeRZzORQi0bwQoBIWoCN8AAACBAW0BAIICgxCHB8FyVF1AQMD BHhmXErI9gQA0QAAANEAAAD///////8A4Bj/O8cIAEUAAMMAAEAAQBG25MCoAPbAqAD/AncCdwCv wusyOTAxNiAzIGlwcDovLzE5Mi4xNjguMC4yNDY6NjMxL3ByaW50ZXJzL1AxMDA2ICJDZW50T1Mi ICJIUCBMYXNlcmpldCBQMTAwNiIgIkhQIExhc2VySmV0IFAxMDA2IEZvb21hdGljL2ZvbzJ4cXgg KHJlY29tbWVuZGVkKSIgam9iLXNoZWV0cz1ub25lLG5vbmUgbGVhc2UtZHVyYXRpb249MzAwCoJm XErDlgUARgAAAEYAAAAABV1qTL0A4Bj/O8cIAEUAADjV+kAAQAbfhsCoAPbAqAL4Ab3P7b84S82W scNkgBgkqQwsAAABAQgKDEJFMAXErZ+FAAAAhGZcSpeVDgCyAQAAsgEAAAAFXWpMvQDgGP87xwgA RRABpFmmQABABlpfwKgA9sCoAvgAIaycBeJ3E8fAJGOAGAO8EWgAAAEBCAoMQk9OBcYQIRiv0kSk YnLtUOIxBx7hKeSvi+SoVSeAMLa7rECzZO3L5BSBUSACnsNuiZoCKxWJcHjen0T964npszLbCTJY Rwq2W+ifesTZKofNDtI3ncpstCVICCxEwebGKe+M48iNyriKmiR6XlyA5r3zmgqh8ulSpmyNU4Fa OisNQ/e/zi2K6C+xx0MTUJ660O5kxkxhgzRxQXAK9bD+XcWrEde246qUcWBOH1Fc9I+AlzopJjHC DyfTP8/DUFDdyqX4Ttdt85dWiY5F45YuPVXVSku2Esk61+4ov3qtOBrylwcSgQosj+wmvtoQ6FLR FdYX2Hvtl6qtQXsvBjT3VsPbeVYfoF8HZKoLFdrSqQfOOtbFw1Wib6UoAd1xLGyYYKKer7/liKqt Dy1QgxX0WqtGokmwHMP9w83lrh55qb7WBNw/W6OYqDNqs77ToDdDXCQh9vCa7bMoAHB0yLx30Xmy gFYdXoZli3cu9hbrAaUuz8E416uzhmZcSm/xBADRAAAA0QAAAP///////wDgGP87xwgARQAAwwAA QABAEbbkwKgA9sCoAP8CdwJ3AK+HezkwMTYgMyBpcHA6Ly8xOTIuMTY4LjAuMjQ2OjYzMS9wcmlu dGVycy9IUF9MYXNlckpldF9QMTAwNiAiIiAiQWRkZWQgYnkgSEFMIiAiSFAgTGFzZXJKZXQgUDEw MDYgRm9vbWF0aWMvZm9vMnhxeCAocmVjb21tZW5kZWQpIiBqb2Itc2hlZXRzPW5vbmUsbm9uZSBs ZWFzZS1kdXJhdGlvbj0zMDAKiWZcSlIkDgBGAAAARgAAAAAFXWpMvQDgGP87xwgARQAAOBGjQABA BqPewKgA9sCoAvgBven9tjhABpvCMMeAGAcs/vAAAAEBCAoMQmK6BcVDEIUAAACJZlxKmjsOAEYA AABGAAAAAAVdaky9AOAY/zvHCABFAAA4uvZAAEAG+orAqAD2wKgC+AG96f61i+KKnR08hoAYD0lH 2QAAAQEICgxCYsAFxUMShQAAAIpmXErdyQwAogAAAKIAAAAABV1qTL0A4Bj/O8cIAEUAAJQAAEAA QBFmvMCoAPZevbNBqNhpmwCAkqSQogJxZKhBnPz3yhEu+Kzc7LexsSWYqZw0kBTrCdaGGXG9ndZs o5QBcIWxZiBQ0yMIur+z20rNspbtBUcRb87BUzvTgQ6Ruw0Yw6iak5hXh6g3DtAYk+boP9e05TBb IwQHihq7qijk2fCcRG6aMqTlVKdiaGdccD2KZlxKQs0MAEwAAABMAAAAAAVdaky9AOAY/zvHCABF AAA+AABAAEAREQ/AqAD228iMOajYoMYAKgY7kKQCkmdLfoVKCyAdp0UrV3V3tbfojPDUBB/h7HVt JPFLV4pmXErqzQwATgAAAE4AAAAABV1qTL0A4Bj/O8cIAEUAAEAAAEAAQBFWC8CoAPbb/UcGqNjI tgAsqCqQpgLHCxxXGzMzxtvpA3XQOG92D3EdN+2P7fY/HN0vydVVsv6LZlxKwcABADwAAAA8AAAA AOAY/zvHAAVdaky9CABFAAAudeUAAG4RrTnbyIw5wKgA9qDGqNgAGjSEGnsCkaU9Q5R/l8mwChYw OM6Bi2ZcSinGAQCfAAAAnwAAAAAFXWpMvQDgGP87xwgARQAAkQAAQABAEQ2gwKgA9s68nGGo2Aiq AH3gfJCoAhCtXxzWgLqpwdmHa7/Phx9k1l6TthBDpplu5cWQP9Ws0E08F++EDIYxPEhIkFkR8kaU CBNzVMJ/pwWO3aZmFraQkBMkCEp/32IKmybNIMqjaukwSfKw3AwNyHSlTlWyxsszP0u6K3emm1Vp +eiU1uoRGotmXEpUeAMAPAAAADwAAAAA4Bj/O8cABV1qTL0IAEUAAC4XyQAAbBFSVNv9RwbAqAD2 yLao2AAaA7wN8gJnyL1JsRTIFdlCHU5mx9+LZlxKbH4DAJkAAACZAAAAAAVdaky9AOAY/zvHCABF AACLAABAAEARO0XAqAD2g+W5majYYyoAd6qskKoCh8XX3XHT8EHpXSz2iwDU6nPHclKXg+6ufmst L3dLbAIsLDetkmiVJKbR92JZBV3+qcO2fw9+icDk/oVkoBbuDQRrz4fIkkE28SnbRwabrYsNJyE6 Q77IHTRP9rqiKhDLC0q2mhVETvjByyRii2ZcSj0BBwBPAAAATwAAAADgGP87xwAFXWpMvQgARQAA QTa7AABvEUFUXr2zQcCoAPZpm6jYAC1UAVaSAueuWaThJomMyluREvKgGV5kIf/p2xtugCie4hWx s//ocgCNZlxKciACAJ8AAACfAAAAAAVdaky9AOAY/zvHCABFAACRAABAAEARDaDAqAD2zrycYajY CKoAfXxFkKgCnUFXataAuqlbRLarp4FZVP1kVYVsuN4Kehitu33Fz9oXLIkZuo0Uq2EV34zczbr+ AftkdF15dNyDtocsKXmNsugAtSifhsK/KSD3am0taHmAQdqd4wX0/mctME9kZD9N77T1A3q4QiKp fbH8c0CLo3jrjWZcSsaqAwCZAAAAmQAAAAAFXWpMvQDgGP87xwgARQAAiwAAQABAETtFwKgA9oPl uZmo2GMqAHcwWJCqApYtpFNx0/BBFvm/JWHYHuBeJHp0zzLyd9QxwTdkHEKtJvAuvpiYMgbeDeXC LdQh5FQF1MHCaBh7zR5/3wExTLQnXq8h0zCpI9EoPLJTuSdIE5Y/IMpRQb1+Tt4D12ucn9bAzymZ FyiyPJyRwo9mXEq9/gwASgAAAEoAAAAABV1qTL0A4Bj/O8cIAEUAADwAAEAAQAa1fcCoAPbAqAL4 ABbaeRZzORQi0bwQoBIWoMW7AAACBAW0BAIICgxCed8FyVF1AQMDBJFmXEoHmwIAnwAAAJ8AAAAA BV1qTL0A4Bj/O8cIAEUAAJEAAEAAQBENoMCoAPbOvJxhqNgIqgB9FbyQqAI4OA/o1oC6qRHWELU5 ++/pnkdKwPiOJC0bKweRdLowuU+HbDW5mazelL9628ZY55si5pJb/yrx47ps40zhZtpH9lTGBdra zKE3gG0EzQrgfAySGZsHGkhfoRG/YOb9YKiX8BfVM65j0rZRIM2ZupE9YEuRZlxK9CQEAJkAAACZ AAAAAAVdaky9AOAY/zvHCABFAACLAABAAEARO0XAqAD2g+W5majYYyoAd0JbkKoC7ZvHOXHT8EF5 VjXmOJToe68npjjTUWW0AEH685DWIQUdyMlzqmz5k0RiBp3OBF/OQRicgYi8U4qKxgrdGnfmfsTL UHc38bodFKcnN9h3akaw5uoIDky59gzsRbH7gLMtcJ8tNpyBd71jsGK0lGZcSiO0DgA8AAAAPAAA AAAFXWpMvQDgGP87xwgGAAEIAAYEAAEA4Bj/O8fAqAD2AAAAAAAAwKgAAQAAAAAAAAAAAAAAAAAA AAAAAJRmXEo1tA4APAAAADwAAAAA4Bj/O8cABV1qTL0IBgABCAAGBAACAAVdaky9wKgAAQDgGP87 x8CoAPYAAAAAAAAAAAAAAAAAAAAAAACXZlxKEucEANEAAADRAAAA////////AOAY/zvHCABFAADD AABAAEARtuTAqAD2wKgA/wJ3AncAr8LrMjkwMTYgMyBpcHA6Ly8xOTIuMTY4LjAuMjQ2OjYzMS9w cmludGVycy9QMTAwNiAiQ2VudE9TIiAiSFAgTGFzZXJqZXQgUDEwMDYiICJIUCBMYXNlckpldCBQ MTAwNiBGb29tYXRpYy9mb28yeHF4IChyZWNvbW1lbmRlZCkiIGpvYi1zaGVldHM9bm9uZSxub25l IGxlYXNlLWR1cmF0aW9uPTMwMAo= --MP_/76/3bukzBOcdNv5+7ZTa1p+ Content-Type: application/octet-stream; name=pflog0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=pflog0 1MOyoQIABAAAAAAAAAAAAP//AAB1AAAAsWRcShfHBgB0AAAAdAAAAD0CAQBzazAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAAAAAAVzIAAAIAAABFAAA0WgpAAD8G qi3AqAECSn0rZWsFAFBqd4hVJjuCfYARAOK9ZAAAAQEICgXHVecEDxpRsWRcSnb5CgB0AAAAdAAA AD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAAAAAA VzIAAAIAAABFAAA0wTJAAD8GQwXAqAECSn0rZWf/AFBqd4hVJjuCfYARAOLAFwAAAQEICgXHVjoE DxpRsmRcSrAoBAB0AAAAdAAAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD//////////6CGAQAAAAAAVzIAAAIAAABFAAA0h15AAD8GfNnAqAECSn0rZRrGAFBqd4hVJjuC fYARAOIMqwAAAQEICgXHVuAEDxpRs2RcSvfJBQB0AAAAdAAAAD0CAQBzazAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAAAAAAVzIAAAIAAABFAAA0gjVAAD8GggLA qAECSn0rZU3eAFBqd4hVJjuCfYARAOLYRgAAAQEICgXHWCwEDxpRtWRcSoELCQB0AAAAdAAAAD0C AQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAAAAAAVzIA AAIAAABFAAA0mW1AAD8GasrAqAECSn0rZXKxAFBqd4hVJjuCfYARAOKw2wAAAQEICgXHWsQEDxpR uGRcSq/6BACbAAAAmwAAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ /////////6CGAQAAAAAAVzIAAAIAAABFAABb/CFAAD8GjkLAqAECRMOqy0lqqnNYvNKMP8w+FFAY //+oaQAAkqOS2Tr+p/42dTn5Bpz21HAiVVzmW6NhJjQj3MIgUIF77Xog6PnEs+6+XHdUWVp8p99R uGRcSsucDADgBQAA4AUAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ /////////6CGAQAAAAAAVzIAAAEAAABFAAWgdBNAAGwG4hVEw6rLwKgC+Kpz370/zD4UWLzSv1AQ +dGwjgAAIKMpTKX5iiAurGJ+EJ8cRjD/ac9k/nMpzamajZaPm7e9UuIOvfSI/aDD5WlDa0LPuNc8 8r29E7+gEI8UdbdBQGWFdK8/V/5YHc4Nhitu03vcfmTijuybjzblO26bsVEt57DjhrpbvdyjMyCm bMGYVwILg0fWsNxUMQRFjE9NgtOfk79mMveGNle0zN55bCzEBTGoAHDemCFZF0QCga1/njUqwb4/ bh2/V0obhq9Cfb8yF5C/MgV4HSN7m2Di9rfKYTeR6jrnpIT4F3gpBu5MXLKzU+wAj7jKnVGPOhJc t7bNyir2rk8UhvY+wszM3/L7SqXcG4GXah96f+3nBvvJcDvhDAgzbypK5bVtygqFXhMP2yE8fv4Q ZA/0ZK3DRW/t+TFPyrtaiBNpn/2V1vXduh/gEVaH/nC77fjYKY22oqmDrjwt3Gp3ORNa5iKTNsgh prGvY/WJvaZ0tmaTJVQsnmk7pxzAsKA7A/FsIMJfJH3Z7uhwyOXOaBXjbdKVvZpbhugsYe/bKVTh xFrjudfkGOfKViONaOM7wWl2+urVZsJbYHEjwdYZXdp2T1Ni6h8ra7TrpbJAJ9rgGENqsKDgOtpf +iNReczpcG7QZGjNq+R+hnmNbcGVFDVKc/m0NjJIEPmXQL0f8TlUJdDBLvgD3MjaphpLpFsgAnTv ggCFsESDOrgN9o2b8jSTZlLeud+ytHQ3dV0NxWJpWSCqFNiKTG4fp300BvurKkE6CcnGsavxVDrw Vlu9lXJPP8CQs8nd2DILepPd3RryMNhtbx0S9x/GatVNpYVfzxUBwBffGJtfy4CekAnYC150M3UE kJBKD8vIXODOmaRPWC5uXMbj+H3zPTgulI3hdX4NLC/YrU6DFuZQHpSX0mQKamCGztRuW74mVqrq BEF2hWqpAdbkm5hcXPu9N8mwceg5e54zm2eXmK22aALcw6MNmFFNuFJZ96Q0I4+AlehcLhpoN1NU R4GmsQUzOcwQqvIOA5Rx+9BHZH8LZPbuGfbhbiv9wkITXMf7DkzMEyAPp0flaFUggQ0h9kYpeOgb d6jJsffmBhjML4wabqWkGkpjXZIm0v1gKKIbFDVuc6XbxBsqVMxPimZdpyaW3x/qQ4mqdopdtk9g 6PA2tFrdyD8lYifaOshcmui+ooa7ENaGYw5aBgMVlF4GNCXqclZ9PoR+jJHsL//qF28XRdaDAXkv Ls0kE27yb6TxFm02pqLmcjcsDETUiT8Tlf8yo9cbKbNe7Jrft5BEPrvwlzUFUPOpbQXl/rI1j0q6 VPr4zLdrdWv+nQWkzXddfHOFmv0t8kGMlCJ3+D5S2MJ9E9Nv1d5QDO7aH8Oc77pXS/Y6HZkee8KV Yuvizpd0TbWkI8aloUiY29rw2SFNJ20jmvXd/2yi5j1jqF43LS6T+a1NET5NVAIxg2e2aXizxGvY 3rNdIqVkewD15pHY5WOUcCLH2z/hsDT70wtlSRjN0G+XoE7Cq66WqHKVQ5Z0DW+8lCQ2smrJ+aNG 3rSP9IC+i7e25eQsaGFU1+rpnarPThoPXJ+g2KbrtPbCX2FCXYOBqRD9uQsSE1jeP2f307gOvDe1 Cco1eHeNzAMMFU9OuQA8TIRI94UmDZYRWonK3q0LTqgcpvknq2Wi38cnkR60Pqk52rDX3Y9OucUN S61bK5ffGWRPhWLX6+8bHYzZA4dSC+B+5znXCeeZetosz2GP0hLVmdyaBmMEe9Z08FsrL6jTiOSs 1jU9ZEncROeIVtuo/baUQHaX006tQh3t7aqr3LCrg2dwdeSYprQoxbkfyPvia37cALuQKtU4DEKP ndSyvh0Riu6o8pBFFkci/1FddufqxJ693d1BW58JySvsVD1ugMi5ZFxKSioBAHkAAAB5AAAAPQIB AHNrMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAA AgAAAEUAADlXXkAAPwYiJcCoAQJbeaUYeOsRAIqYfHQHreiGUBj//zn/AACt7ot91UvwvUq8BhMT OJTWOrpkXErgTAAAdAAAAHQAAAA9AgEAc2swAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA//////////+ghgEAAAAAAFcyAAACAAAARQAANPNLQAA/BhDswKgBAkp9K2VamABQaneIVSY7 gn2AEQDiw8QAAAEBCAoFx1/0BA8aUbtkXEo2UwEAeAAAAHgAAAA9AgEAdnIxAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////+ghgEAAAAAAFcyAAABAAAARQAAONYMQABABt90 wKgA9sCoAvgBven9tjhABpvCMMeAGAcsDzgAAAEBCAoMO1J6BcVDEIUAAAC7ZFxKnGoBAHgAAAB4 AAAAPQIBAHZyMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAA AABXMgAAAQAAAEUAADibZkAAQAYaG8CoAPbAqAL4Ab3p/rWL4oqdHTyGgBgPSVggAAABAQgKDDtS gAXFQxKFAAAAu2RcSgjYAgC4AAAAuAAAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD//////////6CGAQAAAAAAVzIAAAIAAABFAAB4OD9AAD8GDP3AqAECVDDgaTk22pX3 miqiZ5ohRaAYoawT+QAAAQEFEmeaJr1nmlJ9Z5pX9WeabdUAAAANCAAAEE0AO8AAAABAAAAAAA0I AAAQTQA7gAAAAEAAAAAADQgAABBNADtAAAAAQAAAAAAFBAAADNi8ZFxKOjgHAJsAAACbAAAAPQIB AHNrMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAA AgAAAEUAAFthK0AAPwYpOcCoAQJEw6rLRgiqc1i80ow/zD4UUBj//6vLAACSo5LZOv6n/jZ1OfkG nPbUcCJVXOZbo2EmNCPcwiBQgXvteiDo+cSz7r5cd1RZWnyn31G9ZFxKydEDAOAFAADgBQAAPQIB AHNrMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAA AQAAAEUABaCFK0AAbAbQ/UTDqsvAqAL4qnPfvT/MPhRYvNK/UBD50bCOAAAgoylMpfmKIC6sYn4Q nxxGMP9pz2T+cynNqZqNlo+bt71S4g699Ij9oMPlaUNrQs+41zzyvb0Tv6AQjxR1t0FAZYV0rz9X /lgdzg2GK27Te9x+ZOKO7JuPNuU7bpuxUS3nsOOGulu93KMzIKZswZhXAguDR9aw3FQxBEWMT02C 05+Tv2Yy94Y2V7TM3nlsLMQFMagAcN6YIVkXRAKBrX+eNSrBvj9uHb9XShuGr0J9vzIXkL8yBXgd I3ubYOL2t8phN5HqOuekhPgXeCkG7kxcsrNT7ACPuMqdUY86Ely3ts3KKvauTxSG9j7CzMzf8vtK pdwbgZdqH3p/7ecG+8lwO+EMCDNvKkrltW3KCoVeEw/bITx+/hBkD/RkrcNFb+35MU/Ku1qIE2mf /ZXW9d26H+ARVof+cLvt+NgpjbaiqYOuPC3canc5E1rmIpM2yCGmsa9j9Ym9pnS2ZpMlVCyeaTun HMCwoDsD8Wwgwl8kfdnu6HDI5c5oFeNt0pW9mluG6Cxh79spVOHEWuO51+QY58pWI41o4zvBaXb6 6tVmwltgcSPB1hld2nZPU2LqHytrtOulskAn2uAYQ2qwoOA62l/6I1F5zOlwbtBkaM2r5H6GeY1t wZUUNUpz+bQ2MkgQ+ZdAvR/xOVQl0MEu+APcyNqmGkukWyACdO+CAIWwRIM6uA32jZvyNJNmUt65 37K0dDd1XQ3FYmlZIKoU2IpMbh+nfTQG+6sqQToJycaxq/FUOvBWW72Vck8/wJCzyd3YMgt6k93d GvIw2G1vHRL3H8Zq1U2lhV/PFQHAF98Ym1/LgJ6QCdgLXnQzdQSQkEoPy8hc4M6ZpE9YLm5cxuP4 ffM9OC6UjeF1fg0sL9itToMW5lAelJfSZApqYIbO1G5bviZWquoEQXaFaqkB1uSbmFxc+703ybBx 6Dl7njObZ5eYrbZoAtzDow2YUU24Uln3pDQjj4CV6FwuGmg3U1RHgaaxBTM5zBCq8g4DlHH70Edk fwtk9u4Z9uFuK/3CQhNcx/sOTMwTIA+nR+VoVSCBDSH2Ril46Bt3qMmx9+YGGMwvjBpupaQaSmNd kibS/WAoohsUNW5zpdvEGypUzE+KZl2nJpbfH+pDiap2il22T2Do8Da0Wt3IPyViJ9o6yFya6L6i hrsQ1oZjDloGAxWUXgY0JepyVn0+hH6Mkewv/+oXbxdF1oMBeS8uzSQTbvJvpPEWbTamouZyNywM RNSJPxOV/zKj1xsps17smt+3kEQ+u/CXNQVQ86ltBeX+sjWPSrpU+vjMt2t1a/6dBaTNd118c4Wa /S3yQYyUInf4PlLYwn0T02/V3lAM7tofw5zvuldL9jodmR57wpVi6+LOl3RNtaQjxqWhSJjb2vDZ IU0nbSOa9d3/bKLmPWOoXjctLpP5rU0RPk1UAjGDZ7ZpeLPEa9jes10ipWR7APXmkdjlY5RwIsfb P+GwNPvTC2VJGM3Qb5egTsKrrpaocpVDlnQNb7yUJDayasn5o0betI/0gL6Lt7bl5CxoYVTX6umd qs9OGg9cn6DYpuu09sJfYUJdg4GpEP25CxITWN4/Z/fTuA68N7UJyjV4d43MAwwVT065ADxMhEj3 hSYNlhFaicrerQtOqBym+SerZaLfxyeRHrQ+qTnasNfdj065xQ1LrVsrl98ZZE+FYtfr7xsdjNkD h1IL4H7nOdcJ55l62izPYY/SEtWZ3JoGYwR71nTwWysvqNOI5KzWNT1kSdxE54hW26j9tpRAdpfT Tq1CHe3tqqvcsKuDZ3B15JimtCjFuR/I++JrftwAu5Aq1TgMQo+d1LK+HRGK7qjykEUWRyL/UV12 5+rEnr3d3UFbnwnJK+xUPW6AyMBkXErbHgQAqwAAAKsAAAA9AgEAc2swAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA//////////+ghgEAAAAAAFcyAAACAAAARQAAa/BfQAA/BtaOwKgB AlrTWCFhVssDvH+ZsppxILewGAPqCgoAAAEBCAoFx2dHABrHQQEBBQqacSLDmnEo5wAAAA0IAAAQ TQA8QAAAAEAAAAAADQgAABBNAC8AAAAAQAAAAAAFBAAADNjAZFxKqNEEAHwAAAB8AAAAPQIBAHZy MQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAAAQAA AEUAADzWd0AAQAbfBcCoAPbAqAL4ABbkqfw55XWSsfIioBIWoIwMAAACBAW0BAIICgw7ZugFx1vZ AQMDBMJkXEomrgwAiQAAAIkAAAA9AgEAc2swAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA//////////+ghgEAAAAAAFcyAAACAAAARQAASQEyQAA/BjBIwKgBAlIr9l8oA4YHU2Q+UsVH qlqwGAPqNrAAAAEBCAoFx2pHAaIEPwEBBQrFR6/GxUfACgAAAAUEAAAM2MJkXEoSVA0AdAAAAHQA AAA9AgEAc2swAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////+ghgEAAAAA AFcyAAACAAAARQAANDFfQAA/BtLYwKgBAkp9K2UwEQBQaneIVSY7gn2AEQDi4+sAAAEBCAoFx2pU BA8aUcRkXEqBywAAeAAAAHgAAAA9AgEAdnIxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA//////////+ghgEAAAAAAFcyAAABAAAARQAAOD5ZQABABncowKgA9sCoAvgBveoEtma49KR+ EQaAGAIzSEAAAAEBCAoMO3WBBcWJ24UAAADEZFxK3LMLAJsAAACbAAAAPQIBAHNrMAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAAAgAAAEUAAFuAdEAA PwYJ8MCoAQJEw6rLJS2qc1i80ow/zD4UUBj//8ymAACSo5LZOv6n/jZ1OfkGnPbUcCJVXOZbo2Em NCPcwiBQgXvteiDo+cSz7r5cd1RZWnyn31HHZFxKb68BANgAAADYAAAAPQIBAHNrMAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAAAgAAAEUAAJgTdUAA PwZYNcCoAQJG9ccWbBJfBeLU5aQhSX82gBgEKUGpAAABAQgKBcdvSwAE3u8AAAAaAAAACUJUX0NB TkNFTAIAABBNADjAAAAAQAAAAAAaAAAACUJUX0NBTkNFTAIAABBNADiAAAAAQAAAAAAkAAAAB0Fa X0hBVkUCZDY6cGllY2VzbGkzODIyZWkzMjg4ZWVly2RcSvo1BgB0AAAAdAAAAD0CAQB2cjEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAAAAAAVzIAAAIAAABFAAA0 3y1AAD8G11fAqAL4wKgA9uSpABaSsfIi/DnldoARAFze5gAAAQEICgXHdFMMO0Cgy2RcSmJHCQB0 AAAAdAAAAD0CAQB2cjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CG AQAAAAAAVzIAAAIAAABFAAA0JhJAAD8GkHPAqAL4wKgA9uSpABaSsfIi/DnldoARAFzeqQAAAQEI CgXHdJAMO0CgzGRcSqo2AAB0AAAAdAAAAD0CAQB2cjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD//////////6CGAQAAAAAAVzIAAAIAAABFAAA0vVhAAD8G+SzAqAL4wKgA9uSpABaS sfIi/DnldoARAFzeLwAAAQEICgXHdQoMO0CgzGRcSorMBAB8AAAAfAAAAD0CAQB2cjEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAAAAAAVzIAAAEAAABFAAA8FWNA AEAGoBrAqAD2wKgC+AAW5Kn8OeV1krHyIqASFqBdLAAAAgQFtAQCCAoMO5XIBcdb2QEDAwTMZFxK BLUFAH0AAAB9AAAAPQIBAHNrMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////// ////oIYBAAAAAABXMgAAAgAAAEUAAD34LUAAPwYOKsCoAQJjwA/5UtAvCXnro6yWsTW3gBgD6h8p AAABAQgKBcd1dgFIWcQAAAAFBAAADNjMZFxKEaMMAHQAAAB0AAAAPQIBAHZyMQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAAAgAAAEUAADRKPUAAPwZs SMCoAvjAqAD25KkAFpKx8iL8OeV2gBEAXN07AAABAQgKBcd1/gw7QKDNZFxKQR4PAIUAAACFAAAA PQIBAHNrMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABX MgAAAgAAAEUAAEVIQ0AAPwYWXMCoAQJBHdpMYK0LoqkFzCQuMUhigBj//4vdAAABAQUKLjFN2i4x T6oFEEmoGQeMNwbCtPJ4qNlpvc5kXEoN8QYAdAAAAHQAAAA9AgEAdnIxAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA//////////+ghgEAAAAAAFcyAAACAAAARQAANEk5QAA/Bm1MwKgC +MCoAPbkqQAWkrHyIvw55XaAEQBc21MAAAEBCAoFx3fmDDtAoNFkXEpfzwoAdAAAAHQAAAA9AgEA dnIxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////+ghgEAAAAAAFcyAAAC AAAARQAANDETQAA/BoVywKgC+MCoAPbkqQAWkrHyIvw55XaAEQBc14MAAAEBCAoFx3u2DDtAoNRk XErp3QgAdAAAAHQAAAA9AgEAc2swAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// //////+ghgEAAAAAAFcyAAACAAAARQAANBtCQAA/Buj1wKgBAkp9K2VFlQBQaneIVSY7gn2AEQDi uacAAAEBCAoFx38UBA8aUdRkXEpi8A0A2wAAANsAAAA9AgEAc2swAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA//////////+ghgEAAAAAAFcyAAACAAAARQAAm4RhQAA/BtnnwKgBAkEd 2kw03AuiqQXMNS4xSGKAGf//1f4AAAEBBQouMU3aLjFPqvE+6n5LrPgdF6xI8+AC4jOht1Bq+j/L JmswHY2IJsCyT62UJNOnHiz4Nm3W0zIpAO1tbbI9rrDbxBo5TbYeHs4N6U4Y+NKf5GsjV9KIDsfB hRKDRxp+ljQ7Wnu81Eqaz9QZu9U49tHVZFxKt2gFAJsAAACbAAAAPQIBAHNrMAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAAAgAAAEUAAFs4CEAAPwZS XMCoAQJEw6rLUmeqc1i80ow/zD4UUBj//59sAACSo5LZOv6n/jZ1OfkGnPbUcCJVXOZbo2EmNCPc wiBQgXvteiDo+cSz7r5cd1RZWnyn31HVZFxKR64GALAAAACwAAAAPQIBAHNrMAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAAAgAAAEUAAHBHI0AAPwbM bsCoAQLQfpXNCnKBnuhBeQOks8bwgBgEREb8AAABAQgKBceAFQB+VEQAAAANCAAAEE0APYAAAABA AAAAAA0IAAAQTQA9QAAAAEAAAAAADQgAABBNADgAAAAAQAAAAAAFBAAADNjYZFxKnkkDAHQAAAB0 AAAAPQIBAHZyMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAA AABXMgAAAgAAAEUAADTFbUAAPwbxF8CoAvjAqAD25KkAFpKx8iL8OeV2gBEAXM/jAAABAQgKBceD Vgw7QKDZZFxKXngOAMQAAADEAAAAPQIBAHNrMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP//////////oIYBAAAAAABXMgAAAgAAAEUAAITcO0AAPwbqmcCoAQJa01ghfFfLA7x/md2a cSC3sBkD6oTvAAABAQgKBceFXgAax0EBAQUKmnEiw5pxKOcAAAANCAAAEE0APIAAAABAAAAAAA0G AAAQTQAvAAAAAEAAAAAADQgAABBNAC8AAAAAQAAAAAANBgAAFiwAAUAAAABAANlkXEqKeA4AuAAA ALgAAAA9AgEAc2swAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////+ghgEA AAAAAFcyAAACAAAARQAAeEpEQAA/BslFwKgBAtB+lc16roGe6EF5P6SzxvCAGQRECWwAAAEBCAoF x4VeAH5URAAAAA0IAAAQTQA9wAAAAEAAAAAADQYAABBNAC5AAAAAQAAAAAANCAAAEE0ALkAAAABA AAAAAA0GAAAWLAAAgAAAAEAA2WRcSqZ4DgDOAAAAzgAAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAAAAAAVzIAAAIAAABFAACOISNAAD8GlJjAqAEC U21wlxO7YsCQSW7sbmCHeFAZ//94KwAAAAAADQgAACG9ADhAAAAAQAAAAAANCAAAIb0AOAAAAABA AAAAAA0IAAAhvQA4gAAAAEAAAAAADQYAACG9ADgAAAAAQAAAAAANCAAAIb0AOAAAAABAAAAAAA0G AAAhvQA4AAAAAEAA2WRcSsF4DgDZAAAA2QAAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD//////////6CGAQAAAAAAVzIAAAIAAABFAACZFzVAAD8GGfXAqAECUiv2XwSZ hgdTZD5bxUeqWrAZA+qFzQAAAQEICgXHhV4BogQ/AQEFCsVHr8bFR8AKAAAADQgAAB20ABoAAAAA QAAAAAANCAAAHbQAGkAAAABAAAAAAA0GAAAdtAAaAAAAAEAAAAAADQgAAB20ABoAAAAAQAAAAAAN BgAAHbQAGgAAAABAAAAAAADZZFxK3HgOAMAAAADAAAAAPQIBAHNrMAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAAAgAAAEUAAIAaR0AAPwYq7cCoAQJU MOBpD9ralfeaKt5nmiFFoBmhrD9PAAABAQUSZ5omvWeaUn1nmlf1Z5pt1QAAAA0IAAAQTQA8AAAA AEAAAAAADQYAABBNACeAAAAAQAAAAAANCAAAEE0AJ4AAAABAAAAAAA0GAAAWLAAAwAAAAEAA2WRc Svh4DgDaAAAA2gAAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// /////6CGAQAAAAAAVzIAAAIAAABFAACa9BpAAD8GEeDAqAECY8AP+TD4Lwl566O1lrE1t4AZA+rx bQAAAQEICgXHhV4BSFnEAAAADQgAAAKuAANAAAAAQAAAAAANCAAAAq4AAwAAAABAAAAAAA0IAAAC rgADgAAAAEAAAAAADQYAAAKuAAKAAAAAQAAAAAANCAAAAq4AAoAAAABAAAAAAA0GAAACrgACgAAA AEAA2WRcShN5DgDiAAAA4gAAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD//////////6CGAQAAAAAAVzIAAAIAAABFAACieE5AAD8GQMzAqAECY+lcqDxKEzn0QclE6Uqt reAZ9hiEcgAAAQEFIulKz6npSs/l6UrJ9elKyjHpSsRB6UrEfelKvo3pSr7JKCroru7ky2BUIy1T peMFrC16OGKB22K/s1XjJ1z4SD0qIAuoAwMMdlkSNTeULiY+6Fe3E1iBGCcIW8kf45BYt9qfBXDY LWY2irdEC4MoWT2Vyz7pK8/ZZFxKLXkOAMYAAADGAAAAPQIBAHNrMAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAAAgAAAEUAAIblPUAAPwaT+MCoAQJb eaUYLKcRAIqYfIUHreiGUBn//4wNAADv8hVQ6bORl7hJNx+fCJiaD7q+YvPRS4Se0dCmQ8E1hYci G1plaVv4FC5hykHVH0TrfZA2dym70xYnvP5FJrC8x/RHLA5fuCjpxPq/AaR6lEVb2nCNtONtmV76 RYC63GRcSqtACQC2AAAAtgAAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD//////////6CGAQAAAAAAVzIAAAEAAABFAAB2gFIAAHER7qQ+ENrFwKgBAu30dx0AYpv5gSX/ PTqwt2gAAAQL7+43UhYAAAAAABYEPhDaxe30KX2DVwAAASJ46Wj8AhRTf2svbh4FxnTane7wDfsY JelhkAAAAAAAAAAACwAAAAsAC2Q0OnR5cGVpNmVl3mRcStebDQDjAAAA4wAAAD0CAQBzazAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAAAAAAVzIAAAIAAABFAACj oxNAAD8G1EDAqAECUAGyVQguSaK8hSVrICsSroAZA+pw1AAAAQEICgXHiykACJKu6X7FnGSpgDJQ 57tv9O6XQ+eW+OEhU6+ZiOiDMHKLNZzGjbesWzA85vGcFwxejgj3a3rQtFflAw+HLbDjsGLXxe/g /SphApgh4uakUQR0ADLyOJzOIFZ9l8f7watibA0MfrJp1mQ1fBa7vpOed+ob3mRcSv+bDQC4AAAA uAAAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAA AAAAVzIAAAIAAABFAAB4nmhAAD8GPz/AqAECVMpHZCmUsoyEDPtEBiNx8YAZA+pWigAAAQEICgXH iykAWP+aAAAADQgAABBNADdAAAAAQAAAAAANBgAAEE0ANwAAAABAAAAAAA0IAAAQTQA3AAAAAEAA AAAADQYAABYsAAGAAAAAQADeZFxKH5wNACMBAAAjAQAAPQIBAHNrMAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP//////////oIYBAAAAAABXMgAAAgAAAEUAAOP8HUAAPwaxIcCoAQJV kXaaEPUIOkx1xG5d1Qv8UBn//6DHAAAAAAANCAAADPQAAcAAAABAAAAAAA0IAAAM9AABgAAAAEAA AAAADQgAAAz0AAFAAAAAQAAAAAANCAAADPQAAQAAAABAAAAAAA0IAAAM9AAAwAAAAEAAAAAADQgA AAz0AACAAAAAQAAAAAANCAAADPQAAEAAAABAAAAAAA0IAAAM9AACAAAAAEAAAAAADQYAAAz0AABA AAAAQAAAAAANCAAADPQAAEAAAABAAAAAAA0GAAAM9AAAQAAAAEAA3mRcSjmcDQDuAAAA7gAAAD0C AQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAAAAAAVzIA AAIAAABFAACuSm5AAD8GISbAqAECRvXHFmCuXwXi1OYIIUl/NoAZBCmOhQAAAQEICgXHiykABN7v AAAAGgAAAAlCVF9DQU5DRUwCAAAQTQA5AAAAAEAAAAAAGwAAAApCVF9SRVFVRVNUAgAAEE0AN0AA AABAAAAAABoAAAAJQlRfQ0FOQ0VMAgAAEE0AN0AAAABAAAAAABsAAAAKQlRfUkVRVUVTVAIAABYs AAHAAAAAQADeZFxKVZwNAMYAAADGAAAAPQIBAHNrMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP//////////oIYBAAAAAABXMgAAAgAAAEUAAIZAFUAAPwZGJsCoAQJGOa1TBUb+ME7F 0O093CyLUBn//xjOAAA21qUMGw0yzTuUJdrz/KHHHj0HC4PS0RMn5S5wOIkE2C86oQ87F7orKl7W sFUBX9aU/7vYl+aFUapycTRkCUYoDZ+ccPKEZsXdIoUfNNUkmJugvLC2b0sXrQ7eBNGv32RcShl3 CQC2AAAAtgAAAD0CAQBzazAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////// /6CGAQAAAAAAVzIAAAEAAABFAAB2B0cAAHERZ7A+ENrFwKgBAu30dx0AYhL55gpse6Gm+4cAAAQL 7+43XRYAAAAAABYEPhDaxe30KX2DVwAAASJ46XS5AhRTf2svbh4FxnTane7wDfsYJelhkAAAAAAA AAAACwAAAAsAC2Q0OnR5cGVpNmVl5GRcSgjCBAB8AAAAfAAAAD0CAQB2cjEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD//////////6CGAQAAAAAAVzIAAAEAAABFAAA8intAAEAGKwLA qAD2wKgC+AAW5Kn8OeV1krHyIqASFqD/agAAAgQFtAQCCAoMO/OJBcdb2QEDAwQ= --MP_/76/3bukzBOcdNv5+7ZTa1p+-- From owner-freebsd-pf@FreeBSD.ORG Tue Jul 14 15:25:00 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 203B01065676 for ; Tue, 14 Jul 2009 15:25:00 +0000 (UTC) (envelope-from ghostsniper007@hotmail.com) Received: from col0-omc1-s15.col0.hotmail.com (col0-omc1-s15.col0.hotmail.com [65.55.34.25]) by mx1.freebsd.org (Postfix) with ESMTP id F37378FC14 for ; Tue, 14 Jul 2009 15:24:59 +0000 (UTC) (envelope-from ghostsniper007@hotmail.com) Received: from COL106-W36 ([65.55.34.9]) by col0-omc1-s15.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 08:12:59 -0700 Message-ID: X-Originating-IP: [70.28.66.173] From: Tony To: Date: Tue, 14 Jul 2009 15:12:56 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2009 15:12:59.0624 (UTC) FILETIME=[92FE0680:01CA0495] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: question about max-src-conn and max-src-conn-rate 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, 14 Jul 2009 15:25:00 -0000 Below is a packet filter snippet from my config file: =20 block drop log quick from ... pass in quick on $ext_if proto tcp from any to port 80 flags S/SA k= eep state (max-src-conn 80=2C max-src-conn-rate 200/2=2C overload f= lush global) pass out quick on $int_if proto tcp from any to port 80 flags S/SA k= eep state pass out quick on $ext_if proto tcp from port 80 to any flags SA/S= A keep state pass in quick on $int_if proto tcp from port 80 to any flags SA/S= A keep state =20 Question 1: Should the bruteforce rules be on each line=2C or just that first one? =20 Question 2: If they should be on each line=2C should I multiply the values (80=2C 200/2= ) by 4 ? =20 Question 3: Are the rates I'm using reasonable? blocking should be on the loose side =20 I'm open to any thoughts=2C opinions or screams on best practices=20 _________________________________________________________________ Attention all humans. We are your photos. Free us. http://go.microsoft.com/?linkid=3D9666046= From owner-freebsd-pf@FreeBSD.ORG Tue Jul 14 23:15:39 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0707E1065677 for ; Tue, 14 Jul 2009 23:15:39 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from mail-px0-f200.google.com (mail-px0-f200.google.com [209.85.216.200]) by mx1.freebsd.org (Postfix) with ESMTP id DAFD78FC1B for ; Tue, 14 Jul 2009 23:15:38 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: by pxi38 with SMTP id 38so806606pxi.3 for ; Tue, 14 Jul 2009 16:15:38 -0700 (PDT) Received: by 10.141.29.14 with SMTP id g14mr3883045rvj.57.1247612125794; Tue, 14 Jul 2009 15:55:25 -0700 (PDT) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id g31sm2340342rvb.50.2009.07.14.15.55.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 15:55:24 -0700 (PDT) From: "Kevin" To: Date: Tue, 14 Jul 2009 18:55:40 -0400 Message-ID: <00a001ca04d6$37a122e0$a6e368a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoE1jWBBoAc22VmQ/m2jiz+NCtIwg== Content-Language: en-us Subject: PF + ALT QUEUE for DDOS DNS attack 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, 14 Jul 2009 23:15:39 -0000 Greetings, I am currently attempting to mitigate a DDoS attack on our network that is comprised mainly of bogus DNS requests. The attacks seem to be coming in waves of DNS queries on our internal systems. I have tried several different ways of mitigating this, one of which is to queue the DNS traffic via PF + ALTQ. I have attempted to limit the DNS traffic to the particular host that is being attacked. However, this doesn't seem to be very effective, as the nature of a DDoS attack means that the queries being made are fairly simple and straightforward. I was hoping to get some tips / tricks from people who have encountered similar scenarios. My firewall is (obviously) PF. FreeBSD specific information : FreeBSD fw 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Tue Dec 16 13:00:03 EST 2008 fw@fw:/usr/obj/usr/src/sys/FW i386 I'm looking for tips / tricks as far as what I can do on the firewall level, of course. Any help is greatly appreciated! :) ~kevin From owner-freebsd-pf@FreeBSD.ORG Tue Jul 14 23:36:55 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A99E9106566C for ; Tue, 14 Jul 2009 23:36:55 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 2DDA88FC15 for ; Tue, 14 Jul 2009 23:36:54 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: by ewy7 with SMTP id 7so1306312ewy.43 for ; Tue, 14 Jul 2009 16:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=jOMjrVlXrFKc7rJ8MQho3iFu1cANp6iNG7jI4rUgr30=; b=QB6aIVxoRZ9LAG/wto9T1v2tbfLAOnY1mpNOCMcrHZZx28M2dYwtkhazPmWWNDSNot ID1kRRyl3CEW3ONcJFsxBYORoC50ld98IwdnX3TC45ExcSZMNiT8g6hNO/mRHQ30bHHC SwJJhyOSJejzHU5+X6vYu69VksUNlHs9P77hw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tnKmpPU12XcU08O3zEcEx/4NpYJeIIcLHeeLHyXAUzanxNe10PP+naVTEKUUygkCgG AYL2qT/oiI1+hiqGLGuEXO0ycnssOlu/WtKdHnV+iMjj5x1VsWbwl7dp3KJXCiEjeAe/ EQFJHfdeBse93+P/p+r/d3s8ewidAZJbSPaFA= MIME-Version: 1.0 Sender: allicient3141@googlemail.com Received: by 10.210.138.7 with SMTP id l7mr1325147ebd.49.1247614614089; Tue, 14 Jul 2009 16:36:54 -0700 (PDT) In-Reply-To: <20090714132430.75bb46c8@overlord> References: <3228ef7c0907111044i55b965d3me10ad146314517bf@mail.gmail.com> <20090712155707.4925813c@overlord> <17838240D9A5544AAA5FF95F8D520316065A8437@ad-exh01.adhost.lan> <7731938b0907131722v460e5429ve4906ff822b2719@mail.gmail.com> <20090714132430.75bb46c8@overlord> Date: Wed, 15 Jul 2009 00:36:54 +0100 X-Google-Sender-Auth: 45dbf3e3aa32bfd9 Message-ID: <7731938b0907141636p51a6cb6bp9e6553e494d465d9@mail.gmail.com> From: Peter Maxwell To: Aleksic Predrag Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: pf between two lans 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, 14 Jul 2009 23:36:56 -0000 Comments inline... 2009/7/14 Aleksic Predrag : > On Tue, 14 Jul 2009 01:22:06 +0100 > Peter Maxwell wrote: > > =A0> Can you post the output of: pfctl -s r > > # pfctl -sr > scrub in all random-id fragment reassemble > block drop log (all) all > block drop in on sk0 inet proto icmp all icmp-type echoreq > block drop out log (all) quick on sk0 from any to > block drop in log (all) quick on sk0 from to any > pass in on sk0 inet proto tcp from any to 192.168.2.248 port =3D 57277 fl= ags S/SA keep state > pass in on sk0 inet proto udp from any to 192.168.2.248 port =3D 57277 ke= ep state > pass out on sk0 inet proto udp from 192.168.2.248 port =3D 57277 to any k= eep state > pass out on sk0 inet proto tcp from 192.168.2.248 port =3D 57277 to any f= lags S/SA keep state > pass in on sk0 inet proto udp from any to any port =3D http keep state > pass in on sk0 inet proto tcp from any to any port =3D http flags S/SA ke= ep state > pass in on sk0 proto udp from any to any port =3D 2706 keep state > pass in on sk0 proto tcp from any to any port =3D 2706 flags S/SA keep st= ate > pass quick proto tcp from any to any port =3D ssh flags S/SA keep state (= source-track rule, max-src-conn 10, max-src-conn-rate 1/3, overload flush global, src.track 3) > pass quick proto udp from any to any port =3D ssh keep state (source-trac= k rule, max-src-conn 10, max-src-conn-rate 1/3, overload f= lush global, src.track 3) > pass out on sk0 proto tcp all flags S/SA modulate state > pass out on sk0 proto udp all keep state > pass out on sk0 proto icmp all keep state > pass out on sk0 proto esp all keep state > I'd comment out the two (single rule in the pf.conf) "pass quick" rules with the max-src-conn/max-src-conn-rate and see if it helps. Starting with a simple ruleset which works, then incrementally adding in additional rules is usually a good stategy. I know that others may disagree, but I would also suggest that you avoid using the "quick" keyword unless you *really* need it - most rulesets can be written entirely without it and are easier to debug. > pass in on vr0 inet from 192.168.2.0/24 to any flags S/SA keep state > pass out on vr0 inet from any to 192.168.2.0/24 flags S/SA keep state > pass in on vr1 inet from 192.168.0.0/24 to any flags S/SA keep state > pass out on vr1 inet from any to 192.168.0.0/24 flags S/SA keep state > > Should i replace netmask to /16 in last four rules? > No, you have it right as it is. >> What happens if you try things without pf loaded >> and with pf loaded but a pass all ruleset? > > With pf loaded i can open almost anything but not ssh connection. > I can ping, browse shares and printers between lans. > > Without pf loaded i can do all that and ssh. > > Yesterday i changed default ssh port on remote box and it let me in > with the same pf rules loaded. > > Now, I'm also suspicious about remote box, it is CentOS box with untouche= d > config files, maybe SELinux is preventing ssh login. While ssh can be configured with a tcpwrapper style hosts.allow, I doubt that this is the problem as you'd still not be able to ssh without pf loaded as well if it was the ssh daemon. You can test and make sure by connecting to the remote ssh port with telnet: if you get a normal ssh header returned there isn't any ip filter configured in sshd, if there is you'll get some form of error messge back. It sounds like a problem with the pass quick max-src-conn/max-src-conn-rate rule. > >> Have you got gateway_enable set in your rc.conf (I think it shows as >> net.inet.ip.forwarding being set to 1 in your sysctl)? > > sysctl -a | grep net.inet.ip.forwarding > net.inet.ip.forwarding: 1 > >> Can you post the results of the same tcpdump with a larger window size >> ( -s 1024 ) and/or a tcpdump on the network interface itself? > > see attachment >> From owner-freebsd-pf@FreeBSD.ORG Tue Jul 14 23:46:19 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C95D10657CC for ; Tue, 14 Jul 2009 23:46:17 +0000 (UTC) (envelope-from torsten@cnc-london.net) Received: from mailhost.cnc-london.net (mailhost.cnc-london.net [209.44.113.195]) by mx1.freebsd.org (Postfix) with ESMTP id E292C8FC0C for ; Tue, 14 Jul 2009 23:46:16 +0000 (UTC) (envelope-from torsten@cnc-london.net) Received: (qmail 18820 invoked by uid 90); 15 Jul 2009 00:46:14 +0100 Received: from 78-105-9-127.zone3.bethere.co.uk (torsten@cnc-london.net@78-105-9-127.zone3.bethere.co.uk) by mailhost.cnc-london.net (envelope-from , uid 82) with qmail-scanner-2.05st (clamdscan: 0.95.1/9472. perlscan: 2.06st. Clear:RC:1(78.105.9.127):. Processed in 0.037722 secs); 14 Jul 2009 23:46:14 -0000 Received: from 78-105-9-127.zone3.bethere.co.uk (HELO torstenpc) (torsten@cnc-london.net@78.105.9.127) by mailhost.cnc-london.net with SMTP; 15 Jul 2009 00:46:14 +0100 From: "Torsten Kersandt" To: References: <00a001ca04d6$37a122e0$a6e368a0$@com> In-Reply-To: <00a001ca04d6$37a122e0$a6e368a0$@com> Date: Wed, 15 Jul 2009 00:46:22 +0100 Message-ID: <001501ca04dd$4d6ec8f0$e84c5ad0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoE1jWBBoAc22VmQ/m2jiz+NCtIwgABigPA Content-Language: en-gb Subject: RE: PF + ALT QUEUE for DDOS DNS attack 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, 14 Jul 2009 23:46:20 -0000 Hi It is a common problem and can best be prevented configuring your DNS server to limit recursion (lookup requests of non local or authoritive domains) to the internal network and trusted Internet IP addresses only. All other solutions you may just delay or limit normal dns server responses Most DNS server software does that very simple and if it is a internal machine doing this , block udp/tcp requests to port 53 from that address to your server using pf until resolved. Regards Torsten -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of Kevin Sent: 14 July 2009 23:56 To: freebsd-pf@freebsd.org Subject: PF + ALT QUEUE for DDOS DNS attack Greetings, I am currently attempting to mitigate a DDoS attack on our network that is comprised mainly of bogus DNS requests. The attacks seem to be coming in waves of DNS queries on our internal systems. I have tried several different ways of mitigating this, one of which is to queue the DNS traffic via PF + ALTQ. I have attempted to limit the DNS traffic to the particular host that is being attacked. However, this doesn't seem to be very effective, as the nature of a DDoS attack means that the queries being made are fairly simple and straightforward. I was hoping to get some tips / tricks from people who have encountered similar scenarios. My firewall is (obviously) PF. FreeBSD specific information : FreeBSD fw 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Tue Dec 16 13:00:03 EST 2008 fw@fw:/usr/obj/usr/src/sys/FW i386 I'm looking for tips / tricks as far as what I can do on the firewall level, of course. Any help is greatly appreciated! :) ~kevin _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Wed Jul 15 13:19:03 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2110E106566C for ; Wed, 15 Jul 2009 13:19:03 +0000 (UTC) (envelope-from valentin.bud@gmail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id 642188FC14 for ; Wed, 15 Jul 2009 13:19:02 +0000 (UTC) (envelope-from valentin.bud@gmail.com) Received: by bwz4 with SMTP id 4so840511bwz.43 for ; Wed, 15 Jul 2009 06:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=II44eo3ORkvI4oeXMybQpaoE18fC8QilsrVAP5j2W3w=; b=lm4mUxQt4E783cYdTczivVIbbMUXmhJeZOUgyGX6Vwq+zxHR+oGiqP1ZSyEbzG4h8w +P+r8gV7YPxdyR9IG5deHL0vEUuJ8si59lInuFVtbT+iABbULiNew3Tsg+GXkAvn8yhe uqXtFqSx/9rXbQx/S9uTz/kF+LT8jndX7IWgQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=G6mItMANEHGvYuIHYhDAu58aCyboZteizbp3R+Bv3v711Hj8UnAQxhqG8iGXofRzi3 5Nq5o2rjeX5uHqsAxuCH0U2pXACnspsjV+PEeN7f4ZmwQrOeFRI8JJtBLiaVKRf3gfMS rRKXkJwJ5pCaKOtft3Op972cimQexY38+3Vfc= MIME-Version: 1.0 Received: by 10.223.105.9 with SMTP id r9mr3912230fao.66.1247663941093; Wed, 15 Jul 2009 06:19:01 -0700 (PDT) In-Reply-To: References: From: Valentin Bud Date: Wed, 15 Jul 2009 16:18:41 +0300 Message-ID: <139b44430907150618y32473898i3a245c627c7091f2@mail.gmail.com> To: Tony Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: question about max-src-conn and max-src-conn-rate 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: Wed, 15 Jul 2009 13:19:03 -0000 On Tue, Jul 14, 2009 at 6:12 PM, Tony wrote: > > Below is a packet filter snippet from my config file: > > > > block drop log quick from > ... > pass in quick on $ext_if proto tcp from any to port 80 flags S/SA > keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush > global) > pass out quick on $int_if proto tcp from any to port 80 flags S/SA > keep state > > pass out quick on $ext_if proto tcp from port 80 to any flags > SA/SA keep state > pass in quick on $int_if proto tcp from port 80 to any flags > SA/SA keep state > > > > > Question 1: > Should the bruteforce rules be on each line, or just that first one? > > > > Question 2: > If they should be on each line, should I multiply the values (80, 200/2) by > 4 ? > > > > Question 3: > Are the rates I'm using reasonable? blocking should be on the loose side > > > > > I'm open to any thoughts, opinions or screams on best practices > > _________________________________________________________________ > Attention all humans. We are your photos. Free us. > > http://go.microsoft.com/?linkid=9666046_______________________________________________ > freebsd-pf@freebsd.orgmailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > Hello Tony, First i will "draw" a diagram of your network to see if i get it right. INTERNET-----($ext_if)[WEB_SRV]($int_if)-------LAN >From your post what i think you want to accomplish is: to restrict connections to WEB_SRV to 200 conns in 2 seconds and a maximum of 80 connections from one source IP. If any one of those conditions are met overload the table with that IP and flush all the states that IP created. Now the questions is: do you want the above conditions to apply to traffic from both INTERNET and LAN or only to traffic coming from INTERNET/LAN. If the conditions should apply only for traffic coming from internet the following does that: block drop log quick from pass in quick on $ext_if proto tcp from any to port 80 flags S/SA keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush global) pass in quick on $int_if proto tcp from port 80 to any flags S/SA keep state No need for "pass out" rules because of the *keep state* keyword which tells the firewall to allow outgoing traffic to IPs that already established a connection with WEB_SRV on port 80. So the answer to "Question 1" is: *depends *and *no *You don't need the "pass out" rules so no need to repeat the brute force rule :). Now it depends, if you want the same policy to apply to traffic coming in from LAN you must add the brute force rule (i guess you meant the "max-src-conn ..." part) to the rule that applies to traffic coming in $int_if. Question 2 You don't have to multiply the values by nothing if you want to limit the connections coming from one source IP to 80 and no more than 200 conns in 2 seconds for traffic coming in from both directions. You can change them as you need. Suppose you want to limit the maximum connections from one LAN IP to 120 and no more than 50/2 you would change the rule applied to $int_if. Question 3 Now this depends on the amount of incoming connections coming in from one source IP. For example if a visitor tries to open 81 connections at the same time and you wish to let that happen you must increase the max-src-conn to something above 81. The same applies to max-src-conn-rate. I suggest you (re)read the pf faq from openbsd website ( http://openbsd.org/faq/pf/filter.html) and there is a great book of pf - The Book of PF, Peter N.M. Hansteen which i kindly suggest you should read so you get a better understanding of pf overall. a great day, v -- network warrior since 2005 From owner-freebsd-pf@FreeBSD.ORG Thu Jul 16 02:37:41 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A134106564A for ; Thu, 16 Jul 2009 02:37:41 +0000 (UTC) (envelope-from ghostsniper007@hotmail.com) Received: from col0-omc3-s12.col0.hotmail.com (col0-omc3-s12.col0.hotmail.com [65.55.34.150]) by mx1.freebsd.org (Postfix) with ESMTP id 51B5D8FC17 for ; Thu, 16 Jul 2009 02:37:41 +0000 (UTC) (envelope-from ghostsniper007@hotmail.com) Received: from COL106-DS5 ([65.55.34.136]) by col0-omc3-s12.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 19:36:18 -0700 X-Originating-IP: [76.69.38.126] X-Originating-Email: [ghostsniper007@hotmail.com] Message-ID: From: "Tony B" To: "Valentin Bud" References: <139b44430907150618y32473898i3a245c627c7091f2@mail.gmail.com> In-Reply-To: <139b44430907150618y32473898i3a245c627c7091f2@mail.gmail.com> Date: Wed, 15 Jul 2009 22:36:21 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-OriginalArrivalTime: 16 Jul 2009 02:36:18.0269 (UTC) FILETIME=[328088D0:01CA05BE] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: question about max-src-conn and max-src-conn-rate 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: Thu, 16 Jul 2009 02:37:41 -0000 thank you for the reply,=20 This is the network layout I have: INTERNET-----($ext_if)[firewall/gateway]($int_if)-------[webservers on = lan] Does that change must as per the suggestions ? I would need the pass out rules if the webservers executed a CURL or = wget, correct ? Can someone suggest a max-src-conn-rate that would identify an attack? = all the online examples are far too strict. From: Valentin Bud=20 Sent: Wednesday, July 15, 2009 9:18 AM To: Tony=20 Cc: freebsd-pf@freebsd.org=20 Subject: Re: question about max-src-conn and max-src-conn-rate On Tue, Jul 14, 2009 at 6:12 PM, Tony = wrote: Below is a packet filter snippet from my config file: block drop log quick from ... pass in quick on $ext_if proto tcp from any to port 80 flags = S/SA keep state (max-src-conn 80, max-src-conn-rate 200/2, overload = flush global) pass out quick on $int_if proto tcp from any to port 80 flags = S/SA keep state pass out quick on $ext_if proto tcp from port 80 to any flags = SA/SA keep state pass in quick on $int_if proto tcp from port 80 to any flags = SA/SA keep state Question 1: Should the bruteforce rules be on each line, or just that first one? Question 2: If they should be on each line, should I multiply the values (80, = 200/2) by 4 ? Question 3: Are the rates I'm using reasonable? blocking should be on the loose = side I'm open to any thoughts, opinions or screams on best practices _________________________________________________________________ Attention all humans. We are your photos. Free us. = http://go.microsoft.com/?linkid=3D9666046________________________________= _______________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" Hello Tony, First i will "draw" a diagram of your network to see if i get it right. INTERNET-----($ext_if)[WEB_SRV]($int_if)-------LAN >From your post what i think you want to accomplish is: to restrict = connections to WEB_SRV to=20 200 conns in 2 seconds and a maximum of 80 connections from one source = IP. If any one of those conditions are met overload the table with that IP and = flush all the states that IP created. Now the questions is: do you want the above conditions to apply to = traffic from both INTERNET and LAN or only to traffic coming from INTERNET/LAN. If the conditions should apply only for traffic coming from internet the = following does that: block drop log quick from pass in quick on $ext_if proto tcp from any to port 80 flags S/SA = keep state (max-src-conn 80, max-src-conn-rate 200/2, overload = flush global) pass in quick on $int_if proto tcp from port 80 to any flags = S/SA keep state No need for "pass out" rules because of the keep state keyword which = tells the firewall to allow outgoing traffic to IPs that already established a connection = with WEB_SRV on port 80. So the answer to "Question 1" is: depends and no You don't need the "pass out" rules so no need to repeat the brute force = rule :). Now it depends, if you want the same policy to apply to traffic coming = in from LAN you must add the brute force rule (i guess you meant the "max-src-conn ..." = part) to the rule that applies to traffic coming in $int_if. Question 2 You don't have to multiply the values by nothing if you want to limit = the connections=20 coming from one source IP to 80 and no more than 200 conns in 2 seconds = for=20 traffic coming in from both directions. You can change them as you need. = Suppose you want to limit the maximum connections from one LAN IP to 120 and no more = than 50/2 you would change the rule applied to $int_if. Question 3 Now this depends on the amount of incoming connections coming in from = one source IP. For example if a visitor tries to open 81 connections at the same time = and you wish to let that happen you must increase the max-src-conn to something above = 81. The same applies to max-src-conn-rate.=20 I suggest you (re)read the pf faq from openbsd website = (http://openbsd.org/faq/pf/filter.html) and there is a great book of pf - The Book of PF, Peter N.M. Hansteen = which i kindly suggest you should read so you get a better understanding of pf overall. a great day, v --=20 network warrior since 2005 From owner-freebsd-pf@FreeBSD.ORG Thu Jul 16 02:47:18 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4C7A106564A for ; Thu, 16 Jul 2009 02:47:18 +0000 (UTC) (envelope-from torsten@cnc-london.net) Received: from mailhost.cnc-london.net (mailhost.cnc-london.net [209.44.113.195]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1398FC08 for ; Thu, 16 Jul 2009 02:47:18 +0000 (UTC) (envelope-from torsten@cnc-london.net) Received: (qmail 36685 invoked by uid 90); 16 Jul 2009 03:47:16 +0100 Received: from 78-105-9-127.zone3.bethere.co.uk (torsten@cnc-london.net@78-105-9-127.zone3.bethere.co.uk) by mailhost.cnc-london.net (envelope-from , uid 82) with qmail-scanner-2.05st (clamdscan: 0.95.1/9472. perlscan: 2.06st. Clear:RC:1(78.105.9.127):. Processed in 0.040995 secs); 16 Jul 2009 02:47:16 -0000 Received: from 78-105-9-127.zone3.bethere.co.uk (HELO torstenpc) (torsten@cnc-london.net@78.105.9.127) by mailhost.cnc-london.net with SMTP; 16 Jul 2009 03:47:15 +0100 From: "Torsten Kersandt" Cc: References: <139b44430907150618y32473898i3a245c627c7091f2@mail.gmail.com> In-Reply-To: Date: Thu, 16 Jul 2009 03:47:23 +0100 Message-ID: <015901ca05bf$bf85cd70$3e916850$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcoFvmnGYH40Lt3FSLSboM+onbtjHgAAU30g Content-Language: en-gb Subject: RE: question about max-src-conn and max-src-conn-rate 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: Thu, 16 Jul 2009 02:47:19 -0000 HI I know that many people disagree with this but I would not block any outgoing requests front the gateway in the first place: As in: pass out quick keep state regards Torsten -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of Tony B Sent: 16 July 2009 03:36 To: Valentin Bud Cc: freebsd-pf@freebsd.org Subject: Re: question about max-src-conn and max-src-conn-rate thank you for the reply, This is the network layout I have: INTERNET-----($ext_if)[firewall/gateway]($int_if)-------[webservers on lan] Does that change must as per the suggestions ? I would need the pass out rules if the webservers executed a CURL or wget, correct ? Can someone suggest a max-src-conn-rate that would identify an attack? all the online examples are far too strict. From: Valentin Bud Sent: Wednesday, July 15, 2009 9:18 AM To: Tony Cc: freebsd-pf@freebsd.org Subject: Re: question about max-src-conn and max-src-conn-rate On Tue, Jul 14, 2009 at 6:12 PM, Tony wrote: Below is a packet filter snippet from my config file: block drop log quick from ... pass in quick on $ext_if proto tcp from any to port 80 flags S/SA keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush global) pass out quick on $int_if proto tcp from any to port 80 flags S/SA keep state pass out quick on $ext_if proto tcp from port 80 to any flags SA/SA keep state pass in quick on $int_if proto tcp from port 80 to any flags SA/SA keep state Question 1: Should the bruteforce rules be on each line, or just that first one? Question 2: If they should be on each line, should I multiply the values (80, 200/2) by 4 ? Question 3: Are the rates I'm using reasonable? blocking should be on the loose side I'm open to any thoughts, opinions or screams on best practices _________________________________________________________________ Attention all humans. We are your photos. Free us. http://go.microsoft.com/?linkid=9666046_____________________________________ __________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" Hello Tony, First i will "draw" a diagram of your network to see if i get it right. INTERNET-----($ext_if)[WEB_SRV]($int_if)-------LAN >From your post what i think you want to accomplish is: to restrict connections to WEB_SRV to 200 conns in 2 seconds and a maximum of 80 connections from one source IP. If any one of those conditions are met overload the table with that IP and flush all the states that IP created. Now the questions is: do you want the above conditions to apply to traffic from both INTERNET and LAN or only to traffic coming from INTERNET/LAN. If the conditions should apply only for traffic coming from internet the following does that: block drop log quick from pass in quick on $ext_if proto tcp from any to port 80 flags S/SA keep state (max-src-conn 80, max-src-conn-rate 200/2, overload flush global) pass in quick on $int_if proto tcp from port 80 to any flags S/SA keep state No need for "pass out" rules because of the keep state keyword which tells the firewall to allow outgoing traffic to IPs that already established a connection with WEB_SRV on port 80. So the answer to "Question 1" is: depends and no You don't need the "pass out" rules so no need to repeat the brute force rule :). Now it depends, if you want the same policy to apply to traffic coming in from LAN you must add the brute force rule (i guess you meant the "max-src-conn ..." part) to the rule that applies to traffic coming in $int_if. Question 2 You don't have to multiply the values by nothing if you want to limit the connections coming from one source IP to 80 and no more than 200 conns in 2 seconds for traffic coming in from both directions. You can change them as you need. Suppose you want to limit the maximum connections from one LAN IP to 120 and no more than 50/2 you would change the rule applied to $int_if. Question 3 Now this depends on the amount of incoming connections coming in from one source IP. For example if a visitor tries to open 81 connections at the same time and you wish to let that happen you must increase the max-src-conn to something above 81. The same applies to max-src-conn-rate. I suggest you (re)read the pf faq from openbsd website (http://openbsd.org/faq/pf/filter.html) and there is a great book of pf - The Book of PF, Peter N.M. Hansteen which i kindly suggest you should read so you get a better understanding of pf overall. a great day, v -- network warrior since 2005 _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Thu Jul 16 08:09:06 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAA7A106566B for ; Thu, 16 Jul 2009 08:09:06 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail1.jellyfishnet.co.uk (mail1.jellyfishnet.co.uk [93.91.20.9]) by mx1.freebsd.org (Postfix) with ESMTP id 879198FC13 for ; Thu, 16 Jul 2009 08:09:06 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from pemexhub02.jellyfishnet.co.uk.local (93.91.20.3) by mail1.jellyfishnet.co.uk (93.91.20.9) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 16 Jul 2009 09:09:12 +0100 Received: from PEMEXMBXVS01.jellyfishnet.co.uk.local ([192.168.65.9]) by pemexhub02.jellyfishnet.co.uk.local ([192.168.103.12]) with mapi; Thu, 16 Jul 2009 09:06:32 +0100 From: Greg Hennessy To: Torsten Kersandt Date: Thu, 16 Jul 2009 09:04:31 +0100 Thread-Topic: question about max-src-conn and max-src-conn-rate Thread-Index: AcoFvmnGYH40Lt3FSLSboM+onbtjHgAAU30gAAsVU38= Message-ID: <6CE8D2A5CE118747811E51143A68BA0A72F4C625B5@PEMEXMBXVS01.jellyfishnet.co.uk.local> References: <139b44430907150618y32473898i3a245c627c7091f2@mail.gmail.com> , <015901ca05bf$bf85cd70$3e916850$@net> In-Reply-To: <015901ca05bf$bf85cd70$3e916850$@net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-pf@freebsd.org" Subject: RE: question about max-src-conn and max-src-conn-rate 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: Thu, 16 Jul 2009 08:09:07 -0000 That converts the operation of PF into a PIX. :-) I would tend to caveat the advice below with liberal use of tag and 'tagged= '=20 Greg ________________________________________ From: owner-freebsd-pf@freebsd.org [owner-freebsd-pf@freebsd.org] On Behalf= Of Torsten Kersandt [torsten@cnc-london.net] Sent: 16 July 2009 03:47 Cc: freebsd-pf@freebsd.org Subject: RE: question about max-src-conn and max-src-conn-rate HI I know that many people disagree with this but I would not block any outgoing requests front the gateway in the first place: As in: pass out quick keep state regards Torsten= From owner-freebsd-pf@FreeBSD.ORG Fri Jul 17 04:14:34 2009 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 626A8106566C; Fri, 17 Jul 2009 04:14:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 37F9B8FC12; Fri, 17 Jul 2009 04:14:34 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n6H4EYR8092556; Fri, 17 Jul 2009 04:14:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n6H4EYMZ092552; Fri, 17 Jul 2009 04:14:34 GMT (envelope-from linimon) Date: Fri, 17 Jul 2009 04:14:34 GMT Message-Id: <200907170414.n6H4EYMZ092552@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/136781: [pf] Packets appear to drop with pf scrub and if_bridge 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: Fri, 17 Jul 2009 04:14:34 -0000 Old Synopsis: Packets appear to drop with pf scrub and if_bridge New Synopsis: [pf] Packets appear to drop with pf scrub and if_bridge Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jul 17 04:14:12 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=136781 From owner-freebsd-pf@FreeBSD.ORG Fri Jul 17 16:11:00 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B89CC106566C for ; Fri, 17 Jul 2009 16:11:00 +0000 (UTC) (envelope-from elliott@mywedding.com) Received: from smtp187.sat.emailsrvr.com (smtp187.sat.emailsrvr.com [66.216.121.187]) by mx1.freebsd.org (Postfix) with ESMTP id 990EE8FC0C for ; Fri, 17 Jul 2009 16:11:00 +0000 (UTC) (envelope-from elliott@mywedding.com) Received: from relay28.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay28.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id F07B11B4027 for ; Fri, 17 Jul 2009 11:53:40 -0400 (EDT) Received: by relay28.relay.sat.mlsrvr.com (Authenticated sender: elliott-AT-mywedding.com) with ESMTPSA id B80951B4020 for ; Fri, 17 Jul 2009 11:53:40 -0400 (EDT) Message-Id: <10C490B4-9C4B-43C8-A935-146F8774842D@mywedding.com> From: Elliott Barrere To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 17 Jul 2009 08:53:38 -0700 X-Mailer: Apple Mail (2.935.3) Subject: pfsync synchronize 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: Fri, 17 Jul 2009 16:11:01 -0000 Hey all, I've seen references to synchronizing rules and macros through CARP/ pfsync, but only in relation to pfSense. Is this built in to CARP or the pfsync protocol or is it dependent on pfSense? I can use rsync or something if not, but I'd like to use what's built in if it's available. Thanks! -elliott- From owner-freebsd-pf@FreeBSD.ORG Fri Jul 17 16:22:11 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 770D71065672 for ; Fri, 17 Jul 2009 16:22:11 +0000 (UTC) (envelope-from elliott@mywedding.com) Received: from smtp187.sat.emailsrvr.com (smtp187.sat.emailsrvr.com [66.216.121.187]) by mx1.freebsd.org (Postfix) with ESMTP id 5510D8FC13 for ; Fri, 17 Jul 2009 16:22:11 +0000 (UTC) (envelope-from elliott@mywedding.com) Received: from relay28.relay.sat.mlsrvr.com (localhost [127.0.0.1]) by relay28.relay.sat.mlsrvr.com (SMTP Server) with ESMTP id 0D8D61B4020; Fri, 17 Jul 2009 12:22:11 -0400 (EDT) Received: by relay28.relay.sat.mlsrvr.com (Authenticated sender: elliott-AT-mywedding.com) with ESMTPSA id ADB561B401E; Fri, 17 Jul 2009 12:22:10 -0400 (EDT) Message-Id: From: Elliott Barrere To: Scott Ullrich In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 17 Jul 2009 09:22:10 -0700 References: <10C490B4-9C4B-43C8-A935-146F8774842D@mywedding.com> X-Mailer: Apple Mail (2.935.3) Cc: freebsd-pf@freebsd.org Subject: Re: pfsync synchronize 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: Fri, 17 Jul 2009 16:22:11 -0000 On Jul 17, 2009, at 9:17 AM, Scott Ullrich wrote: > On Fri, Jul 17, 2009 at 11:53 AM, Elliott Barrere > wrote: >> Hey all, >> >> I've seen references to synchronizing rules and macros through CARP/ >> pfsync, >> but only in relation to pfSense. Is this built in to CARP or the >> pfsync >> protocol or is it dependent on pfSense? I can use rsync or >> something if >> not, but I'd like to use what's built in if it's available. > > Syncing of rules is not done via CARP. It is specific to pfSense. Perfect, all I needed to know. Thanks for the quick response! > > Scott From owner-freebsd-pf@FreeBSD.ORG Fri Jul 17 16:43:48 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34A48106564A for ; Fri, 17 Jul 2009 16:43:48 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id B718D8FC15 for ; Fri, 17 Jul 2009 16:43:47 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by ey-out-2122.google.com with SMTP id 9so200352eyd.7 for ; Fri, 17 Jul 2009 09:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Dj3wz9V5F5INTd7PQ4DJNiLNi2Q1I2HssMOULqhfvSU=; b=kTJ6AIcoK0UiktPKRKvN0nPaJb31u5nZpkqspje8fYs/L2A0IMehyiw3jvZa+eV2i+ pUJGO/2npnue3ZsaiyWoLU81NlvaBqarvJMxcA08r7VUTdamXdG8YDLglD9yTe/cyMJ5 mRvwmTmzIe4Ks/+eCfefzhFQZgPFg+38j8+o0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=oDxktvpz4ml+7n+4R8XxfaUINHMsVo10ToG6OCj8Ya5pHuAKL+BuzlVUM4zOC49Tnr SUA7FQ/d8amMiFnx7QpWzeqCH0X8AlBUMUX52cAYnKCwRjnJzm0lWhdRZUiesfNzA8M0 dhenJhJd0AQY+r+q2XT18l71I3q2baVEyc90s= MIME-Version: 1.0 Received: by 10.210.41.1 with SMTP id o1mr1592526ebo.10.1247847441072; Fri, 17 Jul 2009 09:17:21 -0700 (PDT) In-Reply-To: <10C490B4-9C4B-43C8-A935-146F8774842D@mywedding.com> References: <10C490B4-9C4B-43C8-A935-146F8774842D@mywedding.com> From: Scott Ullrich Date: Fri, 17 Jul 2009 12:17:01 -0400 Message-ID: To: Elliott Barrere Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: pfsync synchronize 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: Fri, 17 Jul 2009 16:43:48 -0000 On Fri, Jul 17, 2009 at 11:53 AM, Elliott Barrere wr= ote: > Hey all, > > I've seen references to synchronizing rules and macros through CARP/pfsyn= c, > but only in relation to pfSense. =A0Is this built in to CARP or the pfsyn= c > protocol or is it dependent on pfSense? =A0I can use rsync or something i= f > not, but I'd like to use what's built in if it's available. Syncing of rules is not done via CARP. It is specific to pfSense. Scott