From voovoos-fpf at killfile.pl Thu Oct 1 07:22:12 2009 From: voovoos-fpf at killfile.pl (Maciej Wierzbicki) Date: Thu Oct 1 07:22:18 2009 Subject: [FreeBSD 7.2] snmp_pf.so Message-ID: <20091001070641.GA78518@mail.media4u.pl> Hi I am running bsnmpd using the default configuration from /etc/snmpd.config with pf module (theoreticaly) loaded: # # pf(4) module # begemotSnmpdModulePath."pf" = "/usr/lib/snmp_pf.so" As far as I understand, with this module loaded I should have in mib tree pf-related oids, as described in /usr/share/snmp/defs/pf_tree.def But when I am using bsnmpwalk to search them, no hits: # bsnmpwalk | grep ^pf # Oids from mibII_tree.def are available, as mibII is loaded as default, so I assume that my bsnmpd is not including snmp_pf.so somehow. What I am missing? TIA -- | /"\ ASCII ribbon | Maciej Wierzbicki | | \ / campaign against | VOO1-RIPE | | X HTML in email | At paranoia's poison door | | / \ and news | A suspicious mind is a healthy mind. | From loki.fab at gmail.com Thu Oct 1 10:16:57 2009 From: loki.fab at gmail.com (Ondoy) Date: Thu Oct 1 10:17:17 2009 Subject: [FreeBSD 7.2] snmp_pf.so In-Reply-To: <20091001070641.GA78518@mail.media4u.pl> References: <20091001070641.GA78518@mail.media4u.pl> Message-ID: <4b4a8f2b0910010245u2a02b1c9nae6e5645f583f2cd@mail.gmail.com> without specifying OID, it only walks the mib-2 subtree. try # bsnmpwalk fokus the objects under 1.3.6.1.4.1.12325.1.200 are the pf stuff. regards, On Thu, Oct 1, 2009 at 3:06 PM, Maciej Wierzbicki wrote: > Hi > > I am running bsnmpd using the default configuration from > /etc/snmpd.config with pf module (theoreticaly) loaded: > > # > # pf(4) module > # > begemotSnmpdModulePath."pf" ? ? = "/usr/lib/snmp_pf.so" > > As far as I understand, with this module loaded I should have in mib > tree pf-related oids, as described in /usr/share/snmp/defs/pf_tree.def > > But when I am using bsnmpwalk to search them, no hits: > # bsnmpwalk | grep ^pf > # > > Oids from mibII_tree.def are available, as mibII is loaded as default, > so I assume that my bsnmpd is not including snmp_pf.so somehow. What I > am missing? > > TIA > -- > | ?/"\ ? ASCII ribbon ? ?| ? ? ? ? ? ?Maciej Wierzbicki ? ? ? ? ? | > | ?\ / campaign against ?| ? ? ? ? ? ? ? ?VOO1-RIPE ? ? ? ? ? ? ? | > | ? X ? ?HTML in email ? | ? ? ? ?At paranoia's poison door ? ? ? | > | ?/ \ ? ? and news ? ? ?| ?A suspicious mind is a healthy mind. ?| > _______________________________________________ > 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 voovoos-fpf at killfile.pl Thu Oct 1 10:49:05 2009 From: voovoos-fpf at killfile.pl (Maciej Wierzbicki) Date: Thu Oct 1 10:49:12 2009 Subject: [FreeBSD 7.2] snmp_pf.so In-Reply-To: <4b4a8f2b0910010245u2a02b1c9nae6e5645f583f2cd@mail.gmail.com> References: <20091001070641.GA78518@mail.media4u.pl> <4b4a8f2b0910010245u2a02b1c9nae6e5645f583f2cd@mail.gmail.com> Message-ID: <4AC4891C.4090403@killfile.pl> Ondoy wrote on 2009-10-01 11:45: > without specifying OID, it only walks the mib-2 subtree. > try > # bsnmpwalk fokus > the objects under 1.3.6.1.4.1.12325.1.200 are the pf stuff. Indeed, thanks. But then I have another question. bsnmpwalk parses some of pf oids and then returns an error: Agent localhost:snmp returned error 1.3.6.1.4.1.12325.1.200.1.9.2.1.20.1 caused error - General error Its pfTablesTblPktsOutXPass in pfTables, I believe. That error is a known issue or I am missing something again? PS also, is it possible to count traffic on interface using snmp per ip address bound to it (not per whole interface)? PPS maybe I should address this discussion to freebsd-net instead? -- * Maciej Wierzbicki * At paranoia's poison door * * VOO1-RIPE * From shteryana at gmail.com Thu Oct 1 13:35:31 2009 From: shteryana at gmail.com (Shteryana Shopova) Date: Thu Oct 1 13:35:40 2009 Subject: [FreeBSD 7.2] snmp_pf.so In-Reply-To: <4AC4891C.4090403@killfile.pl> References: <20091001070641.GA78518@mail.media4u.pl> <4b4a8f2b0910010245u2a02b1c9nae6e5645f583f2cd@mail.gmail.com> <4AC4891C.4090403@killfile.pl> Message-ID: <61b573980910010606o575eb28cu7b28ba01992cbdcd@mail.gmail.com> Hi, 2009/10/1 Maciej Wierzbicki : > Ondoy wrote on 2009-10-01 11:45: > >> without specifying OID, it only walks the mib-2 subtree. >> try >> # bsnmpwalk fokus >> the objects under 1.3.6.1.4.1.12325.1.200 are the pf stuff. > > Indeed, thanks. > > But then I have another question. bsnmpwalk parses some of pf oids and then > returns an error: > Agent localhost:snmp returned error > 1.3.6.1.4.1.12325.1.200.1.9.2.1.20.1 caused error - General error > bsnmpwalk -i /usr/share/snmp/defs/pf_tree.def begemotPf By default only the mibII_tree.def and tree.def OID to strings are parsed - you have to tell bsnmpwalk to parse the begemotPf OIDs explicitly . > Its pfTablesTblPktsOutXPass in pfTables, I believe. That error is a known > issue or I am missing something again? > http://people.freebsd.org/~syrinx/snmp/pf_snmp.c-01102009-01.diff - this should fix the error. > PS also, is it possible to count traffic on interface using snmp per ip > address bound to it (not per whole interface)? Hm, I think this should be supposedly done by fetching pfTablesAddrTable, but currently it does not return any data...I am not sure when I will have time to look at this, but of course everyone is more than wellcome to submit a patch :) > PPS maybe I should address this discussion to freebsd-net instead? > -- cheers, Shteryana From roberto at keltia.freenix.fr Thu Oct 1 13:41:37 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Thu Oct 1 13:41:49 2009 Subject: something like bruteblock for pf? In-Reply-To: <200908230132343.SM01728@W500.Go2France.com> References: <200908230132343.SM01728@W500.Go2France.com> Message-ID: <20091001134134.GD1539@rron.freenix.org> According to Len Conrad: > Anybody know of anything similar for pf? postdandee does such manipulations for Postfix and you can configure it to add/remove pf rules for each address. http://traveler.com.br/blogs/ze/postdandee/ ----- ... my $BLOCKHOSTCOMMAND = 'pfctl -qt blackhole -Tadd $offendingHost 2>\&1 > /dev/null'; my $RELEASEHOSTCOMMAND = 'pfctl -qt blackhole -Tdelete $offendingHost 2>\&1 > /dev/null'; # $ROUTECHECKCOMMAND : # the command you'd like to use when checking for existing routes # postdandee will not try to add a route over an existing one my $ROUTECHECKCOMMAND = 'pfctl -qt blackhole -Tshow'; ... ----- -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From voovoos-fpf at killfile.pl Fri Oct 2 06:59:08 2009 From: voovoos-fpf at killfile.pl (Maciej Wierzbicki) Date: Fri Oct 2 06:59:15 2009 Subject: [FreeBSD 7.2] snmp_pf.so In-Reply-To: <61b573980910010606o575eb28cu7b28ba01992cbdcd@mail.gmail.com> References: <20091001070641.GA78518@mail.media4u.pl> <4b4a8f2b0910010245u2a02b1c9nae6e5645f583f2cd@mail.gmail.com> <4AC4891C.4090403@killfile.pl> <61b573980910010606o575eb28cu7b28ba01992cbdcd@mail.gmail.com> Message-ID: <4AC5A4B1.9080103@killfile.pl> Shteryana Shopova wrote on 2009-10-01 15:06: > http://people.freebsd.org/~syrinx/snmp/pf_snmp.c-01102009-01.diff - > this should fix the error. It does, but then it produces infinite amount of 1.3.6.1.4.1.12325.1.200.1.10.2.1.2 without values, so I must break bsnmpwalk by hand: [...] pfTablesTblPktsOutBlock[1] = 0 pfTablesTblPktsOutXPass[1] = 0 pfAltqQueueNumber.0 = 0 1.3.6.1.4.1.12325.1.200.1.10.2.1.2 = 1.3.6.1.4.1.12325.1.200.1.10.2.1.2 = [tons of 1.3.6.1.4.1.12325.1.200.1.10.2.1.2 =] > Hm, I think this should be supposedly done by fetching > pfTablesAddrTable, but currently it does not return any data...I am > not sure when I will have time to look at this, but of course everyone > is more than wellcome to submit a patch :) Can you give a tip to which files I should look into? -- * Maciej Wierzbicki * At paranoia's poison door * * VOO1-RIPE * From luizgustavo at luizgustavo.pro.br Sat Oct 3 19:51:37 2009 From: luizgustavo at luizgustavo.pro.br (Luiz Gustavo S. Costa) Date: Sat Oct 3 19:51:42 2009 Subject: Fwd: altq over vlan: patch exists ? In-Reply-To: <772ca7d0909241942n5ce78cc9sd9855bdd4c1e9c26@mail.gmail.com> References: <772ca7d0909241942n5ce78cc9sd9855bdd4c1e9c26@mail.gmail.com> Message-ID: <772ca7d0910031229w6c395db3x7cde66029ec6c5cf@mail.gmail.com> ---------- Forwarded message ---------- From: Luiz Gustavo S. Costa Date: 2009/9/24 Subject: altq over vlan: patch exists ? To: freebsd-hackers@freebsd.org Hi guys, The configuration Altq on one interface VLAN is working on OpenBSD and DragonFlyBSD, but FreeBSD no ! exists any patch for this ? or .. why no working ? any reason ? thanx -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: contato@mundounix.com.br -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: contato@mundounix.com.br Blog: http://www.luizgustavo.pro.br From sullrich at gmail.com Sat Oct 3 20:02:01 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Sat Oct 3 20:02:08 2009 Subject: altq over vlan: patch exists ? In-Reply-To: <772ca7d0910031229w6c395db3x7cde66029ec6c5cf@mail.gmail.com> References: <772ca7d0909241942n5ce78cc9sd9855bdd4c1e9c26@mail.gmail.com> <772ca7d0910031229w6c395db3x7cde66029ec6c5cf@mail.gmail.com> Message-ID: On Sat, Oct 3, 2009 at 3:29 PM, Luiz Gustavo S. Costa wrote: > Hi guys, > > The configuration Altq on one interface VLAN is working on OpenBSD and > DragonFlyBSD, but FreeBSD no ! > > exists any patch for this ? or .. why no working ? any reason ? http://cvs.pfsense.org/~sullrich/altq_if_vlan.c.diff But this assumes you know why you want to use this. Max has spoken on this topic quite a bit in the archives. Scott From luizgustavo at luizgustavo.pro.br Sun Oct 4 01:40:15 2009 From: luizgustavo at luizgustavo.pro.br (Luiz Gustavo S. Costa) Date: Sun Oct 4 01:40:22 2009 Subject: altq over vlan: patch exists ? In-Reply-To: References: <772ca7d0909241942n5ce78cc9sd9855bdd4c1e9c26@mail.gmail.com> <772ca7d0910031229w6c395db3x7cde66029ec6c5cf@mail.gmail.com> Message-ID: <772ca7d0910031840g10fe62e8x3855bf4f92e580f8@mail.gmail.com> Thanks Scott !!! and thank for the work on the pfSense ! but.... what a reason for this not in production on FreeBSD ? 2009/10/3 Scott Ullrich : > On Sat, Oct 3, 2009 at 3:29 PM, Luiz Gustavo S. Costa > wrote: >> Hi guys, >> >> The configuration Altq on one interface VLAN is working on OpenBSD and >> DragonFlyBSD, but FreeBSD no ! >> >> exists any patch for this ? or .. why no working ? any reason ? > > http://cvs.pfsense.org/~sullrich/altq_if_vlan.c.diff > > But this assumes you know why you want to use this. ?Max has spoken on > this topic quite a bit in the archives. > > Scott > -- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: contato@mundounix.com.br Blog: http://www.luizgustavo.pro.br From sullrich at gmail.com Sun Oct 4 03:50:02 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Sun Oct 4 03:50:09 2009 Subject: altq over vlan: patch exists ? In-Reply-To: <772ca7d0910031840g10fe62e8x3855bf4f92e580f8@mail.gmail.com> References: <772ca7d0909241942n5ce78cc9sd9855bdd4c1e9c26@mail.gmail.com> <772ca7d0910031229w6c395db3x7cde66029ec6c5cf@mail.gmail.com> <772ca7d0910031840g10fe62e8x3855bf4f92e580f8@mail.gmail.com> Message-ID: On Sat, Oct 3, 2009 at 9:40 PM, Luiz Gustavo S. Costa wrote: > but.... what a reason for this not in production on FreeBSD ? That is the part I was speaking of. :) Max has outlined why this patch is not in production and it boils down to being used incorrectly, I think. Scott From bugmaster at FreeBSD.org Mon Oct 5 11:06:58 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 5 11:09:08 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200910051106.n95B6v67088756@freefall.freebsd.org> 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/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg 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 36 problems total. From it85 at inbox.lv Mon Oct 5 19:20:42 2009 From: it85 at inbox.lv (it85@inbox.lv) Date: Mon Oct 5 19:20:48 2009 Subject: PF and HFSC Message-ID: <1254769280.4aca428097378@mail.inbox.lv> Hello, I'm interested in PF and HFSC. There is one limit in HFSC - classes, which are only 64. So I am interesting why 64? Can You tell me, why are so or there is some information about that? I want to find this out. Maybe I can write about that researh and find out why and how to improve this algorithm? Ilvars From gaurav at subisu.net.np Tue Oct 6 09:13:08 2009 From: gaurav at subisu.net.np (Gaurav Ghimire) Date: Tue Oct 6 09:13:16 2009 Subject: Packet Filter alerting system. In-Reply-To: <020001ca381e$4b8bade0$e2a309a0$@com> References: <4AADC15B.5060501@subisu.net.np> <4AAFE24A.2040602@uffner.com> <020001ca381e$4b8bade0$e2a309a0$@com> Message-ID: <4ACB0A16.4000806@subisu.net.np> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin wrote: >> Gaurav Ghimire wrote: >>> Just curious to know if we have something, some alerting system or >> mechanism that provides the administrator with the daily reports that >> pf itself or some other >>> tool collects on pf's behalf. >>> >>> That probably reports the admin of: >>> ~ Total connection counts matched on each rulesets. >>> ~ Total number of counts matched on deny rules. >> /etc/periodic/security/520.pfdenied >> >> it should be enabled by default if you haven't done anything unnatural >> to >> the /etc/periodic system >> >> > ~ IP/Port attack logs and relatives. >> >> only if you specify "log" in one or more of your pf rules, in which >> case you will find it in /var/log/pflog, /var/log/pflog.?.bz2, and >> /var/log/pf.{today,yesterday} >> >> tom > > > I wrote a script that compiles a daily report on any pf table based > threshold breaches -- something that could be modified to produce many > different types of daily pf based reports : > > > http://blog.stardothosting.com/2009/08/12/freebsd-pf-packet-filter-shell-scr > ipt-to-report-on-hacking-attempts/ > > > > Something to look at anyways. > > Hi all, Thanks for all your help. After a few workarounds I managed to get what I required. I wrote a script to get an easy to read report on all the traffic matching the block rule in my pf. The script could be modified to get reports on other specific rulesets you intend to, however, for that to work you might have to define another logging interface using pflogd and slap it to the rules you want to get reports on. Here is it if you guys wanna have a look on. http://nixify.blogspot.com/2009/10/getting-reports-on-intrusion-attempts.html Regards, - -- Gaurav Ghimire System Administrator Subisu Cablenet (P.) Ltd. 148 Thirbum Sadak Baluwatar, Kathmandu Nepal http://www.subisu.net.np (An ISO 9001:2000 Certified Company) - -- Gaurav Ghimire System Administrator Subisu Cablenet (P.) Ltd. 148 Thirbum Sadak Baluwatar, Kathmandu Nepal T: 00977 1 4429616/17 Ext.: 110 F: 00977 1 4430572 http://www.subisu.net.np (An ISO 9001:2000 Certified Company) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrLChIACgkQnfv7imVnL2tV7ACglNlu13pvAchgHAkYE5zE7cD2 KYAAnj5aDhKy2Olq3/d+i6h1hhx4DEOp =Zs9B -----END PGP SIGNATURE----- From nico at elico-it.be Tue Oct 6 13:30:45 2009 From: nico at elico-it.be (Nico De Dobbeleer) Date: Tue Oct 6 13:30:52 2009 Subject: freebsd-pf Stealth Modus In-Reply-To: <20091006120027.160901065786@hub.freebsd.org> Message-ID: <6422287.58441254834893591.JavaMail.root@zimbra-store> Hello, I just finished installing FreeBSD 7.x with pf in transparant bridging mode as the servers behind the firewall need to have an public ipaddress. Now is everything working fine and the FW is doing his job as it should be. When I nmap the FW I see the open ports and closed ports. Is there a way the get the FW running in stealth mode so that isn't possible anymore with nmap or any other scanning tool to see the open or closed ports? When I look around I hear roomers that there's something like blackhole that can be added in the sysctl. Anyone an idea? Kind regards, Nico From jumper99 at gmx.de Tue Oct 6 15:49:52 2009 From: jumper99 at gmx.de (Helmut Schneider) Date: Tue Oct 6 15:50:00 2009 Subject: freebsd-pf Stealth Modus References: <6422287.58441254834893591.JavaMail.root@zimbra-store> Message-ID: <49F0693DC96541B4B9D7B61599A12CA4@vpe.de> From: "Nico De Dobbeleer" > I just finished installing FreeBSD 7.x with pf in transparant bridging > mode as the servers behind the firewall need to have an public > ipaddress. Now is everything working fine and the FW is doing his job as > it should be. When I nmap the FW I see the open ports and closed ports. > Is there a way the get the FW running in stealth mode so that isn't > possible anymore with nmap or any other scanning tool to see the open or > closed ports? There is no "stealth". If a service responds to a request the port is "open". If not it's closed. Helmut From bunchou at googlemail.com Tue Oct 6 16:43:59 2009 From: bunchou at googlemail.com (=?UTF-8?B?5paH6bOl?=) Date: Tue Oct 6 16:44:04 2009 Subject: freebsd-pf Stealth Modus In-Reply-To: <49F0693DC96541B4B9D7B61599A12CA4@vpe.de> References: <6422287.58441254834893591.JavaMail.root@zimbra-store> <49F0693DC96541B4B9D7B61599A12CA4@vpe.de> Message-ID: <20091006182241.79d16c8c@centaur.5550h.net> On Tue, 6 Oct 2009 17:23:09 +0200 "Helmut Schneider" wrote: > From: "Nico De Dobbeleer" > > I just finished installing FreeBSD 7.x with pf in transparant > > bridging mode as the servers behind the firewall need to have an > > public ipaddress. Now is everything working fine and the FW is > > doing his job as it should be. When I nmap the FW I see the open > > ports and closed ports. Is there a way the get the FW running in > > stealth mode so that isn't possible anymore with nmap or any other > > scanning tool to see the open or closed ports? > > There is no "stealth". If a service responds to a request the port is > "open". If not it's closed. > > Helmut There is: just use "block drop" in your pf config or "set block-policy drop" (see man 5 pf.conf). This effectively stops sending TCP RST or UDP unreach packets. From jumper99 at gmx.de Tue Oct 6 18:51:30 2009 From: jumper99 at gmx.de (Helmut Schneider) Date: Tue Oct 6 18:52:03 2009 Subject: freebsd-pf Stealth Modus References: <6422287.58441254834893591.JavaMail.root@zimbra-store><49F0693DC96541B4B9D7B61599A12CA4@vpe.de> <20091006182241.79d16c8c@centaur.5550h.net> Message-ID: ?? wrote: > On Tue, 6 Oct 2009 17:23:09 +0200 > "Helmut Schneider" wrote: > >> From: "Nico De Dobbeleer" >>> I just finished installing FreeBSD 7.x with pf in transparant >>> bridging mode as the servers behind the firewall need to have an >>> public ipaddress. Now is everything working fine and the FW is >>> doing his job as it should be. When I nmap the FW I see the open >>> ports and closed ports. Is there a way the get the FW running in >>> stealth mode so that isn't possible anymore with nmap or any other >>> scanning tool to see the open or closed ports? >> >> There is no "stealth". If a service responds to a request the port is >> "open". If not it's closed. > > There is: just use "block drop" in your pf config or "set block-policy > drop" (see man 5 pf.conf). This effectively stops sending TCP RST or > UDP unreach packets. Consider a webserver where you pass HTTP and "block drop" SSH. 1 port is open -> host not "stealth". But even if you "block drop" all incoming traffic to a host, if a host is really down (and therefore stealth) the hosts' gateway would send an ICMP type 3 packet (until you didn't cripple ICMP as well). While sometimes it might be useful to "block drop" it has nothing to do with being "stealth". Helmut From bunchou at googlemail.com Tue Oct 6 19:09:19 2009 From: bunchou at googlemail.com (=?UTF-8?B?5paH6bOl?=) Date: Tue Oct 6 19:09:25 2009 Subject: freebsd-pf Stealth Modus In-Reply-To: References: <6422287.58441254834893591.JavaMail.root@zimbra-store> <49F0693DC96541B4B9D7B61599A12CA4@vpe.de> <20091006182241.79d16c8c@centaur.5550h.net> Message-ID: <20091006210912.379434eb@centaur.5550h.net> On Tue, 6 Oct 2009 20:28:33 +0200 "Helmut Schneider" wrote: > ?? wrote: > > On Tue, 6 Oct 2009 17:23:09 +0200 > > "Helmut Schneider" wrote: > > > >> From: "Nico De Dobbeleer" > >>> I just finished installing FreeBSD 7.x with pf in transparant > >>> bridging mode as the servers behind the firewall need to have an > >>> public ipaddress. Now is everything working fine and the FW is > >>> doing his job as it should be. When I nmap the FW I see the open > >>> ports and closed ports. Is there a way the get the FW running in > >>> stealth mode so that isn't possible anymore with nmap or any other > >>> scanning tool to see the open or closed ports? > >> > >> There is no "stealth". If a service responds to a request the port > >> is "open". If not it's closed. > > > > There is: just use "block drop" in your pf config or "set > > block-policy drop" (see man 5 pf.conf). This effectively stops > > sending TCP RST or UDP unreach packets. > > Consider a webserver where you pass HTTP and "block drop" SSH. 1 port > is open -> host not "stealth". > > But even if you "block drop" all incoming traffic to a host, if a > host is really down (and therefore stealth) the hosts' gateway would > send an ICMP type 3 packet (until you didn't cripple ICMP as well). > > While sometimes it might be useful to "block drop" it has nothing to > do with being "stealth". > > Helmut Not replying to a probe in the mentioned way is exactly what is commonly referred to as "stealth mode" by consumer firewalls. Just try a simple google search for "stealth firewall" and you will see. Besides, if only a few (uncommon) ports are open, a limited scan is unlikely to find them, thus calling it "stealth" (aka "low observability" according to wikipedia) is appropriate imho. There is a difference between stealth and invisibility. From jumper99 at gmx.de Wed Oct 7 09:42:51 2009 From: jumper99 at gmx.de (Helmut Schneider) Date: Wed Oct 7 09:42:58 2009 Subject: freebsd-pf Stealth Modus References: <6422287.58441254834893591.JavaMail.root@zimbra-store><49F0693DC96541B4B9D7B61599A12CA4@vpe.de><20091006182241.79d16c8c@centaur.5550h.net> <20091006210912.379434eb@centaur.5550h.net> Message-ID: ?? wrote: > On Tue, 6 Oct 2009 20:28:33 +0200 > "Helmut Schneider" wrote: > >> ?? wrote: >>> On Tue, 6 Oct 2009 17:23:09 +0200 >>> "Helmut Schneider" wrote: >>> >>>> From: "Nico De Dobbeleer" >>>>> I just finished installing FreeBSD 7.x with pf in transparant >>>>> bridging mode as the servers behind the firewall need to have an >>>>> public ipaddress. Now is everything working fine and the FW is >>>>> doing his job as it should be. When I nmap the FW I see the open >>>>> ports and closed ports. Is there a way the get the FW running in >>>>> stealth mode so that isn't possible anymore with nmap or any other >>>>> scanning tool to see the open or closed ports? >>>> >>>> There is no "stealth". If a service responds to a request the port >>>> is "open". If not it's closed. >>> >>> There is: just use "block drop" in your pf config or "set >>> block-policy drop" (see man 5 pf.conf). This effectively stops >>> sending TCP RST or UDP unreach packets. >> >> Consider a webserver where you pass HTTP and "block drop" SSH. 1 port >> is open -> host not "stealth". >> >> But even if you "block drop" all incoming traffic to a host, if a >> host is really down (and therefore stealth) the hosts' gateway would >> send an ICMP type 3 packet (until you didn't cripple ICMP as well). >> >> While sometimes it might be useful to "block drop" it has nothing to >> do with being "stealth". > > Not replying to a probe in the mentioned way is exactly what is > commonly referred to as "stealth mode" by consumer firewalls. Just try > a simple google search for "stealth firewall" and you will see. I know the term "stealth firewall" very well. It's a worthless marketing buzzword. It suggests users that it could prevent an attack or even the scan itself. Neither is correct. This is what I wanted to point out and I was encouraged by the fact that the OP was talking about "stealthing" open ports. From nico at elico-it.be Wed Oct 7 14:10:29 2009 From: nico at elico-it.be (Nico De Dobbeleer) Date: Wed Oct 7 14:10:36 2009 Subject: freebsd-pf Digest, Vol 263, Issue 3 In-Reply-To: <24402806.63641254924566875.JavaMail.root@zimbra-store> Message-ID: <23087185.63661254924619867.JavaMail.root@zimbra-store> From: "Nico De Dobbeleer" > I just finished installing FreeBSD 7.x with pf in transparant bridging > mode as the servers behind the firewall need to have an public > ipaddress. Now is everything working fine and the FW is doing his job as > it should be. When I nmap the FW I see the open ports and closed ports. > Is there a way the get the FW running in stealth mode so that isn't > possible anymore with nmap or any other scanning tool to see the open or > closed ports? There is no "stealth". If a service responds to a request the port is "open". If not it's closed. Helmut ------------------------------ Message: 3 Date: Tue, 6 Oct 2009 18:22:41 +0200 From: " ?? " Subject: Re: freebsd-pf Stealth Modus To: "Helmut Schneider" Cc: Nico De Dobbeleer , freebsd-pf@freebsd.org Message-ID: <20091006182241.79d16c8c@centaur.5550h.net> Content-Type: text/plain; charset=US-ASCII On Tue, 6 Oct 2009 17:23:09 +0200 "Helmut Schneider" wrote: > From: "Nico De Dobbeleer" > > I just finished installing FreeBSD 7.x with pf in transparant > > bridging mode as the servers behind the firewall need to have an > > public ipaddress. Now is everything working fine and the FW is > > doing his job as it should be. When I nmap the FW I see the open > > ports and closed ports. Is there a way the get the FW running in > > stealth mode so that isn't possible anymore with nmap or any other > > scanning tool to see the open or closed ports? > > There is no "stealth". If a service responds to a request the port is > "open". If not it's closed. > > Helmut There is: just use "block drop" in your pf config or "set block-policy drop" (see man 5 pf.conf). This effectively stops sending TCP RST or UDP unreach packets. ------------------------------ Message: 4 Date: Tue, 6 Oct 2009 20:28:33 +0200 From: "Helmut Schneider" Subject: Re: freebsd-pf Stealth Modus To: freebsd-pf@freebsd.org Message-ID: Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original ?????? wrote: > On Tue, 6 Oct 2009 17:23:09 +0200 > "Helmut Schneider" wrote: > >> From: "Nico De Dobbeleer" >>> I just finished installing FreeBSD 7.x with pf in transparant >>> bridging mode as the servers behind the firewall need to have an >>> public ipaddress. Now is everything working fine and the FW is >>> doing his job as it should be. When I nmap the FW I see the open >>> ports and closed ports. Is there a way the get the FW running in >>> stealth mode so that isn't possible anymore with nmap or any other >>> scanning tool to see the open or closed ports? >> >> There is no "stealth". If a service responds to a request the port is >> "open". If not it's closed. > > There is: just use "block drop" in your pf config or "set block-policy > drop" (see man 5 pf.conf). This effectively stops sending TCP RST or > UDP unreach packets. Consider a webserver where you pass HTTP and "block drop" SSH. 1 port is open -> host not "stealth". But even if you "block drop" all incoming traffic to a host, if a host is really down (and therefore stealth) the hosts' gateway would send an ICMP type 3 packet (until you didn't cripple ICMP as well). While sometimes it might be useful to "block drop" it has nothing to do with being "stealth". Helmut ------------------------------ Message: 5 Date: Tue, 6 Oct 2009 21:09:12 +0200 From: " ?? " Subject: Re: freebsd-pf Stealth Modus To: "Helmut Schneider" Cc: freebsd-pf@freebsd.org Message-ID: <20091006210912.379434eb@centaur.5550h.net> Content-Type: text/plain; charset=UTF-8 On Tue, 6 Oct 2009 20:28:33 +0200 "Helmut Schneider" wrote: > ?????? wrote: > > On Tue, 6 Oct 2009 17:23:09 +0200 > > "Helmut Schneider" wrote: > > > >> From: "Nico De Dobbeleer" > >>> I just finished installing FreeBSD 7.x with pf in transparant > >>> bridging mode as the servers behind the firewall need to have an > >>> public ipaddress. Now is everything working fine and the FW is > >>> doing his job as it should be. When I nmap the FW I see the open > >>> ports and closed ports. Is there a way the get the FW running in > >>> stealth mode so that isn't possible anymore with nmap or any other > >>> scanning tool to see the open or closed ports? > >> > >> There is no "stealth". If a service responds to a request the port > >> is "open". If not it's closed. > > > > There is: just use "block drop" in your pf config or "set > > block-policy drop" (see man 5 pf.conf). This effectively stops > > sending TCP RST or UDP unreach packets. > > Consider a webserver where you pass HTTP and "block drop" SSH. 1 port > is open -> host not "stealth". > > But even if you "block drop" all incoming traffic to a host, if a > host is really down (and therefore stealth) the hosts' gateway would > send an ICMP type 3 packet (until you didn't cripple ICMP as well). > > While sometimes it might be useful to "block drop" it has nothing to > do with being "stealth". > > Helmut Not replying to a probe in the mentioned way is exactly what is commonly referred to as "stealth mode" by consumer firewalls. Just try a simple google search for "stealth firewall" and you will see. Besides, if only a few (uncommon) ports are open, a limited scan is unlikely to find them, thus calling it "stealth" (aka "low observability" according to wikipedia) is appropriate imho. There is a difference between stealth and invisibility. ------------------------------ Message: 6 Date: Wed, 7 Oct 2009 11:40:36 +0200 From: "Helmut Schneider" Subject: Re: freebsd-pf Stealth Modus To: freebsd-pf@freebsd.org Message-ID: Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original ?????? wrote: > On Tue, 6 Oct 2009 20:28:33 +0200 > "Helmut Schneider" wrote: > >> ?????? wrote: >>> On Tue, 6 Oct 2009 17:23:09 +0200 >>> "Helmut Schneider" wrote: >>> >>>> From: "Nico De Dobbeleer" >>>>> I just finished installing FreeBSD 7.x with pf in transparant >>>>> bridging mode as the servers behind the firewall need to have an >>>>> public ipaddress. Now is everything working fine and the FW is >>>>> doing his job as it should be. When I nmap the FW I see the open >>>>> ports and closed ports. Is there a way the get the FW running in >>>>> stealth mode so that isn't possible anymore with nmap or any other >>>>> scanning tool to see the open or closed ports? >>>> >>>> There is no "stealth". If a service responds to a request the port >>>> is "open". If not it's closed. >>> >>> There is: just use "block drop" in your pf config or "set >>> block-policy drop" (see man 5 pf.conf). This effectively stops >>> sending TCP RST or UDP unreach packets. >> >> Consider a webserver where you pass HTTP and "block drop" SSH. 1 port >> is open -> host not "stealth". >> >> But even if you "block drop" all incoming traffic to a host, if a >> host is really down (and therefore stealth) the hosts' gateway would >> send an ICMP type 3 packet (until you didn't cripple ICMP as well). >> >> While sometimes it might be useful to "block drop" it has nothing to >> do with being "stealth". > > Not replying to a probe in the mentioned way is exactly what is > commonly referred to as "stealth mode" by consumer firewalls. Just try > a simple google search for "stealth firewall" and you will see. I know the term "stealth firewall" very well. It's a worthless marketing buzzword. It suggests users that it could prevent an attack or even the scan itself. Neither is correct. This is what I wanted to point out and I was encouraged by the fact that the OP was talking about "stealthing" open ports. ------------------- Already many thanks for the info. I'v added already the "set block-policy drop". I'v done an nmap and it's apparently able to find out the setting below of my pf FW: MAC Address: 00:0E:2E:xx:xx:xx (Edimax Technology Co.) Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running: FreeBSD 7.X OS details: FreeBSD 7.1-PRERELEASE Uptime guess: 0.000 days (since Wed Oct 07 16:02:00 2009) Network Distance: 1 hop TCP Sequence Prediction: Difficulty=260 (Good luck!) IP ID Sequence Generation: Incremental Service Info: OS: FreeBSD Is there a way to block this info? From bunchou at googlemail.com Wed Oct 7 15:11:40 2009 From: bunchou at googlemail.com (=?UTF-8?B?5paH6bOl?=) Date: Wed Oct 7 15:11:53 2009 Subject: freebsd-pf Stealth Modus In-Reply-To: References: <6422287.58441254834893591.JavaMail.root@zimbra-store> <49F0693DC96541B4B9D7B61599A12CA4@vpe.de> <20091006182241.79d16c8c@centaur.5550h.net> <20091006210912.379434eb@centaur.5550h.net> Message-ID: <20091007171133.21cf50ce@centaur.5550h.net> On Wed, 7 Oct 2009 11:40:36 +0200 "Helmut Schneider" wrote: > ?? wrote: > > On Tue, 6 Oct 2009 20:28:33 +0200 > > "Helmut Schneider" wrote: > > > >> ?? wrote: > >>> On Tue, 6 Oct 2009 17:23:09 +0200 > >>> "Helmut Schneider" wrote: > >>> > >>>> From: "Nico De Dobbeleer" > >>>>> I just finished installing FreeBSD 7.x with pf in transparant > >>>>> bridging mode as the servers behind the firewall need to have an > >>>>> public ipaddress. Now is everything working fine and the FW is > >>>>> doing his job as it should be. When I nmap the FW I see the open > >>>>> ports and closed ports. Is there a way the get the FW running in > >>>>> stealth mode so that isn't possible anymore with nmap or any > >>>>> other scanning tool to see the open or closed ports? > >>>> > >>>> There is no "stealth". If a service responds to a request the > >>>> port is "open". If not it's closed. > >>> > >>> There is: just use "block drop" in your pf config or "set > >>> block-policy drop" (see man 5 pf.conf). This effectively stops > >>> sending TCP RST or UDP unreach packets. > >> > >> Consider a webserver where you pass HTTP and "block drop" SSH. 1 > >> port is open -> host not "stealth". > >> > >> But even if you "block drop" all incoming traffic to a host, if a > >> host is really down (and therefore stealth) the hosts' gateway > >> would send an ICMP type 3 packet (until you didn't cripple ICMP as > >> well). > >> > >> While sometimes it might be useful to "block drop" it has nothing > >> to do with being "stealth". > > > > Not replying to a probe in the mentioned way is exactly what is > > commonly referred to as "stealth mode" by consumer firewalls. Just > > try a simple google search for "stealth firewall" and you will see. > > I know the term "stealth firewall" very well. It's a worthless > marketing buzzword. It suggests users that it could prevent an attack > or even the scan itself. Neither is correct. This is what I wanted to > point out and I was encouraged by the fact that the OP was talking > about "stealthing" open ports. Ok, I totally agree with your reasoning when it comes to the open ports and useless marketing hype. Nevertheless, I think that the word "stealth" fits very well in the case of closed ports as it makes it a (slight) bit harder to find if a host is up or not. Anyway, even if the OP's mail was a bit misleading, I think it would have helped him more if you had just explained what 'stealth' actually means, why you and steered him into the right direction in addition to what you wrote. And it would also have prevented this prolonged and utterly useless discussion we were leading ;) From bunchou at googlemail.com Wed Oct 7 15:48:51 2009 From: bunchou at googlemail.com (=?UTF-8?B?5paH6bOl?=) Date: Wed Oct 7 15:48:57 2009 Subject: freebsd-pf Digest, Vol 263, Issue 3 In-Reply-To: <23087185.63661254924619867.JavaMail.root@zimbra-store> References: <24402806.63641254924566875.JavaMail.root@zimbra-store> <23087185.63661254924619867.JavaMail.root@zimbra-store> Message-ID: <20091007174846.32846614@centaur.5550h.net> > Already many thanks for the info. I'v added already the "set > block-policy drop". I'v done an nmap and it's apparently able to find > out the setting below of my pf FW: > > MAC Address: 00:0E:2E:xx:xx:xx (Edimax Technology Co.) > Warning: OSScan results may be unreliable because we could not find > at least 1 open and 1 closed port Device type: general purpose > Running: FreeBSD 7.X > OS details: FreeBSD 7.1-PRERELEASE > Uptime guess: 0.000 days (since Wed Oct 07 16:02:00 2009) > Network Distance: 1 hop > TCP Sequence Prediction: Difficulty=260 (Good luck!) > IP ID Sequence Generation: Incremental > Service Info: OS: FreeBSD > > > Is there a way to block this info? Possible, but may be disruptive to your networking, depending on your network environment and what you block. As I know nothing about your setup or pf.conf, and thus cannot tell you anything more specific, I will just explain what you can do to investigate and reduce the flow of data, but from there on you're on your own. First of all, check what ICMP messages come through and consider blocking these (take a look at the relevant RFCs first, though). Secondly, you can capture the data that nmap sends and the other end's replies using tcpdump, wireshark, whatever. Of interest are the responses you actually get from the scanned host. Find out what protocols those responses belong to (google, etc.), decide whether it is worthwile to block that data and, finally, check 'man pf.conf' to see how to do just that. BTW: please limit the amount of text you quote. From simon.haller at gmx.net Wed Oct 7 19:02:42 2009 From: simon.haller at gmx.net (Simon Haller) Date: Wed Oct 7 19:02:49 2009 Subject: freebsd-pf Digest, Vol 263, Issue 3 In-Reply-To: <20091007174846.32846614@centaur.5550h.net> References: <24402806.63641254924566875.JavaMail.root@zimbra-store> <23087185.63661254924619867.JavaMail.root@zimbra-store> <20091007174846.32846614@centaur.5550h.net> Message-ID: just to add my two cents (some of it already mentioned): the default nmap-scan, depending on how initial tcp-handshake (SYN packet) with a particular port is carried out, displays 1.) "open" if a TCP SYN-packet is answered by a TCP SYN/ACK packet. 2.) "closed" if a TCP SYN-packet is answered by TCP RST packet. 3.) "filtered" if either no response is received (after retransmission of the TCP SYN-packet) or it is answered by a ICMP type 3 packet (unreachable error). so actually there is a difference between "closed" and "filtered" ports... *) "stealth-mode" a.k.a. "block-policy drop;" will let the firewall ignore TCP SYN requests to open ports (the port will appear as "filtered"), while *) "block-policy return;" will let the firewall return a TCP RST packet (the port will appear as "closed"), if a "TCP SYN" packet is sent to a blocked port. the OS-detection of nmap is based on different response tests using different types of packets to different ports (by default nmap scans the 1000 most common ports): all the above mentioned packets "TCP SYN/ACK", "TCP RST" and "ICMP type 3" give away information about the operating system. also responses to UDP packets and ICMP request give away information about the OS. without knowledge of the firewall and network setup it is not possible to say if it is possible and how to prevent the os detecting in the mentioned case... BR, simon haller Am 07.10.2009, 17:48 Uhr, schrieb ?? : >> Already many thanks for the info. I'v added already the "set >> block-policy drop". I'v done an nmap and it's apparently able to find >> out the setting below of my pf FW: >> >> MAC Address: 00:0E:2E:xx:xx:xx (Edimax Technology Co.) >> Warning: OSScan results may be unreliable because we could not find >> at least 1 open and 1 closed port Device type: general purpose >> Running: FreeBSD 7.X >> OS details: FreeBSD 7.1-PRERELEASE >> Uptime guess: 0.000 days (since Wed Oct 07 16:02:00 2009) >> Network Distance: 1 hop >> TCP Sequence Prediction: Difficulty=260 (Good luck!) >> IP ID Sequence Generation: Incremental >> Service Info: OS: FreeBSD >> >> >> Is there a way to block this info? > > Possible, but may be disruptive to your networking, depending on > your network environment and what you block. As I know nothing about > your setup or pf.conf, and thus cannot tell you anything more specific, > I will just explain what you can do to investigate and reduce the flow > of data, but from there on you're on your own. > > First of all, check what ICMP messages come through and consider > blocking these (take a look at the relevant RFCs first, though). > > Secondly, you can capture the data that nmap sends and the other > end's replies using tcpdump, wireshark, whatever. Of interest are the > responses you actually get from the scanned host. Find out what > protocols those responses belong to (google, etc.), decide > whether it is worthwile to block that data and, finally, check 'man > pf.conf' to see how to do just that. > > BTW: please limit the amount of text you quote. > _______________________________________________ > 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" -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From nico at elico-it.be Wed Oct 7 20:17:22 2009 From: nico at elico-it.be (Nico De Dobbeleer) Date: Wed Oct 7 20:17:30 2009 Subject: freebsd-pf Digest, Vol 263, Issue 3 In-Reply-To: <25442608.66481254946506174.JavaMail.root@zimbra-store> Message-ID: <32213363.66501254946635517.JavaMail.root@zimbra-store> Hey, Ok It's true, I need to provide you all with more info. This is the situation: My firewall has 3 networkcards 2 off them are in bridge (em0 and em1), 1 is used for administration (rl0). The goal is to use the bridge to filter all traffic to my servers behind the firewall. BUT the server behind the firewall must have a public ip-address hence the setup with the bridge because NAT is out of the question. The range of my severs is 62.213.196.60/28. In the config file you will see 10.0.0.0/8 addresses but that's just for testing purposes at home. @home there is a 10.0.0.50 ubuntu connected to a router and the router into the bridge of the FW. The admin NC has 10.0.0.200. This will all change into the 62.213.196.160/28 range once I put it in production. Hereby my config file I'm still testing so here and there you will see uncommented options): ____________________________________________________________________________ ####################### # Tables ####################### table { 10.0.0.0/8, 62.213.196.160/28 } table { 10.0.0.50, 62.213.196.174, 62.213.196.173, 62.213.196.172, 62.213.196.171, 62.213.196.170 } table { 10.0.0.200, 62.213.196.166, 62.213.196.167, 62.213.196.168, 62.213.196.169 } table { 62.213.196.164, 62.213.196.165 } ############################################################################ # Normalization rules: ############################################################################ #set block-policy drop set fingerprints "/etc/pf.os" set block-policy return # scrub incoming packets scrub in on { $ext_if, $int_if } all fragment reassemble min-ttl 15 max-mss 1400 scrub in on { $ext_if, $int_if } all no-df scrub on { $ext_if, $int_if } all reassemble tcp # Don't filter on the loopback interface set skip on $loop_if # this should block OS fingerprints?? block in log quick proto tcp flags FUP/WEUAPRSF block in log quick proto tcp flags WEUAPRSF/WEUAPRSF block in log quick proto tcp flags SRAFU/WEUAPRSF block in log quick proto tcp flags /WEUAPRSF block in log quick proto tcp flags SR/SR block in log quick proto tcp flags SF/SF block drop in on em0 all block drop out on em0 all block drop in on em1 all block drop out on em1 all block drop in on rl0 all block drop out on rl0 all # thwart nmap scans block in log quick on { $ext_if, $int_if, $mng_if } proto tcp all flags FUP/FUP block out log quick on { $ext_if, $int_if, $mng_if } proto tcp all flags FUP/FUP ############################################################################ # Filter rules: ############################################################################ # Allow public services to customers IP pass in quick on { $ext_if, $int_if } inet proto { tcp, udp } from any to port $public_services pass out quick on { $ext_if, $int_if } inet proto { tcp, udp } from any to port $public_services # Allow admin services to admin servers pass in quick on { $ext_if, $int_if, $mng_if } inet proto tcp from any to port $admin_services pass out quick on { $ext_if, $int_if, $mng_if } inet proto tcp from any to port $admin_services # Allow access to powerboots pass in quick on { $ext_if, $int_if } inet proto tcp from any to port $power_services pass out quick on { $ext_if, $int_if } inet proto tcp from any to port $power_services ____________________________________________________________________________________________ I hope you have more info now? Nico ----- Oorspronkelijk bericht ----- Van: "Simon Haller" Aan: "Nico De Dobbeleer" , "??" Cc: freebsd-pf@freebsd.org Verzonden: Woensdag 7 oktober 2009 20:35:58 Onderwerp: Re: freebsd-pf Digest, Vol 263, Issue 3 just to add my two cents (some of it already mentioned): the default nmap-scan, depending on how initial tcp-handshake (SYN packet) with a particular port is carried out, displays 1.) "open" if a TCP SYN-packet is answered by a TCP SYN/ACK packet. 2.) "closed" if a TCP SYN-packet is answered by TCP RST packet. 3.) "filtered" if either no response is received (after retransmission of the TCP SYN-packet) or it is answered by a ICMP type 3 packet (unreachable error). so actually there is a difference between "closed" and "filtered" ports... *) "stealth-mode" a.k.a. "block-policy drop;" will let the firewall ignore TCP SYN requests to open ports (the port will appear as "filtered"), while *) "block-policy return;" will let the firewall return a TCP RST packet (the port will appear as "closed"), if a "TCP SYN" packet is sent to a blocked port. the OS-detection of nmap is based on different response tests using different types of packets to different ports (by default nmap scans the 1000 most common ports): all the above mentioned packets "TCP SYN/ACK", "TCP RST" and "ICMP type 3" give away information about the operating system. also responses to UDP packets and ICMP request give away information about the OS. without knowledge of the firewall and network setup it is not possible to say if it is possible and how to prevent the os detecting in the mentioned case... BR, simon haller Am 07.10.2009, 17:48 Uhr, schrieb ?? : >> Already many thanks for the info. I'v added already the "set >> block-policy drop". I'v done an nmap and it's apparently able to find >> out the setting below of my pf FW: >> >> MAC Address: 00:0E:2E:xx:xx:xx (Edimax Technology Co.) >> Warning: OSScan results may be unreliable because we could not find >> at least 1 open and 1 closed port Device type: general purpose >> Running: FreeBSD 7.X >> OS details: FreeBSD 7.1-PRERELEASE >> Uptime guess: 0.000 days (since Wed Oct 07 16:02:00 2009) >> Network Distance: 1 hop >> TCP Sequence Prediction: Difficulty=260 (Good luck!) >> IP ID Sequence Generation: Incremental >> Service Info: OS: FreeBSD >> >> >> Is there a way to block this info? > > Possible, but may be disruptive to your networking, depending on > your network environment and what you block. As I know nothing about > your setup or pf.conf, and thus cannot tell you anything more specific, > I will just explain what you can do to investigate and reduce the flow > of data, but from there on you're on your own. > > First of all, check what ICMP messages come through and consider > blocking these (take a look at the relevant RFCs first, though). > > Secondly, you can capture the data that nmap sends and the other > end's replies using tcpdump, wireshark, whatever. Of interest are the > responses you actually get from the scanned host. Find out what > protocols those responses belong to (google, etc.), decide > whether it is worthwile to block that data and, finally, check 'man > pf.conf' to see how to do just that. > > BTW: please limit the amount of text you quote. > _______________________________________________ > 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" -- Erstellt mit Operas revolution?rem E-Mail-Modul: http://www.opera.com/mail/ From jumper99 at gmx.de Thu Oct 8 10:02:39 2009 From: jumper99 at gmx.de (Helmut Schneider) Date: Thu Oct 8 10:02:46 2009 Subject: freebsd-pf Stealth Modus References: <6422287.58441254834893591.JavaMail.root@zimbra-store><49F0693DC96541B4B9D7B61599A12CA4@vpe.de><20091006182241.79d16c8c@centaur.5550h.net><20091006210912.379434eb@centaur.5550h.net> <20091007171133.21cf50ce@centaur.5550h.net> Message-ID: ?? wrote: > On Wed, 7 Oct 2009 11:40:36 +0200 > "Helmut Schneider" wrote: >> I know the term "stealth firewall" very well. It's a worthless >> marketing buzzword. It suggests users that it could prevent an attack >> or even the scan itself. Neither is correct. This is what I wanted to >> point out and I was encouraged by the fact that the OP was talking >> about "stealthing" open ports. > > Ok, I totally agree with your reasoning when it comes to the open > ports and useless marketing hype. Nevertheless, I think that the word > "stealth" fits very well in the case of closed ports as it makes it > a (slight) bit harder to find if a host is up or not. Well, I still disagree. > Anyway, even if the OP's mail was a bit misleading, I think > it would have helped him more if you had just explained what > 'stealth' actually means, why you and steered him into the right > direction in addition to what you wrote. And it would also have > prevented this prolonged and utterly useless discussion we were > leading ;) Again I disagree, I expect this discussion to be useful for many others. But I agree, we should stop at that point. :) Helmut From jhell at DataIX.net Sat Oct 10 02:40:18 2009 From: jhell at DataIX.net (jhell) Date: Sat Oct 10 02:40:24 2009 Subject: return-icmp() relative question to ipf rule. Message-ID: I have a rule I used in ipfilter probably around 2 or so years ago and I am now getting around to trying to implement in it my pf rules. So far any results I have achieved have failed with no response back from the server and get dropped. The rule in ipf syntax: block return-icmp-as-dest(13) in log first quick proto icmp all icmp-type 8 The above ipf rule returns a result of "Destination Administratively Prohibited" when ping'd The following pf syntax: block return-icmp(3,13) in quick inet proto icmp from any to any icmp-type 8 code 0 The above pf rule returns a result of "Nothing ........" when ping'd Just to be sure I wasn't mucking up the chain of rules I added this as the only rule to test it out and have achieved the same result multiple times on a test machine. Can anyone shed some light on the syntax and help me out with getting this rule to make the system respond to a echo request with admin-prohib as the destination system ? Thanks -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2 Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E From bugmaster at FreeBSD.org Mon Oct 12 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 12 11:08:57 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200910121106.n9CB6wBu036495@freefall.freebsd.org> 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/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg 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 36 problems total. From ml at infosec.pl Thu Oct 15 20:45:27 2009 From: ml at infosec.pl (Michal) Date: Thu Oct 15 20:45:33 2009 Subject: pf starts too early Message-ID: <4AD79180.204@infosec.pl> Hello, I'm using pf on FreeBSD 8.0-RC1. My wlan0-ath0 card is set up via wpa_supplicant.conf and rc.conf (ifconfig_wlan0="WPA DHCP"). pf also starts via rc.conf Problem is that pf cannot start during the system boot because it tries to load rules before my network card gets authenticated and connected. Since wlan0 doesn't have IP address at the time I get a lot of: no IP address found for wlan0 /etc/pf.conf:151: could not parse host specification no IP address found for wlan0 pfctl: Syntax error in config file: pf rules not loaded pf enabled It fills up my dmesg output. Loading rules by hand works perfectly fine. Any ideas what is wrong or which part of the system should I tweak? Michal -- "Attacks always get better; they never get worse." -NSA From mkhitrov at gmail.com Thu Oct 15 21:06:18 2009 From: mkhitrov at gmail.com (Maxim Khitrov) Date: Thu Oct 15 21:06:24 2009 Subject: pf starts too early In-Reply-To: <4AD79180.204@infosec.pl> References: <4AD79180.204@infosec.pl> Message-ID: <26ddd1750910151405t79e78781reb417076d60bab45@mail.gmail.com> On Thu, Oct 15, 2009 at 5:17 PM, Michal wrote: > Hello, > > I'm using pf on FreeBSD 8.0-RC1. My wlan0-ath0 card is set up via > wpa_supplicant.conf and rc.conf (ifconfig_wlan0="WPA DHCP"). pf also starts > via rc.conf > > Problem is that pf cannot start during the system boot because it tries to > load rules before my network card gets authenticated and connected. Since > wlan0 doesn't have IP address at the time I get a lot of: > > no IP address found for wlan0 > /etc/pf.conf:151: could not parse host specification > no IP address found for wlan0 > pfctl: Syntax error in config file: pf rules not loaded > pf enabled > > It fills up my dmesg output. Loading rules by hand works perfectly fine. > > Any ideas what is wrong or which part of the system should I tweak? > > Michal See the post I made a few weeks ago on this topic: http://lists.freebsd.org/pipermail/freebsd-pf/2009-September/005329.html You may need to tweak the REQUIRE line in /etc/rc.d/pf for your needs, but otherwise this solution has been working for me without any problems. Just need to be careful not to revert changes when running mergemaster. - Max From max at love2party.net Thu Oct 15 22:17:26 2009 From: max at love2party.net (Max Laier) Date: Thu Oct 15 22:17:33 2009 Subject: pf starts too early In-Reply-To: <4AD79180.204@infosec.pl> References: <4AD79180.204@infosec.pl> Message-ID: <200910160017.34339.max@love2party.net> On Thursday 15 October 2009 23:17:52 Michal wrote: > Hello, > > I'm using pf on FreeBSD 8.0-RC1. My wlan0-ath0 card is set up via > wpa_supplicant.conf and rc.conf (ifconfig_wlan0="WPA DHCP"). pf also > starts via rc.conf > > Problem is that pf cannot start during the system boot because it tries > to load rules before my network card gets authenticated and connected. > Since wlan0 doesn't have IP address at the time I get a lot of: > > no IP address found for wlan0 > /etc/pf.conf:151: could not parse host specification > no IP address found for wlan0 > pfctl: Syntax error in config file: pf rules not loaded > pf enabled simply s/wlan0/(wlan0)/ where is appears in a host/address context. This is an FAQ. > It fills up my dmesg output. Loading rules by hand works perfectly fine. > > Any ideas what is wrong or which part of the system should I tweak? > > Michal > -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From ml at infosec.pl Thu Oct 15 22:51:08 2009 From: ml at infosec.pl (Michal) Date: Thu Oct 15 22:51:14 2009 Subject: pf starts too early In-Reply-To: <200910160017.34339.max@love2party.net> References: <4AD79180.204@infosec.pl> <200910160017.34339.max@love2party.net> Message-ID: <4AD7B543.6000700@infosec.pl> Max Laier wrote: > > simply s/wlan0/(wlan0)/ where is appears in a host/address context. This is > an FAQ. > Thank you, looks that it does the trick. And sorry for missing that one. Michal -- "The future is here. It's just not widely distributed yet." -William Gibson From bugmaster at FreeBSD.org Mon Oct 19 11:06:59 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 19 11:09:04 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200910191106.n9JB6wrp063525@freefall.freebsd.org> 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/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg 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 36 problems total. From omerfsen at gmail.com Mon Oct 19 12:08:30 2009 From: omerfsen at gmail.com (Omer Faruk Sen) Date: Mon Oct 19 12:08:37 2009 Subject: port based round robin Message-ID: <75a268720910190435n48897e42v44afd0ba0ded1c96@mail.gmail.com> Hi, As far as I have seen from manual pages round-robin works for IP addresses only. But I want it to work for port based. Here is what I want to do: 127.0.0.1:1234 ---> 127.0.0.1:1235 ---> 127.0.0.1:1236 Is that possible with pf? Regards. From jedgainer at gmail.com Mon Oct 19 16:15:57 2009 From: jedgainer at gmail.com (Jed Gainer) Date: Mon Oct 19 16:16:04 2009 Subject: PF - load balancing outgoing connections Message-ID: <36b1f3e60910190848h382cde04l104f2a9f466af3fa@mail.gmail.com> I wanted to setup a machine as my LAN gateway and have it load balance over multiple WANs. When I found http://www.openbsd.org/faq/pf/pools.html I choose FreeBSD as the machines OS. After getting it up and running, and acting as a gateway just using one WAN via *# macros wan1="nfe0" lan1="rl0" pc1="10.0.0.2" xb1="10.0.0.3" # options #set block-policy return #set loginterface $wan1 set skip on lo0 # scrub scrub in # nat/rdr nat on $wan1 from !($wan1) -> ($wan1:0) static-port # uTorrent rdr on $wan1 proto tcp from any to any port 41016 -> $pc1 # Xbox Live rdr on $wan1 proto {tcp, udp} from any to any port 3074 -> $xb1* I decided to try the load balancing and came up with quite a few different pf.confs that did not work, my LAN just lost all connectivity when I loaded them. * lan1r = "10.0.0.0/24" lan1 = "rl0" wan1 = "nfe0" wan2 = "rl1" gw1 = "10.0.1.2" gw2 = "10.0.2.2" # nat outgoing connections on each internet interface nat on $wan1 from $lan1r to any -> ($wan1) #static-port nat on $wan2 from $lan1r to any -> ($wan2) #static-port # default deny block in from any to any block out from any to any # pass all outgoing packets on internal interface pass out on $lan1 from any to $lan1r # pass in quick any packets destined for the gateway itself pass in quick on $lan1 from $lan1r to $lan1 # load balance outgoing tcp traffic from internal network. pass in on $lan1 route-to { ($wan1 $gw1), ($wan2 $gw2) } round-robin proto tcp from $lan1r to any flags S/SA modulate state # load balance outgoing udp and icmp traffic from internal network pass in on $lan1 route-to { ($wan1 $gw1), ($wan2 $gw2) } round-robin proto { udp, icmp } from $lan1r to any keep state # general "pass out" rules for external interfaces pass out on $wan1 proto tcp from any to any flags S/SA modulate state pass out on $wan1 proto { udp, icmp } from any to any keep state pass out on $wan2 proto tcp from any to any flags S/SA modulate state pass out on $wan2 proto { udp, icmp } from any to any keep state # route packets from any IPs on $ext_if1 to $ext_gw1 and the same for $ext_if2 and $ext_gw2 pass out on $wan1 route-to ($wan2 $gw2) from $wan2 to any pass out on $wan2 route-to ($wan1 $gw1) from $wan1 to any* ... and ... *lan = rl0 wan1 = nfe0 wan2 = rl1 wan1_gw = 173.183.32.254 wan2_gw = 10.0.1.2 nat on $wan1 from any to any -> ($wan1) nat on $wan2 from any to any -> ($wan2) pass in quick on $lan route-to { ($wan1 $wan1_gw), ($wan2 $wan2_gw) } \ round-robin inet from ($lan:network) to any flags S/SA keep state* Neither of the above worked, or the many other attempts I made. No errors are reported when I `pfctl -f /etc/pf.lb.conf` and my LAN looses internet connectivity. Does any one see the problem? I can ping Google fine using either WAN as default route so it has to be my PF conf. I am at the point where I will pay someone to get it working! -- ~ Jed Gainer From mike at jellydonut.org Mon Oct 19 16:55:34 2009 From: mike at jellydonut.org (Michael Proto) Date: Mon Oct 19 16:55:41 2009 Subject: PF - load balancing outgoing connections In-Reply-To: <36b1f3e60910190848h382cde04l104f2a9f466af3fa@mail.gmail.com> References: <36b1f3e60910190848h382cde04l104f2a9f466af3fa@mail.gmail.com> Message-ID: <1de79840910190934w358e711t781f39061e16991@mail.gmail.com> On Mon, Oct 19, 2009 at 11:48 AM, Jed Gainer wrote: > I wanted to setup a machine as my LAN gateway and have it load balance over > multiple WANs. When I found http://www.openbsd.org/faq/pf/pools.html I > choose FreeBSD as the machines OS. After getting it up and running, and > acting as a gateway just using one WAN via > > *# macros > wan1="nfe0" > lan1="rl0" > > pc1="10.0.0.2" > xb1="10.0.0.3" > > # options > #set block-policy return > #set loginterface $wan1 > set skip on lo0 > > # scrub > scrub in > > # nat/rdr > nat on $wan1 from !($wan1) -> ($wan1:0) static-port > > # uTorrent > rdr on $wan1 proto tcp from any to any port 41016 -> $pc1 > > # Xbox Live > rdr on $wan1 proto {tcp, udp} from any to any port 3074 -> $xb1* > > I decided to try the load balancing and came up with quite a few different > pf.confs that did not work, my LAN just lost all connectivity when I loaded > them. > * > lan1r = "10.0.0.0/24" > lan1 ?= "rl0" > wan1 = "nfe0" > wan2 = "rl1" > gw1 = "10.0.1.2" > gw2 = "10.0.2.2" > > # nat outgoing connections on each internet interface > nat on $wan1 from $lan1r to any -> ($wan1) #static-port > nat on $wan2 from $lan1r to any -> ($wan2) #static-port > > # default deny > block in from any to any > block out from any to any > > # pass all outgoing packets on internal interface > pass out on $lan1 from any to $lan1r > > # pass in quick any packets destined for the gateway itself > pass in quick on $lan1 from $lan1r to $lan1 > > # load balance outgoing tcp traffic from internal network. > pass in on $lan1 route-to { ($wan1 $gw1), ($wan2 $gw2) } round-robin proto > tcp from $lan1r to any flags S/SA modulate state > > # load balance outgoing udp and icmp traffic from internal network > pass in on $lan1 route-to { ($wan1 $gw1), ($wan2 $gw2) } round-robin proto { > udp, icmp } from $lan1r to any keep state > > # general "pass out" rules for external interfaces > pass out on $wan1 proto tcp from any to any flags S/SA modulate state > pass out on $wan1 proto { udp, icmp } from any to any keep state > pass out on $wan2 proto tcp from any to any flags S/SA modulate state > pass out on $wan2 proto { udp, icmp } from any to any keep state > > # route packets from any IPs on $ext_if1 to $ext_gw1 and the same for > $ext_if2 and $ext_gw2 > pass out on $wan1 route-to ($wan2 $gw2) from $wan2 to any > pass out on $wan2 route-to ($wan1 $gw1) from $wan1 to any* > > ... and ... > > *lan = rl0 > wan1 = nfe0 > wan2 = rl1 > wan1_gw = 173.183.32.254 > wan2_gw = 10.0.1.2 > > nat on $wan1 from any to any -> ($wan1) > nat on $wan2 from any to any -> ($wan2) > > pass in quick on $lan route-to { ($wan1 $wan1_gw), ($wan2 $wan2_gw) } \ > ?round-robin inet from ($lan:network) to any flags S/SA keep state* > > Neither of the above worked, or the many other attempts I made. > > No errors are reported when I `pfctl -f /etc/pf.lb.conf` and my LAN looses > internet connectivity. > > Does any one see the problem? I can ping Google fine using either WAN as > default route so it has to be my PF conf. > > I am at the point where I will pay someone to get it working! > -- > ~ Jed Gainer > _______________________________________________ > 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" > Correct me if I'm wrong, but I don't think you can do this without running a routing protocol with your upstream ISP. The problem is, regardless of which connection you send your traffic out, the return traffic will always come the same route from your ISP(s). If you send your traffic out $wan2 but your IP space is advertised by your ISP on $wan1 the traffic will always come back in $wan1 and you'll have an asymmetric route (as well as messed-up states in pf on the $wan1 and $wan2 interfaces). The only way I've been able to load-balance outbound traffic is to have different upstream routers advertise different routes back to my network via BGP and work the load-balancing that way. -Proto From leccine at gmail.com Tue Oct 20 00:20:24 2009 From: leccine at gmail.com (=?UTF-8?Q?Istv=C3=A1n?=) Date: Tue Oct 20 00:20:30 2009 Subject: PF - load balancing outgoing connections In-Reply-To: <36b1f3e60910190848h382cde04l104f2a9f466af3fa@mail.gmail.com> References: <36b1f3e60910190848h382cde04l104f2a9f466af3fa@mail.gmail.com> Message-ID: what does pflogd say about this? i mean have you tried to enable logging and check it? http://www.openbsd.org/cgi-bin/man.cgi?query=pflogd&sektion=8 Regards, Istvan On Mon, Oct 19, 2009 at 4:48 PM, Jed Gainer wrote: > I wanted to setup a machine as my LAN gateway and have it load balance over > multiple WANs. When I found http://www.openbsd.org/faq/pf/pools.html I > choose FreeBSD as the machines OS. After getting it up and running, and > acting as a gateway just using one WAN via > > *# macros > wan1="nfe0" > lan1="rl0" > > pc1="10.0.0.2" > xb1="10.0.0.3" > > # options > #set block-policy return > #set loginterface $wan1 > set skip on lo0 > > # scrub > scrub in > > # nat/rdr > nat on $wan1 from !($wan1) -> ($wan1:0) static-port > > # uTorrent > rdr on $wan1 proto tcp from any to any port 41016 -> $pc1 > > # Xbox Live > rdr on $wan1 proto {tcp, udp} from any to any port 3074 -> $xb1* > > I decided to try the load balancing and came up with quite a few different > pf.confs that did not work, my LAN just lost all connectivity when I loaded > them. > * > lan1r = "10.0.0.0/24" > lan1 = "rl0" > wan1 = "nfe0" > wan2 = "rl1" > gw1 = "10.0.1.2" > gw2 = "10.0.2.2" > > # nat outgoing connections on each internet interface > nat on $wan1 from $lan1r to any -> ($wan1) #static-port > nat on $wan2 from $lan1r to any -> ($wan2) #static-port > > # default deny > block in from any to any > block out from any to any > > # pass all outgoing packets on internal interface > pass out on $lan1 from any to $lan1r > > # pass in quick any packets destined for the gateway itself > pass in quick on $lan1 from $lan1r to $lan1 > > # load balance outgoing tcp traffic from internal network. > pass in on $lan1 route-to { ($wan1 $gw1), ($wan2 $gw2) } round-robin proto > tcp from $lan1r to any flags S/SA modulate state > > # load balance outgoing udp and icmp traffic from internal network > pass in on $lan1 route-to { ($wan1 $gw1), ($wan2 $gw2) } round-robin proto > { > udp, icmp } from $lan1r to any keep state > > # general "pass out" rules for external interfaces > pass out on $wan1 proto tcp from any to any flags S/SA modulate state > pass out on $wan1 proto { udp, icmp } from any to any keep state > pass out on $wan2 proto tcp from any to any flags S/SA modulate state > pass out on $wan2 proto { udp, icmp } from any to any keep state > > # route packets from any IPs on $ext_if1 to $ext_gw1 and the same for > $ext_if2 and $ext_gw2 > pass out on $wan1 route-to ($wan2 $gw2) from $wan2 to any > pass out on $wan2 route-to ($wan1 $gw1) from $wan1 to any* > > ... and ... > > *lan = rl0 > wan1 = nfe0 > wan2 = rl1 > wan1_gw = 173.183.32.254 > wan2_gw = 10.0.1.2 > > nat on $wan1 from any to any -> ($wan1) > nat on $wan2 from any to any -> ($wan2) > > pass in quick on $lan route-to { ($wan1 $wan1_gw), ($wan2 $wan2_gw) } \ > round-robin inet from ($lan:network) to any flags S/SA keep state* > > Neither of the above worked, or the many other attempts I made. > > No errors are reported when I `pfctl -f /etc/pf.lb.conf` and my LAN looses > internet connectivity. > > Does any one see the problem? I can ping Google fine using either WAN as > default route so it has to be my PF conf. > > I am at the point where I will pay someone to get it working! > -- > ~ Jed Gainer > _______________________________________________ > 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" > -- the sun shines for all http://l1xl1x.blogspot.com From reed at reedmedia.net Tue Oct 20 23:01:54 2009 From: reed at reedmedia.net (Jeremy C. Reed) Date: Tue Oct 20 23:02:01 2009 Subject: tool to dump and restore pf(4) state Message-ID: See this blog: http://blog.netbsd.org/tnf/entry/summer_of_code_results_a "... a working pfs tool which is able to dump / restore the internal state table of pf ..." From bugmaster at FreeBSD.org Mon Oct 26 11:07:05 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 26 11:09:28 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200910261107.n9QB743n043842@freefall.freebsd.org> 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/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg 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 36 problems total. From remko at elvandar.org Mon Oct 26 13:33:57 2009 From: remko at elvandar.org (Remko Lodder) Date: Mon Oct 26 13:34:04 2009 Subject: return-icmp() relative question to ipf rule. In-Reply-To: References: Message-ID: On Oct 10, 2009, at 4:09 AM, jhell wrote: > > I have a rule I used in ipfilter probably around 2 or so years ago > and I am now getting around to trying to implement in it my pf > rules. So far any results I have achieved have failed with no > response back from the server and get dropped. > > The rule in ipf syntax: > block return-icmp-as-dest(13) in log first quick proto icmp all icmp- > type 8 > > The above ipf rule returns a result of "Destination Administratively > Prohibited" when ping'd > > The following pf syntax: > block return-icmp(3,13) in quick inet proto icmp from any to any > icmp-type 8 code 0 > > The above pf rule returns a result of "Nothing ........" when ping'd > > Just to be sure I wasn't mucking up the chain of rules I added this > as the only rule to test it out and have achieved the same result > multiple times on a test machine. > > Can anyone shed some light on the syntax and help me out with > getting this rule to make the system respond to a echo request with > admin-prohib as the destination system ? > > Thanks > *click* (the light is on) Options returning ICMP packets currently have no effect if pf(4) operates on a if_bridge(4), as the code to support this feature has not yet been implemented. from the Manual page. I think that answers the question? -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From jhell at DataIX.net Mon Oct 26 15:02:38 2009 From: jhell at DataIX.net (jhell) Date: Mon Oct 26 15:02:45 2009 Subject: return-icmp() relative question to ipf rule. In-Reply-To: References: Message-ID: On Mon, 26 Oct 2009 09:18, remko@ wrote: > On Oct 10, 2009, at 4:09 AM, jhell wrote: > >> >> I have a rule I used in ipfilter probably around 2 or so years ago and I am >> now getting around to trying to implement in it my pf rules. So far any >> results I have achieved have failed with no response back from the server >> and get dropped. >> >> The rule in ipf syntax: >> block return-icmp-as-dest(13) in log first quick proto icmp all icmp-type 8 >> >> The above ipf rule returns a result of "Destination Administratively >> Prohibited" when ping'd >> >> The following pf syntax: >> block return-icmp(3,13) in quick inet proto icmp from any to any icmp-type >> 8 code 0 >> >> The above pf rule returns a result of "Nothing ........" when ping'd >> >> Just to be sure I wasn't mucking up the chain of rules I added this as the >> only rule to test it out and have achieved the same result multiple times >> on a test machine. >> >> Can anyone shed some light on the syntax and help me out with getting this >> rule to make the system respond to a echo request with admin-prohib as the >> destination system ? >> >> Thanks >> > > > *click* (the light is on) > > Options returning ICMP packets currently have no effect if pf(4) > operates on a if_bridge(4), as the code to support this feature has > not yet been implemented. > > from the Manual page. I think that answers the question? > Thanks Remko, No I'm not using if_bridge(4) here, nor any bridge for that matter. I have tested this directly from interface -> interface with a patch cable thinking that the click that I heard from the light above would actually turn something on but was just throwing a breaker. I also have turned my WiFi NIC into a ad-hoc connection and threw the rule on it instead of the test box and then ran a ping(8) from a direct connect and the same thing happens. Same thing from directly connecting to the AP. So unless what you are telling me above is that all interfaces no matter what they are, operate in a bridge mode and the code is missing then I am really confused. -- This does not need to be answered as I know that's not the case. Or the code is just missing to do this all together, in turn I would like to throw a voiced question of "where did it go ?" this was in IPF before pf started making its way through the circuit. The conclusion from what I see thus far is that all the return-icmp* context in the pf.conf(5) man page is false for FreeBSD at least 7.2 right now, as I can't account for earlier or later releases at this point. FreeBSD 7.2-STABLE #0 r198446: Sun Oct 25 16:40:39 EDT 2009 Still obtaining small flicker of light from circuit breaker, Best regards. -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2 Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E From remko at elvandar.org Wed Oct 28 08:23:19 2009 From: remko at elvandar.org (Remko Lodder) Date: Wed Oct 28 08:23:25 2009 Subject: return-icmp() relative question to ipf rule. In-Reply-To: References: Message-ID: <086A9580-906E-406A-AB00-FC47D6EE72D9@elvandar.org> On Oct 26, 2009, at 4:02 PM, jhell wrote: > > On Mon, 26 Oct 2009 09:18, remko@ wrote: >> On Oct 10, 2009, at 4:09 AM, jhell wrote: >> >>> I have a rule I used in ipfilter probably around 2 or so years ago >>> and I am now getting around to trying to implement in it my pf >>> rules. So far any results I have achieved have failed with no >>> response back from the server and get dropped. >>> The rule in ipf syntax: >>> block return-icmp-as-dest(13) in log first quick proto icmp all >>> icmp-type 8 >>> The above ipf rule returns a result of "Destination >>> Administratively Prohibited" when ping'd >>> The following pf syntax: >>> block return-icmp(3,13) in quick inet proto icmp from any to any >>> icmp-type 8 code 0 >>> The above pf rule returns a result of "Nothing ........" when ping'd >>> Just to be sure I wasn't mucking up the chain of rules I added >>> this as the only rule to test it out and have achieved the same >>> result multiple times on a test machine. >>> Can anyone shed some light on the syntax and help me out with >>> getting this rule to make the system respond to a echo request >>> with admin-prohib as the destination system ? >>> Thanks >> >> >> *click* (the light is on) >> >> Options returning ICMP packets currently have no effect if >> pf(4) >> operates on a if_bridge(4), as the code to support this >> feature has >> not yet been implemented. >> >> from the Manual page. I think that answers the question? >> > > Thanks Remko, > > No I'm not using if_bridge(4) here, nor any bridge for that matter. > I have tested this directly from interface -> interface with a patch > cable thinking that the click that I heard from the light above > would actually turn something on but was just throwing a breaker. OK, yes I understand what you mean. I over-read the bridge part. My apologies for the confusion this caused. I am not sure whether it then should or should not work though. One thing that I noticed is that you speak about 'it was in IPF and it isn't in PF', please keep in mind that PF is a complete rewrite and looks similiar to IPF with syntax etc. Features found there are no guarantee that it will be in PF as well. Doesn't make up the fact that the documentation indeed talks about it being possible and seemingly impossible to do it. I added Max to the discussion, he might be able to tell whether or not this is integrated and whether it should work at all :-) Thanks for catching my misread part! -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From jhell at DataIX.net Wed Oct 28 17:22:54 2009 From: jhell at DataIX.net (jhell) Date: Wed Oct 28 17:23:01 2009 Subject: return-icmp() relative question to ipf rule. In-Reply-To: <086A9580-906E-406A-AB00-FC47D6EE72D9@elvandar.org> References: <086A9580-906E-406A-AB00-FC47D6EE72D9@elvandar.org> Message-ID: On Wed, 28 Oct 2009 04:23, remko@ wrote: > On Oct 26, 2009, at 4:02 PM, jhell wrote: > >> >> On Mon, 26 Oct 2009 09:18, remko@ wrote: >>> On Oct 10, 2009, at 4:09 AM, jhell wrote: >>> >>>> I have a rule I used in ipfilter probably around 2 or so years ago and I >>>> am now getting around to trying to implement in it my pf rules. So far >>>> any results I have achieved have failed with no response back from the >>>> server and get dropped. >>>> The rule in ipf syntax: >>>> block return-icmp-as-dest(13) in log first quick proto icmp all icmp-type >>>> 8 >>>> The above ipf rule returns a result of "Destination Administratively >>>> Prohibited" when ping'd >>>> The following pf syntax: >>>> block return-icmp(3,13) in quick inet proto icmp from any to any >>>> icmp-type 8 code 0 >>>> The above pf rule returns a result of "Nothing ........" when ping'd >>>> Just to be sure I wasn't mucking up the chain of rules I added this as >>>> the only rule to test it out and have achieved the same result multiple >>>> times on a test machine. >>>> Can anyone shed some light on the syntax and help me out with getting >>>> this rule to make the system respond to a echo request with admin-prohib >>>> as the destination system ? >>>> Thanks >>> >>> >>> *click* (the light is on) >>> >>> Options returning ICMP packets currently have no effect if pf(4) >>> operates on a if_bridge(4), as the code to support this feature has >>> not yet been implemented. >>> >>> from the Manual page. I think that answers the question? >>> >> >> Thanks Remko, >> >> No I'm not using if_bridge(4) here, nor any bridge for that matter. I have >> tested this directly from interface -> interface with a patch cable >> thinking that the click that I heard from the light above would actually >> turn something on but was just throwing a breaker. > > > OK, yes I understand what you mean. I over-read the bridge part. My apologies > for the confusion this caused. I am not sure whether it then should or should > not work though. One thing that I noticed is that you speak about > 'it was in IPF and it isn't in PF', please keep in mind that PF is a complete > rewrite and looks similiar to IPF with syntax etc. Features found there are > no guarantee that it will be in PF as well. Doesn't make up the fact that the > documentation indeed talks about it being possible and seemingly impossible > to do it. > > I added Max to the discussion, he might be able to tell whether or not this > is integrated and whether it should work at all :-) > > Thanks for catching my misread part! > Hey its no problem at all, I appreciate the feedback because I thought that possibly I might have missed something that wasn't allowing it to work but I have tried all kinds of trickery around the likes of adding pass out all rules of type ICMP with specific codes and such before and after the rule in question and nothing seems to do it. So some input on this was better than none at all. Thanks for your response and can't wait for some more interaction on this thread as this has now just become a annoying unreachable objective for me. Best regards. -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2 Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E From nico at elico-it.be Sat Oct 31 21:00:13 2009 From: nico at elico-it.be (Nico De Dobbeleer) Date: Sat Oct 31 21:00:36 2009 Subject: freebsd-pf Digest, Vol 266, Issue 4 In-Reply-To: <2849417.188201257022710812.JavaMail.root@zimbra-store> Message-ID: <3350817.188221257022804727.JavaMail.root@zimbra-store> Hello, I have an issue with pf bridge. This is my setup Wan --> pf-bridge --> servers (mail, webserver with public IP) When I activate my pf-bridge FW It allows the things as it should be (http, rdp, ssh, ...) But when I try to send a mail for example it cannot find hostname or when I'm connected to the webserver over RDP I cannot browse. It's like I can get in to the correct ports but from the inside I'm not allowed to do stuff. Here's pf-bridge.conf: # #################### # Macro's #################### ext_if="em0" int_if="em1" mng_if="rl0" loop_if="lo0" public_services="{ ssh, http, https, smtp, pop3, imap, 7071, 53, 3389 }" admin_services="{ ssh, http, https }" power_services="{ telnet, http }" # TCP Options #TCP_Options="flags S/SAFRUP modulate state" # UDP Options #UDP_Options="keep state" ####################### # Tables ####################### table { 62.213.196.XXX/xx } table { 62.213.196.xxx, 62.213.196.xxx, 62.213.196.xxx, 62.213.196.xxx, 62.213.196.xxx, 62.213.196.xxx } table { 62.213.196.xxx, 62.213.196.xxx, 62.213.196.xxx, 62.213.196.xxx } table { 62.213.196.xxx, 62.213.196.xxx } ############################################################################ # Normalization rules: ############################################################################ #set block-policy drop #set fingerprints "/etc/pf.os" set block-policy return # scrub incoming packets scrub in on { $ext_if, $int_if } all fragment reassemble min-ttl 15 max-mss 1400 scrub in on { $ext_if, $int_if } all no-df scrub on { $ext_if, $int_if } all reassemble tcp # Don't filter on the loopback interface set skip on $loop_if # this should block OS fingerprints?? block in log quick proto tcp flags FUP/WEUAPRSF block in log quick proto tcp flags WEUAPRSF/WEUAPRSF block in log quick proto tcp flags SRAFU/WEUAPRSF block in log quick proto tcp flags /WEUAPRSF block in log quick proto tcp flags SR/SR block in log quick proto tcp flags SF/SF # thwart nmap scans block in log quick on { $ext_if, $int_if, $mng_if } proto tcp all flags SEFUP/SEFUP block out log quick on { $ext_if, $int_if, $mng_if } proto tcp all flags SEFUP/SEFUP ############################################################################ # Filter rules: ############################################################################ # Allow public services to customers IP pass in quick on { $ext_if, $int_if } inet proto { tcp, udp } from any to port $public_services pass out quick on { $ext_if, $int_if } inet proto { tcp, udp } from any to port $public_services # Allow admin services to admin servers pass in quick on { $ext_if, $int_if, $mng_if } inet proto tcp from any to port $admin_services pass out quick on { $ext_if, $int_if, $mng_if } inet proto tcp from any to port $admin_services # Allow access to powerboots pass in quick on { $ext_if, $int_if } inet proto tcp from any to port $power_services pass out quick on { $ext_if, $int_if } inet proto tcp from any to port $power_services block drop in on $ext_if all block drop out on $ext_if all block drop in on $int_if all block drop out on $int_if all Any idea's? From tom at uffner.com Sat Oct 31 21:52:17 2009 From: tom at uffner.com (Tom Uffner) Date: Sat Oct 31 21:52:23 2009 Subject: freebsd-pf Digest, Vol 266, Issue 4 In-Reply-To: <3350817.188221257022804727.JavaMail.root@zimbra-store> References: <3350817.188221257022804727.JavaMail.root@zimbra-store> Message-ID: <4AECB18F.30106@uffner.com> Nico De Dobbeleer wrote: > # this should block OS fingerprints?? > block in log quick proto tcp flags FUP/WEUAPRSF > block in log quick proto tcp flags WEUAPRSF/WEUAPRSF > block in log quick proto tcp flags SRAFU/WEUAPRSF > block in log quick proto tcp flags /WEUAPRSF > block in log quick proto tcp flags SR/SR > block in log quick proto tcp flags SF/SF > > # thwart nmap scans > block in log quick on { $ext_if, $int_if, $mng_if } proto tcp all flags SEFUP/SEFUP > block out log quick on { $ext_if, $int_if, $mng_if } proto tcp all flags SEFUP/SEFUP > > Any idea's? yeah. replace all of the strange flag combinations with a simple "block log all" rule. get basic firewall functionality working first, then add the fancy stuff back one rule at a time & test to see what breaks. and when adding the above rules, think about whether you really want "quick". i'm amazed that any TCP gets through that ruleset in either direction.