From news at topocentras.lt Fri Aug 1 10:07:20 2008 From: news at topocentras.lt (news@topocentras.lt) Date: Fri Aug 1 10:07:27 2008 Subject: need help with keep state and shaping In-Reply-To: <50928.88.119.128.115.1217406553.squirrel@mx.agservice.lt> References: <51307.88.119.128.115.1217227945.squirrel@mx.agservice.lt> <64686.88.119.128.115.1217400195.squirrel@mx.agservice.lt> <1217406136.31805.6.camel@buchtajz> <50928.88.119.128.115.1217406553.squirrel@mx.agservice.lt> Message-ID: <56637.88.119.128.115.1217585235.squirrel@mx.agservice.lt> Hello once more, What difference in state-policy floating and if-bound? If i am using tagging for incoming and outgoing traffic? Which policy I need to use? Thanks, Albertas > Thanks for suggestion. Is any difference using set state-policy if-bound? > When what state policy to use? > > Thanks, Albertas > > >> PF makes 2 states per connection, so try this >> ($int_if is users LAN) >> >> pass in quick on $int_if from 10.0.0.1 to any tag user1 queue download1 >> pass in quick on $ext_if from any to 10.0.0.1 tag user1 queue upload1 >> pass out quick on $int_if tagged user1 queue download1 >> pass out quick on $ext_if tagged user1 queue upload1 >> .....and so on for another users >> >> >> news@topocentras.lt p??e v St 30. 07. 2008 v 09:43 +0300: >>> Hello once more, >>> It whould be very interesting to hear from you how to use keep state >>> for >>> router, shaping in and out traffic. >>> I am using around thousand of queues(hfsc) and it makes a lot of >>> performace problems. Using keep state it would reduce it, but as i >>> mention >>> before, i have problems using it. >>> >>> Sincerely Yours, >>> Albertas >>> >>> > ext_if="bge0" >>> > int_if="bge1" >>> > >>> > pass out quick on $ext_if from 10.0.0.1 to any queue upload1 >>> > pass out quick on $int_if from any to 10.0.0.1 queue download1 >>> > >>> > pass out quick on $ext_if from 10.0.0.2 to any queue upload2 >>> > pass out quick on $int_if from any to 10.0.0.2 queue download2 >>> > >>> > pass out quick on $ext_if from 10.0.0.3 to any queue upload3 >>> > pass out quick on $int_if from any to 10.0.0.3 queue download3 >>> > >>> > pass in all >>> > pass out all >>> > >>> > #10.0.0.x users subnet >>> > >>> > Hello, >>> > I have problems with keep state usage. I need to shape ingoing and >>> > outgoing trafic (no nat). >>> > Before I used sintax like above, but then I used it with keyword >>> "keep >>> > state" some useres reported problems with trafic. >>> > With version FreeBSD 7 with keep state on pass rules are not working >>> at >>> > all. >>> > Question is how to deal with keep state for in and out trafic then i >>> need >>> > to shape both? I tried to use set state-policy if-bound but it had no >>> > impact. >>> > >>> > _______________________________________________ >>> > 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" >>> > >>> >>> >>> _______________________________________________ >>> 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" >> >> > > > _______________________________________________ > 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 buchtajz at borsice.net Fri Aug 1 10:20:31 2008 From: buchtajz at borsice.net (Michal Buchtik) Date: Fri Aug 1 10:20:38 2008 Subject: need help with keep state and shaping In-Reply-To: <56637.88.119.128.115.1217585235.squirrel@mx.agservice.lt> References: <51307.88.119.128.115.1217227945.squirrel@mx.agservice.lt> <64686.88.119.128.115.1217400195.squirrel@mx.agservice.lt> <1217406136.31805.6.camel@buchtajz> <50928.88.119.128.115.1217406553.squirrel@mx.agservice.lt> <56637.88.119.128.115.1217585235.squirrel@mx.agservice.lt> Message-ID: <1217585923.9406.18.camel@buchtajz> as i write in last mail I use default state-policy (floating). As I can remember, if-bound policy works diferent. leave default (floating) there news@topocentras.lt p??e v P? 01. 08. 2008 v 13:07 +0300: > Hello once more, > What difference in state-policy floating and if-bound? > If i am using tagging for incoming and outgoing traffic? Which policy I > need to use? > > Thanks, > Albertas > > > Thanks for suggestion. Is any difference using set state-policy if-bound? > > When what state policy to use? > > > > Thanks, Albertas > > > > > >> PF makes 2 states per connection, so try this > >> ($int_if is users LAN) > >> > >> pass in quick on $int_if from 10.0.0.1 to any tag user1 queue download1 > >> pass in quick on $ext_if from any to 10.0.0.1 tag user1 queue upload1 > >> pass out quick on $int_if tagged user1 queue download1 > >> pass out quick on $ext_if tagged user1 queue upload1 > >> .....and so on for another users > >> > >> > >> news@topocentras.lt p??e v St 30. 07. 2008 v 09:43 +0300: > >>> Hello once more, > >>> It whould be very interesting to hear from you how to use keep state > >>> for > >>> router, shaping in and out traffic. > >>> I am using around thousand of queues(hfsc) and it makes a lot of > >>> performace problems. Using keep state it would reduce it, but as i > >>> mention > >>> before, i have problems using it. > >>> > >>> Sincerely Yours, > >>> Albertas > >>> > >>> > ext_if="bge0" > >>> > int_if="bge1" > >>> > > >>> > pass out quick on $ext_if from 10.0.0.1 to any queue upload1 > >>> > pass out quick on $int_if from any to 10.0.0.1 queue download1 > >>> > > >>> > pass out quick on $ext_if from 10.0.0.2 to any queue upload2 > >>> > pass out quick on $int_if from any to 10.0.0.2 queue download2 > >>> > > >>> > pass out quick on $ext_if from 10.0.0.3 to any queue upload3 > >>> > pass out quick on $int_if from any to 10.0.0.3 queue download3 > >>> > > >>> > pass in all > >>> > pass out all > >>> > > >>> > #10.0.0.x users subnet > >>> > > >>> > Hello, > >>> > I have problems with keep state usage. I need to shape ingoing and > >>> > outgoing trafic (no nat). > >>> > Before I used sintax like above, but then I used it with keyword > >>> "keep > >>> > state" some useres reported problems with trafic. > >>> > With version FreeBSD 7 with keep state on pass rules are not working > >>> at > >>> > all. > >>> > Question is how to deal with keep state for in and out trafic then i > >>> need > >>> > to shape both? I tried to use set state-policy if-bound but it had no > >>> > impact. > >>> > > >>> > _______________________________________________ > >>> > 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" > >>> > > >>> > >>> > >>> _______________________________________________ > >>> 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" > >> > >> > > > > > > _______________________________________________ > > 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" > > > > > _______________________________________________ > 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 fox at verio.net Fri Aug 1 17:31:14 2008 From: fox at verio.net (David DeSimone) Date: Fri Aug 1 17:31:25 2008 Subject: need help with keep state and shaping In-Reply-To: <56637.88.119.128.115.1217585235.squirrel@mx.agservice.lt> References: <51307.88.119.128.115.1217227945.squirrel@mx.agservice.lt> <64686.88.119.128.115.1217400195.squirrel@mx.agservice.lt> <1217406136.31805.6.camel@buchtajz> <50928.88.119.128.115.1217406553.squirrel@mx.agservice.lt> <56637.88.119.128.115.1217585235.squirrel@mx.agservice.lt> Message-ID: <20080801173107.GC13898@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 news@topocentras.lt wrote: > > What difference in state-policy floating and if-bound? "if-bound" means that the state becomes bound to the particular interfaces over which traffic was flowing at the start of the connection (when state is created). If your interfaces have hard assignments that don't change, and your routing table is static, this is the most secure choice. It means that traffic which suddenly starts coming in or going out a different interface than it used to, will no longer match the state, and therefore will be dropped. The "floating" state does not have this restriction, and traffic can come in or go out any interface and it will still be matched. > If i am using tagging for incoming and outgoing traffic? Which policy > I need to use? The policy you choose depends on how dynamic your interface and routing environment are. For instance, if you had multiple ISP's and use a routing protocol to choose dynamically between them, you would want the "floating" policy. Likewise, if you use PPP or other types of tunnels which go up and down, you will want "floating." Otherwise, choose "if-bound" for security reasons. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIk0hbFSrKRjX5eCoRAl8qAJ0Z23RD25cHiy6anw3A7NW7+88qewCfcRd7 H2Th1ZZAraXLgQ+G3G+r/T0= =+noD -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From bugmaster at FreeBSD.org Mon Aug 4 11:07:00 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 4 11:08:26 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200808041106.m74B6xIf082148@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o kern/121704 pf [pf] PF mangles loopback packets o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/125467 pf [pf] pf keep state bug while handling sessions between 10 problems total. From ismail at ismailozatay.net Mon Aug 4 20:51:08 2008 From: ismail at ismailozatay.net (Ismail OZATAY) Date: Tue Aug 5 02:00:33 2008 Subject: About policy routing Message-ID: <027A22408D9149A4B1A54CED20827F9F@pc> Hi there, Today i tried to make a policy routing with pf on freebsd 7 server for my second internet connection but couldn't do it. My default gw is dsl and want to use leased line for second connection. I do not know where is the problem ? Here is my pf.conf file ; > ll="sk0" > ll_gw="212.212.1.1" > ll_ip="212.212.1.2" > > dmz="sk1" > dmz_net="230.230.1.176/28" > dmz_ip="230.230.1.177" > > dsl="rl0" > dsl_gw="10.1.1.1" > dsl_ip="10.1.1.2" > > int="sk2" > int_net="10.10.10.0/24" > int_ip="10.10.10.1" > > set optimization aggressive > set skip on lo > > scrub in all > > nat on $dsl from $int_net to any -> $dsl_ip > > # Default block > ############### > block in log all > block out log all > > antispoof quick for { lo $int $ll $dsl $dmz } > pass out on $dsl inet proto tcp from $dsl to any keep state > pass out on $dsl inet proto udp from $dsl to any keep state > pass out on $ll inet proto tcp from $ll to any keep state > pass out on $ll inet proto udp from $ll to any keep state > > pass in on $int inet proto tcp from $int_net to any port { http, https } > flags S/SA keep state > pass in on $int inet proto udp from $int_net to any port domain keep state > > pass in log on $dmz route-to($ll $ll_gw) inet proto tcp from $dmz_net to > any port { http, https } flags S/SA keep state > pass in log on $dmz route-to($ll $ll_gw) inet proto udp from $dmz_net to > any port domain flags S/SA keep state Can you correct me ? Thanks ismail From swygue at rodhouse.org Tue Aug 5 14:14:35 2008 From: swygue at rodhouse.org (Rodrique Heron) Date: Tue Aug 5 14:14:42 2008 Subject: Understanding Load Balancing with DNS+PF+CARP Message-ID: <1a5f1a2d0808050648g4dcc4e02pe1904f1ffa8bb2cf@mail.gmail.com> I'm a running a Apache reverse proxy on PF+CARP, one node as master the other backup. I want a active/active setup, but since I don't have a hardware load balancer I'm banking on DNS. I would like to understand what happens when a host connects to the cluster for the first time after the first DNS query. So a user request www.website.com, DNS round-robin points the user to node1, what happens when a the user makes another request ? Is there another DNS lookup ? Will the user the sent back to node1 ? Does it make a difference if the server is hosting static content or an application ? Thanks From artemrts at ukr.net Wed Aug 6 09:28:12 2008 From: artemrts at ukr.net (Vitaliy Vladimirovich) Date: Wed Aug 6 09:28:23 2008 Subject: pf and torrent clients Message-ID: Hi, All. I have one question about pf. In my LAN some users use torrent clients. This torrent client create states with 86400s timeoutes. But when users shutdown own computers at the end of working day, entries remain before the expiration 86400s. Not 90s as at closing web or ftp sessions. I assume, that Torrent does not close connection. How to adjust pf, that it would delete "dead" entries ?created by torrent. ? Thanks! From dalibor.gudzic at gmail.com Wed Aug 6 15:55:56 2008 From: dalibor.gudzic at gmail.com (Dalibor Gudzic) Date: Wed Aug 6 15:56:02 2008 Subject: pf and torrent clients In-Reply-To: References: Message-ID: <866fa9520808060829g37445902hfe1cd96c67e40ee9@mail.gmail.com> 2008/8/6 Vitaliy Vladimirovich > Hi, All. > > I have one question about pf. > In my LAN some users use torrent clients. This torrent client > create states with 86400s timeoutes. But when users shutdown own computers > at the end of working day, > entries remain before the expiration 86400s. Not 90s as at closing web or > ftp sessions. > I assume, that Torrent does not close connection. How to adjust pf, that it > would delete "dead" entries > created by torrent. > > Thanks! You might wanna check the "set timeout" section in pf.conf(5) man page. You can check default timeout options with: pfctl -st Cheers P.S. Sorry, forgot to cc the list. From info at tecodryer.com Wed Aug 6 21:40:31 2008 From: info at tecodryer.com (TECO DRYER) Date: Wed Aug 6 21:40:37 2008 Subject: Teco Industry is in the business of corn, wheat, paddy, and Message-ID: <20080806214030.875508FC0A@mx1.freebsd.org> vegetable dr Sender: "TECO DRYER" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 7 Aug 2008 00:12:24 +0300 Message-ID: <20080806211224054.1DE32C1C329A14B1@erkan-e90bf8060> X-Priority: 3 (Normal) Importance: Normal Teco Industry is in the business of corn, wheat, paddy, and vegetable drying machines and the production and marketing of silo & steel construction. Related to the machines that our company produce; Teco Industry has the representatives in Bulgaria, Albania, Ukraine, Tatarstan, Kazakhstan, Russia, Angola and Indonesia. Our partners in these countries are accepted as the leaders in the steel industry. The quality of produced machines is approved by international standards. Teco is guaranteed by CE and ISO 9001-2000 certificates. Teco also contributes to the national economy by creating jobs in designing, project, production, import and export. Teco materializes R&D activities with its professional staff. Quality results are presented to the customers during the production, import and export. Our company takes the leadership of producing and marketing nationally and internationally. For Grain, Oily Seeds, and Pulses: Silos Corn and Soybean Drying Machines Handling Systems like Bucket Elevator, Chain Conveyor and Helix Prop Towers and Catwalks for Handling Systems Unloading Truck Lifts Industrial Foundations, Steel Construction With the expert staff; we take an important target like ‘’Customer Satisfaction and Service Quality’’ and perform service and counseling duties successfully. -------------------------------------------------------------------------------- Contact Us , Teco Dryer Company is ready for a long partnership with you. Sales Engineer Erkan AYMAN eayman@tecodryer.com From ask at develooper.com Thu Aug 7 08:41:45 2008 From: ask at develooper.com (=?ISO-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Thu Aug 7 08:41:52 2008 Subject: Understanding Load Balancing with DNS+PF+CARP In-Reply-To: <1a5f1a2d0808050648g4dcc4e02pe1904f1ffa8bb2cf@mail.gmail.com> References: <1a5f1a2d0808050648g4dcc4e02pe1904f1ffa8bb2cf@mail.gmail.com> Message-ID: <3E55632D-BD42-4299-BF63-976152B514DD@develooper.com> On Aug 5, 2008, at 6:48, Rodrique Heron wrote: > I'm a running a Apache reverse proxy on PF+CARP, one node as master > the > other backup. I want a active/active setup, but since I don't have a > hardware load balancer I'm banking on DNS. I would like to > understand what > happens when a host connects to the cluster for the first time after > the > first DNS query. > > So a user request www.website.com, DNS round-robin points the user > to node1, > what happens when a the user makes another request ? "It depends". The client is in control of that. Clients are different. The setup I usually recommend is to have CARP (or similar) move one IP around and then ahve nginx or perlbal running to load balance to the actual servers. - ask -- http://develooper.com/ - http://askask.com/ From tomh at huppi.com Thu Aug 7 10:45:07 2008 From: tomh at huppi.com (Tom Huppi) Date: Thu Aug 7 10:45:13 2008 Subject: syn flood, tcpdump readings Message-ID: <20080807101825.GC10818@huppi.com> I have been using 'pf' for about 8 months now, and it has been rock solid and a real pleasure to use. I built it into: FreeBSD 6.3-PRERELEASE (PEO2) #2: Mon Dec 10 19:45:05 PST 2007. I've not wished to re-start PF for 7 months since it is doing live traffic and I didn't do a pfsync implementation (won't make that mistake again and am working on such a solution now.) I am makeing high use of the load balancer and it is extreamly useful to us. My gateway host acts as a simple router with three physical interfaces, but I only filter on the interface connected to my provider (set skip on { lo0 em0 bce1 }). Anyway, I am getting what I believe to be syn floods periodically. They dwarf my production traffic and sometimes get close to producing as much bandwith as we are paying for. A representative sample looks like so when viewed with tcpdump on my outward interface ('em1'): 21:36:53.870312 IP 125.21.176.19.x11 > 74.123.192.195.domain: S 27394048:27394048(0) win 16384 21:36:53.870319 IP 125.21.176.19.x11 > 74.123.192.204.domain: S 1793916928:1793916928(0) win 16384 21:36:53.870325 IP 125.21.176.19.x11 > 74.123.192.190.domain: S 1669070848:1669070848(0) win 16384 21:36:53.870369 IP 125.21.176.19.x11 > 74.123.192.185.domain: S 601948160:601948160(0) win 16384 21:36:53.870371 IP 125.21.176.19.x11 > 74.123.192.166.domain: S 1129906176:1129906176(0) win 16384 21:36:53.870373 IP 125.21.176.19.x11 > 74.123.192.179.domain: S 1231945728:1231945728(0) win 16384 21:36:53.870375 IP 125.21.176.19.x11 > 74.123.192.171.domain: S 1524105216:1524105216(0) win 16384 21:36:53.870377 IP 125.21.176.19.x11 > 74.123.192.26.domain: S 1212678144:1212678144(0) win 16384 21:36:53.870381 IP 125.21.176.19.x11 > 74.123.192.195.domain: S 27394048:27394048(0) win 16384 21:36:53.870383 IP 125.21.176.19.x11 > 74.123.192.204.domain: S 1793916928:1793916928(0) win 16384 21:36:53.870385 IP 125.21.176.19.x11 > 74.123.192.190.domain: S 1669070848:1669070848(0) win 16384 21:36:53.870396 IP 125.21.176.19.x11 > 74.123.192.185.domain: S 601948160:601948160(0) win 16384 21:36:53.870403 IP 125.21.176.19.x11 > 74.123.192.166.domain: S 1129906176:1129906176(0) win 16384 21:36:53.870409 IP 125.21.176.19.x11 > 74.123.192.179.domain: S 1231945728:1231945728(0) win 16384 21:36:53.870416 IP 125.21.176.19.x11 > 74.123.192.171.domain: S 1524105216:1524105216(0) win 16384 21:36:53.870422 IP 125.21.176.19.x11 > 74.123.192.26.domain: S 1212678144:1212678144(0) win 16384 I run 'pfstat' and here is a representative chart showing bandwidth. The chart of packets almost completely obscures real traffic since the syn packets are small: http://www.huppi.com/t/tmp/pfstat_2days.png My confusion is that my charts show outgoing traffic matching incomming traffic, but I see no outgoing with tcpdump. My uplink is Gig ethernet rate-limited by my network provider. I think perhaps the outgoing traffic is something other than TCP, but I wanted to ask on this list since I couldn't spot an answer in surfing around and network stuff is really not my area of expertise. My fear is that I actually am responding in some manner to these packets and either inviting more of these attacks, or worse, allowing my service to attack other people (say if the incomming IP was spoofed to an attack target.) --- A slightly less important question is whether attacks like this are 'par for the course' and expected, and how bad they can get. I do fear that at an inopertune time I will recieve an attack which consumes all of my bandwith and causes performance issues for my real traffic. (I'm developing more faith in PF's ability to handle things...so far I see no degradation whatsoever durring these attacks.) My typical rules look like so: pass proto tcp from any to port $tase_int_ports flags S/SA synproxy state and I really only notice attacks after I started using 'synproxy'. Whether I had them prior and just didn't notice, I am not sure. I've not used any of the 'max-*' stuff because I don't fully understand the problem and issues, and I am using a somewhat dated codebase. --- Thanks for any thoughts, hints, pointers, etc. - Tom -- From freebsd at optiksecurite.com Thu Aug 7 16:02:39 2008 From: freebsd at optiksecurite.com (FreeBSD) Date: Thu Aug 7 16:02:46 2008 Subject: syn flood, tcpdump readings In-Reply-To: <20080807101825.GC10818@huppi.com> References: <20080807101825.GC10818@huppi.com> Message-ID: <489B1049.9000002@optiksecurite.com> Tom Huppi a ?crit : > I have been using 'pf' for about 8 months now, and it has been > rock solid and a real pleasure to use. I built it into: FreeBSD > 6.3-PRERELEASE (PEO2) #2: Mon Dec 10 19:45:05 PST 2007. I've > not wished to re-start PF for 7 months since it is doing live > traffic and I didn't do a pfsync implementation (won't make that > mistake again and am working on such a solution now.) > > I am makeing high use of the load balancer and it is extreamly > useful to us. > > My gateway host acts as a simple router with three physical > interfaces, but I only filter on the interface connected to my > provider (set skip on { lo0 em0 bce1 }). > > Anyway, I am getting what I believe to be syn floods > periodically. They dwarf my production traffic and sometimes > get close to producing as much bandwith as we are paying for. A > representative sample looks like so when viewed with tcpdump on > my outward interface ('em1'): > > 21:36:53.870312 IP 125.21.176.19.x11 > 74.123.192.195.domain: S 27394048:27394048(0) win 16384 > 21:36:53.870319 IP 125.21.176.19.x11 > 74.123.192.204.domain: S 1793916928:1793916928(0) win 16384 > 21:36:53.870325 IP 125.21.176.19.x11 > 74.123.192.190.domain: S 1669070848:1669070848(0) win 16384 > 21:36:53.870369 IP 125.21.176.19.x11 > 74.123.192.185.domain: S 601948160:601948160(0) win 16384 > 21:36:53.870371 IP 125.21.176.19.x11 > 74.123.192.166.domain: S 1129906176:1129906176(0) win 16384 > 21:36:53.870373 IP 125.21.176.19.x11 > 74.123.192.179.domain: S 1231945728:1231945728(0) win 16384 > 21:36:53.870375 IP 125.21.176.19.x11 > 74.123.192.171.domain: S 1524105216:1524105216(0) win 16384 > 21:36:53.870377 IP 125.21.176.19.x11 > 74.123.192.26.domain: S 1212678144:1212678144(0) win 16384 > 21:36:53.870381 IP 125.21.176.19.x11 > 74.123.192.195.domain: S 27394048:27394048(0) win 16384 > 21:36:53.870383 IP 125.21.176.19.x11 > 74.123.192.204.domain: S 1793916928:1793916928(0) win 16384 > 21:36:53.870385 IP 125.21.176.19.x11 > 74.123.192.190.domain: S 1669070848:1669070848(0) win 16384 > 21:36:53.870396 IP 125.21.176.19.x11 > 74.123.192.185.domain: S 601948160:601948160(0) win 16384 > 21:36:53.870403 IP 125.21.176.19.x11 > 74.123.192.166.domain: S 1129906176:1129906176(0) win 16384 > 21:36:53.870409 IP 125.21.176.19.x11 > 74.123.192.179.domain: S 1231945728:1231945728(0) win 16384 > 21:36:53.870416 IP 125.21.176.19.x11 > 74.123.192.171.domain: S 1524105216:1524105216(0) win 16384 > 21:36:53.870422 IP 125.21.176.19.x11 > 74.123.192.26.domain: S 1212678144:1212678144(0) win 16384 > > > I run 'pfstat' and here is a representative chart showing > bandwidth. The chart of packets almost completely obscures real > traffic since the syn packets are small: > > http://www.huppi.com/t/tmp/pfstat_2days.png > > > My confusion is that my charts show outgoing traffic matching > incomming traffic, but I see no outgoing with tcpdump. My > uplink is Gig ethernet rate-limited by my network provider. I > think perhaps the outgoing traffic is something other than TCP, > but I wanted to ask on this list since I couldn't spot an answer > in surfing around and network stuff is really not my area of > expertise. > > My fear is that I actually am responding in some manner to these > packets and either inviting more of these attacks, or worse, > allowing my service to attack other people (say if the incomming > IP was spoofed to an attack target.) > > --- > > A slightly less important question is whether attacks like this > are 'par for the course' and expected, and how bad they can > get. I do fear that at an inopertune time I will recieve an > attack which consumes all of my bandwith and causes performance > issues for my real traffic. (I'm developing more faith in > PF's ability to handle things...so far I see no degradation > whatsoever durring these attacks.) > > > My typical rules look like so: > > pass proto tcp from any to port $tase_int_ports flags S/SA synproxy state > > and I really only notice attacks after I started using > 'synproxy'. Whether I had them prior and just didn't notice, I > am not sure. I've not used any of the 'max-*' stuff because I > don't fully understand the problem and issues, and I am using a > somewhat dated codebase. > > --- > > Thanks for any thoughts, hints, pointers, etc. > > - Tom > Hi, I think that you should look at the 'scrub' directive in pf.conf. I think that a 'scrub in all' should block that kind of malformed packets. Martin From nejc at skoberne.net Thu Aug 7 16:13:59 2008 From: nejc at skoberne.net (=?ISO-8859-2?Q?Nejc_=A9koberne?=) Date: Thu Aug 7 16:14:06 2008 Subject: pf and jails Message-ID: <489B1D86.3070306@skoberne.net> Hello, I have a server with multiple jails of different types (service jails, user jails, ...). In my rc.conf I have (the relevant parts): # Host ifconfig_bge0="a.b.c.242 netmask 255.255.255.240" # Host ifconfig_bge0_alias0="a.b.c.243 netmask 255.255.255.255" # Common defaultrouter="a.b.c.241" # Jails cloned_interfaces="lo1 lo2" ifconfig_lo1="10.1.1.1 netmask 255.255.255.0" ifconfig_lo2="10.1.2.1 netmask 255.255.255.0" jail_first_ip="a.b.c.244" jail_first_interface="bge0 netmask 255.255.255.240" jail_second_ip="10.1.1.13" jail_second_interface="lo1 netmask 255.255.255.0" jail_third_ip="10.1.2.10" jail_third_interface="lo2 netmask 255.255.255.0" Now I would like to do firewalling between these jails. So that users of the second and the third jail can't ssh to first jail, for example. I thought this could be done by simply doing: - block log all - pass on lo0 all - [define other pass rules like: pass out on lo1 from ... to ...) But then I realized that all the traffic which travels between jails themselves and between jails and the host, is only "visible" on lo0 interface. So I guess this done by design. So my only option would be blocking all on lo0 and then doing pass rules only on lo0? I guess this is harder, because I need to observe carefully what needs to be passed on lo0 in order not to break anything? How do you do it? Thanks, Nejc From tomh at huppi.com Thu Aug 7 17:11:52 2008 From: tomh at huppi.com (Tom Huppi) Date: Thu Aug 7 17:11:58 2008 Subject: syn flood, tcpdump readings In-Reply-To: <489B1049.9000002@optiksecurite.com> References: <20080807101825.GC10818@huppi.com> <489B1049.9000002@optiksecurite.com> Message-ID: <20080807171150.GD10818@huppi.com> On 11:10 Thu 07 Aug , FreeBSD wrote: > Tom Huppi a ?crit : > >I have been using 'pf' for about 8 months now, and it has been > >rock solid and a real pleasure to use. I built it into: FreeBSD > >6.3-PRERELEASE (PEO2) #2: Mon Dec 10 19:45:05 PST 2007. I've > >not wished to re-start PF for 7 months since it is doing live > >traffic and I didn't do a pfsync implementation (won't make that > >mistake again and am working on such a solution now.) > > > >I am makeing high use of the load balancer and it is extreamly > >useful to us. > > > >My gateway host acts as a simple router with three physical > >interfaces, but I only filter on the interface connected to my > >provider (set skip on { lo0 em0 bce1 }). > > > >Anyway, I am getting what I believe to be syn floods > >periodically. They dwarf my production traffic and sometimes > >get close to producing as much bandwith as we are paying for. A > >representative sample looks like so when viewed with tcpdump on > >my outward interface ('em1'): > > > >21:36:53.870312 IP 125.21.176.19.x11 > 74.123.192.195.domain: S > >27394048:27394048(0) win 16384 > >21:36:53.870319 IP 125.21.176.19.x11 > 74.123.192.204.domain: S > >1793916928:1793916928(0) win 16384 > >21:36:53.870325 IP 125.21.176.19.x11 > 74.123.192.190.domain: S > >1669070848:1669070848(0) win 16384 > >21:36:53.870369 IP 125.21.176.19.x11 > 74.123.192.185.domain: S > >601948160:601948160(0) win 16384 > >21:36:53.870371 IP 125.21.176.19.x11 > 74.123.192.166.domain: S > >1129906176:1129906176(0) win 16384 > >21:36:53.870373 IP 125.21.176.19.x11 > 74.123.192.179.domain: S > >1231945728:1231945728(0) win 16384 > >21:36:53.870375 IP 125.21.176.19.x11 > 74.123.192.171.domain: S > >1524105216:1524105216(0) win 16384 > >21:36:53.870377 IP 125.21.176.19.x11 > 74.123.192.26.domain: S > >1212678144:1212678144(0) win 16384 > >21:36:53.870381 IP 125.21.176.19.x11 > 74.123.192.195.domain: S > >27394048:27394048(0) win 16384 > >21:36:53.870383 IP 125.21.176.19.x11 > 74.123.192.204.domain: S > >1793916928:1793916928(0) win 16384 > >21:36:53.870385 IP 125.21.176.19.x11 > 74.123.192.190.domain: S > >1669070848:1669070848(0) win 16384 > >21:36:53.870396 IP 125.21.176.19.x11 > 74.123.192.185.domain: S > >601948160:601948160(0) win 16384 > >21:36:53.870403 IP 125.21.176.19.x11 > 74.123.192.166.domain: S > >1129906176:1129906176(0) win 16384 > >21:36:53.870409 IP 125.21.176.19.x11 > 74.123.192.179.domain: S > >1231945728:1231945728(0) win 16384 > >21:36:53.870416 IP 125.21.176.19.x11 > 74.123.192.171.domain: S > >1524105216:1524105216(0) win 16384 > >21:36:53.870422 IP 125.21.176.19.x11 > 74.123.192.26.domain: S > >1212678144:1212678144(0) win 16384 > > > > > >I run 'pfstat' and here is a representative chart showing > >bandwidth. The chart of packets almost completely obscures real > >traffic since the syn packets are small: > > > >http://www.huppi.com/t/tmp/pfstat_2days.png > > > > > >My confusion is that my charts show outgoing traffic matching > >incomming traffic, but I see no outgoing with tcpdump. My > >uplink is Gig ethernet rate-limited by my network provider. I > >think perhaps the outgoing traffic is something other than TCP, > >but I wanted to ask on this list since I couldn't spot an answer > >in surfing around and network stuff is really not my area of > >expertise. > > > >My fear is that I actually am responding in some manner to these > >packets and either inviting more of these attacks, or worse, > >allowing my service to attack other people (say if the incomming > >IP was spoofed to an attack target.) > > > >--- > > > >A slightly less important question is whether attacks like this > >are 'par for the course' and expected, and how bad they can > >get. I do fear that at an inopertune time I will recieve an > >attack which consumes all of my bandwith and causes performance > >issues for my real traffic. (I'm developing more faith in > >PF's ability to handle things...so far I see no degradation > >whatsoever durring these attacks.) > > > > > >My typical rules look like so: > > > >pass proto tcp from any to port $tase_int_ports flags > >S/SA synproxy state > > > >and I really only notice attacks after I started using > >'synproxy'. Whether I had them prior and just didn't notice, I > >am not sure. I've not used any of the 'max-*' stuff because I > >don't fully understand the problem and issues, and I am using a > >somewhat dated codebase. > > > >--- > > > >Thanks for any thoughts, hints, pointers, etc. > > > > - Tom > > > Hi, > > I think that you should look at the 'scrub' directive in pf.conf. I > think that a 'scrub in all' should block that kind of malformed packets. I have used 'scrub' in one form or another from the start. My current one looks like so: scrub on $ext_if all reassemble tcp #scrub in on $ext_if #scrub in all Actally, I think that PF is doing a fine job of 'blocking' the packets, but I of course have limited control over the packets getting to my gateway in the first place. I was probably not clear on my question. To re-phrase: 1) Am I really sending out as much bandwidth as I am recieving when these trillions of packets arrive? 2) If so, why can I not see the traffic with tcpdump? Thanks for any insights, - Tom From fox at verio.net Thu Aug 7 17:32:33 2008 From: fox at verio.net (David DeSimone) Date: Thu Aug 7 17:32:39 2008 Subject: syn flood, tcpdump readings In-Reply-To: <20080807101825.GC10818@huppi.com> References: <20080807101825.GC10818@huppi.com> Message-ID: <20080807173225.GA17926@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Huppi wrote: > > Anyway, I am getting what I believe to be syn floods > periodically. They dwarf my production traffic and sometimes > get close to producing as much bandwith as we are paying for. A > representative sample looks like so when viewed with tcpdump on > my outward interface ('em1'): > > 21:36:53.870312 IP 125.21.176.19.x11 > 74.123.192.195.domain: S 27394048:27394048(0) win 16384 > 21:36:53.870319 IP 125.21.176.19.x11 > 74.123.192.204.domain: S 1793916928:1793916928(0) win 16384 Since you went to the trouble of obscuring the source IP, I presume that the source IP is your IP. So, these look like responses, i.e. outbound traffic, not inbound, since they are sourced from your IP. You can use tcpdump's -e flag to be sure who is sending and who is receiving. - -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFImzGpFSrKRjX5eCoRAmQWAJ42P3j3LgD9gE5aqIs+A9ytFAzUgACeLU1g 0F9BDmubpLI37Bz/OKW420Y= =Nm7c -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From tomh at huppi.com Thu Aug 7 18:00:56 2008 From: tomh at huppi.com (Tom Huppi) Date: Thu Aug 7 18:01:03 2008 Subject: syn flood, tcpdump readings In-Reply-To: <20080807173225.GA17926@verio.net> References: <20080807101825.GC10818@huppi.com> <20080807173225.GA17926@verio.net> Message-ID: <20080807180054.GE10818@huppi.com> On 12:32 Thu 07 Aug , David DeSimone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tom Huppi wrote: > > > > Anyway, I am getting what I believe to be syn floods > > periodically. They dwarf my production traffic and sometimes > > get close to producing as much bandwith as we are paying for. A > > representative sample looks like so when viewed with tcpdump on > > my outward interface ('em1'): > > > > 21:36:53.870312 IP 125.21.176.19.x11 > 74.123.192.195.domain: S 27394048:27394048(0) win 16384 > > 21:36:53.870319 IP 125.21.176.19.x11 > 74.123.192.204.domain: S 1793916928:1793916928(0) win 16384 > > Since you went to the trouble of obscuring the source IP, I presume that > the source IP is your IP. So, these look like responses, i.e. outbound > traffic, not inbound, since they are sourced from your IP. You can use > tcpdump's -e flag to be sure who is sending and who is receiving. I obscured my own IP range which is the 74.nnn.nnn. one and it is a /24. Interestingly most of the IP's on my side are ones where I have no host. The reason why is that I figured that if I myself were a semi-sophisticated cracker, I would look for targets of opertunity on the various mailing lists where one could identify both networks administered by newbie/part-time personel, and often a fair amount about the configuration of said :) The IP '125.21.176.19' is exactly as it appeared on my tcpdump. It shows as a telcom company in India in this case...usually it's some network company or another in China. My network looks like so: ------------- em0 <---> internal range Network Provider <----> em1 | pf firewall | (Internap) ------------- bce1 <---> dmz range I took the tcpdump output to indicate that Syn packets showing an Indian Origin were showing up addressed to (mainly non-existant) IP addresses within my /24 network. I'll look at 'tcpdump -e'. Thanks for the hint! - Tom > > - -- > David DeSimone == Network Admin == fox@verio.net > "I don't like spinach, and I'm glad I don't, because if I > liked it I'd eat it, and I just hate it." -- Clarence Darrow > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFImzGpFSrKRjX5eCoRAmQWAJ42P3j3LgD9gE5aqIs+A9ytFAzUgACeLU1g > 0F9BDmubpLI37Bz/OKW420Y= > =Nm7c > -----END PGP SIGNATURE----- > > > This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. > _______________________________________________ > 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 bugmaster at FreeBSD.org Mon Aug 11 11:07:02 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 11 11:08:25 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200808111107.m7BB71jn047275@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o kern/121704 pf [pf] PF mangles loopback packets o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/125467 pf [pf] pf keep state bug while handling sessions between 10 problems total. From reddvinylene at gmail.com Mon Aug 11 13:24:05 2008 From: reddvinylene at gmail.com (Redd Vinylene) Date: Mon Aug 11 13:24:10 2008 Subject: Why the old version of pf? Message-ID: Hello hello! Just curious why FreeBSD 7 has to use an old version of pf? There's been so many improvements! I'd very much like to use the new IP range feature for instance, so I can reduce box = "{ 80.252.2.4, 80.252.2.5, 80.252.2.6, 80.252.2.7, 80.252.2.8, 80.252.2.9, 80.252.2.10, 80.252.2.11, 80.252.2.12, 80.252.2.13, 80.252.2.14, 80.252.2.15, 80.252.2.16, 80.252.2.17, 80.252.2.18, 80.252.2.19, 80.252.2.20, 80.252.2.21, 80.252.2.22, 80.252.2.23, 80.252.2.24, 80.252.2.25, 80.252.2.26, 80.252.2.27, 80.252.2.28, 80.252.2.29, 80.252.2.30, 80.252.2.31, 80.252.2.32, 80.252.2.33, 80.252.2.34, 80.252.2.35, 80.252.2.36, 80.252.2.37, 80.252.2.38, 80.252.2.39, 80.252.2.40, 80.252.2.41, 80.252.2.42, 80.252.2.43, 80.252.2.44, 80.252.2.45, 80.252.2.46, 80.252.2.47, 80.252.2.48, 80.252.2.49, 80.252.2.50, 80.252.2.51, 80.252.2.52, 80.252.2.53, 80.252.2.54, 80.252.2.55, 80.252.2.56, 80.252.2.57, 80.252.2.58, 80.252.2.59, 80.252.2.60, 80.252.2.61, 80.252.2.62, 80.252.2.63, 80.252.2.64, 80.252.2.65, 80.252.2.80, 80.252.2.67, 80.252.2.68, 80.252.2.69, 80.252.2.70, 80.252.2.71, 80.252.2.72, 80.252.2.73, 80.252.2.74, 80.252.2.75, 80.252.2.76, 80.252.2.77, 80.252.2.78, 80.252.2.79, 80.252.2.80, 80.252.2.81, 80.252.2.82, 80.252.2.83, 80.252.2.84, 80.252.2.85, 80.252.2.86, 80.252.2.87, 80.252.2.88, 80.252.2.89, 80.252.2.90, 80.252.2.91, 80.252.2.92, 80.252.2.93, 80.252.2.94, 80.252.2.95, 80.252.2.96, 80.252.2.97, 80.252.2.98, 80.252.2.99, 80.252.2.100, 80.252.2.101, 80.252.2.102, 80.252.2.103, 80.252.2.104, 80.252.2.105, 80.252.2.106, 80.252.2.107, 80.252.2.108, 80.252.2.109, 80.252.2.110, 80.252.2.111, 80.252.2.112, 80.252.2.113, 80.252.2.114, 80.252.2.115, 80.252.2.116, 80.252.2.117, 80.252.2.118, 80.252.2.119, 80.252.2.120, 80.252.2.121, 80.252.2.122, 80.252.2.123, 80.252.2.124, 80.252.2.125, 80.252.2.126, 80.252.2.127 }" to box = "{ 80.252.2.4 - 80.252.2.127 }" Much obliged, and thanks! -- http://www.home.no/reddvinylene From nejc at skoberne.net Mon Aug 11 13:53:46 2008 From: nejc at skoberne.net (=?ISO-8859-1?Q?Nejc_S=28koberne?=) Date: Mon Aug 11 13:53:52 2008 Subject: Why the old version of pf? In-Reply-To: References: Message-ID: <48A0422F.1050403@skoberne.net> Hey, > Just curious why FreeBSD 7 has to use an old version of pf? There's > been so many improvements! I'd very much like to use the new IP range > feature for instance, so I can reduce Can't help you here. > box = "{ 80.252.2.4 - 80.252.2.127 }" But if I am not wrong, you could write this (at least) as: box = "{ 80.252.2.64/26, 80.252.2.32/27, 80.252.2.16/28, \ 80.252.2.8/29, 80.252.2.4/30 }" Bye, Nejc From reddvinylene at gmail.com Mon Aug 11 14:24:46 2008 From: reddvinylene at gmail.com (Redd Vinylene) Date: Mon Aug 11 14:24:52 2008 Subject: Why the old version of pf? In-Reply-To: References: <48A0422F.1050403@skoberne.net> <11167f520808110713p69d165bdsb29224f8eb1279a4@mail.gmail.com> Message-ID: 4.1 according to the handbook, no? > On Mon, Aug 11, 2008 at 4:13 PM, Sam Fourman Jr. wrote: >>>> Just curious why FreeBSD 7 has to use an old version of pf? There's >>>> been so many improvements! I'd very much like to use the new IP range >>>> feature for instance, so I can reduce >> >> does anyone know how to find our what version of pf FreeBSD is currently using? >> a switch maybe? >> >> Sam Fourman Jr. >> > > > > -- > http://www.home.no/reddvinylene > -- http://www.home.no/reddvinylene From sfourman at gmail.com Mon Aug 11 14:39:06 2008 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Mon Aug 11 14:39:12 2008 Subject: Why the old version of pf? In-Reply-To: <48A0422F.1050403@skoberne.net> References: <48A0422F.1050403@skoberne.net> Message-ID: <11167f520808110713p69d165bdsb29224f8eb1279a4@mail.gmail.com> >> Just curious why FreeBSD 7 has to use an old version of pf? There's >> been so many improvements! I'd very much like to use the new IP range >> feature for instance, so I can reduce does anyone know how to find our what version of pf FreeBSD is currently using? a switch maybe? Sam Fourman Jr. From max at love2party.net Mon Aug 11 15:05:34 2008 From: max at love2party.net (Max Laier) Date: Mon Aug 11 15:05:41 2008 Subject: Why the old version of pf? In-Reply-To: <11167f520808110713p69d165bdsb29224f8eb1279a4@mail.gmail.com> References: <48A0422F.1050403@skoberne.net> <11167f520808110713p69d165bdsb29224f8eb1279a4@mail.gmail.com> Message-ID: <200808111705.22825.max@love2party.net> On Monday 11 August 2008 16:13:15 Sam Fourman Jr. wrote: > >> Just curious why FreeBSD 7 has to use an old version of pf? There's > >> been so many improvements! I'd very much like to use the new IP range > >> feature for instance, so I can reduce > > does anyone know how to find our what version of pf FreeBSD is currently > using? a switch maybe? Unfortunately, there is no simple mechanism to figure that out. There is documentation of __FreeBSD_version (aka sysctl kern.osreldate) mapping to pf version in the porter's handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/freebsd- versions.html You can also check sysutils/pftop/Makefile for hints. -- /"\ 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 max at love2party.net Mon Aug 11 15:18:54 2008 From: max at love2party.net (Max Laier) Date: Mon Aug 11 15:19:00 2008 Subject: Why the old version of pf? In-Reply-To: References: Message-ID: <200808111718.51616.max@love2party.net> On Monday 11 August 2008 14:59:46 Redd Vinylene wrote: > Just curious why FreeBSD 7 has to use an old version of pf? There's > been so many improvements! It's a mixed bag, I'd say. I'm pondering an update to 4.3, but haven't found the time yet. And now 4.4 is in sight already and has a lot more stuff ... though there seem to be some problems with some of the new stuff ... Right now, the simple answer is just: It hasn't been done. > I'd very much like to use the new IP range > feature for instance, so I can reduce > > box = "{ 80.252.2.4, 80.252.2.5, 80.252.2.6, 80.252.2.7, 80.252.2.8, > ... > 80.252.2.124, 80.252.2.125, 80.252.2.126, 80.252.2.127 }" > > to > > box = "{ 80.252.2.4 - 80.252.2.127 }" Now, if that's your only problem I suggest that you read about netmasks and write the above as either table { 80.252.2.0/25, !80.252.2.3/30 } or box = "{ 80.252.2.64/26, 80.252.2.32/27, 80.252.2.16/28, \ 80.252.2.8/29, 80.252.2.4/30 }" as Nejc suggested. -- /"\ 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 stefan.lambrev at moneybookers.com Mon Aug 11 15:21:20 2008 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Mon Aug 11 15:21:26 2008 Subject: syn flood, tcpdump readings In-Reply-To: <20080807180054.GE10818@huppi.com> References: <20080807101825.GC10818@huppi.com> <20080807173225.GA17926@verio.net> <20080807180054.GE10818@huppi.com> Message-ID: <48A058EB.3010308@moneybookers.com> Tom Huppi wrote: > On 12:32 Thu 07 Aug , David DeSimone wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Tom Huppi wrote: >> >>> Anyway, I am getting what I believe to be syn floods >>> periodically. They dwarf my production traffic and sometimes >>> get close to producing as much bandwith as we are paying for. A >>> representative sample looks like so when viewed with tcpdump on >>> my outward interface ('em1'): >>> >>> 21:36:53.870312 IP 125.21.176.19.x11 > 74.123.192.195.domain: S 27394048:27394048(0) win 16384 >>> 21:36:53.870319 IP 125.21.176.19.x11 > 74.123.192.204.domain: S 1793916928:1793916928(0) win 16384 >>> >> Since you went to the trouble of obscuring the source IP, I presume that >> the source IP is your IP. So, these look like responses, i.e. outbound >> traffic, not inbound, since they are sourced from your IP. You can use >> tcpdump's -e flag to be sure who is sending and who is receiving. >> > > > I obscured my own IP range which is the 74.nnn.nnn. one and it > is a /24. Interestingly most of the IP's on my side are ones > where I have no host. > > The reason why is that I figured that if I myself were a > semi-sophisticated cracker, I would look for targets of > opertunity on the various mailing lists where one could identify > both networks administered by newbie/part-time personel, and > often a fair amount about the configuration of said :) > > The IP '125.21.176.19' is exactly as it appeared on my tcpdump. > It shows as a telcom company in India in this case...usually > it's some network company or another in China. > > My network looks like so: > > ------------- em0 <---> internal range > Network Provider <----> em1 | pf firewall | > (Internap) ------------- bce1 <---> dmz range > > > I took the tcpdump output to indicate that Syn packets showing an Indian Origin were showing up addressed to (mainly non-existant) IP addresses within my /24 network. > > I'll look at 'tcpdump -e'. Thanks for the hint! > If the syn flood comes from single IP you can just block traffic from it. For every SYN packet you are sending SYN-ACK packet so yes the traffic is in both ways. Why you do not see it on tcpdump I duno. In all cases you want to limit the max number of states that can be created by a single source IP and you want to limit the rate of new connections over a time interval. - max-src-states - max-src-conn-rate Anyway if the incoming traffic "floods" your pipe this will not help, but at least your firewall will work properly ;) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From sfourman at gmail.com Mon Aug 11 15:23:35 2008 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Mon Aug 11 15:23:42 2008 Subject: Why the old version of pf? In-Reply-To: <200808111718.51616.max@love2party.net> References: <200808111718.51616.max@love2party.net> Message-ID: <11167f520808110823l6630b12ck10c6a36d630342@mail.gmail.com> > And now 4.4 is in sight already and has a lot more stuff ... > though there seem to be some problems with some of the new stuff ... What stuff is causing trouble, I could cherry pick a few patches and test. Sam Fourman Jr. From biancalana at gmail.com Fri Aug 15 14:33:55 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Fri Aug 15 14:34:01 2008 Subject: why BAD state messages Message-ID: <8e10486b0808150708j304524e4nade3c215187092a7@mail.gmail.com> Hi list, I'm experiencing some problems with blocked connections because of bad states but I need some more information about why this is happening, if this is timeout between tcp handshake, or state creation or application trying to talk on closed connection. I have two FreeBSD 7-STABLE with PF, carp, pfsync and max carpdev patch and two application servers (jboss) that listen on port 9090 behind this firewalls, some connections from external clients off this appservers are (apparently random) being blocked, enabling loud (pfctl -x loud) I can see in /var/log/messages the following messages: kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 10.10.110.34:52347 [lo=3922530250 high=3922595445 win=65535 modulator=0] [lo=3059100500 high=3059158735 win=65195 modulator=0] 4:4 S seq=398900533 (398900533) ack=3059100500 len=0 ackskew=0 pkts=6:20 dir=in,fwd kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 10.10.110.34:50668 [lo=395881033 high=395946233 win=65535 modulator=0] [lo=3568232053 high=3568290288 win=65200 modulator=0] 4:4 S seq=2480335288 (2480335288) ack=3568232053 len=0 ackskew=0 pkts=6:20 dir=in,fwd kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 10.10.110.34:51582 [lo=3528357041 high=3528421509 win=65535 modulator=0] [lo=3809540772 high=3809605893 win=64468 modulator=0] 9:9 S seq=3810516558 (3810516558) ack=3809540772 len=0 ackskew=0 pkts=6:5 dir=in,fwd kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 10.10.110.34:50668 [lo=395881033 high=395946233 win=65535 modulator=0] [lo=3568232053 high=3568290288 win=65200 modulator=0] 4:4 S seq=2480335288 (2480335288) ack=3568232053 len=0 ackskew=0 pkts=6:20 dir=in,fwd kernel: pf: BAD state: TCP 10.10.6.18:9090 10.10.6.18:9090 10.10.81.242:2434 [lo=538716318 high=538780855 win=65535 modulator=0] [lo=1004209856 high=1004274961 win=64537 modulator=0] 4:9 S seq=1634723484 (1634723484) ack=1004209856 len=0 ackskew=0 pkts=5:4 dir=in,fwd I tried to set custom tcp timeout options in this rules but this does not help pass log proto tcp from any to { $apphpr01 $apphpr02 } port { 9090 } keep state (tcp.opening 60, tcp.closed 180, tcp.finwait 90) Any ideas on how can I know why this connections are being blocked ?? I can provide any additional information needed. Regards, Alexandre From biancalana at gmail.com Fri Aug 15 14:37:01 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Fri Aug 15 14:37:11 2008 Subject: why BAD state messages Message-ID: <8e10486b0808150708g200727b8sc2f4993eee9f5248@mail.gmail.com> Hi list, I'm experiencing some problems with blocked connections because of bad states but I need some more information about why this is happening, if this is timeout between tcp handshake, or state creation or application trying to talk on closed connection. I have two FreeBSD 7-STABLE with PF, carp, pfsync and max carpdev patch and two application servers (jboss) that listen on port 9090 behind this firewalls, some connections from external clients off this appservers are (apparently random) being blocked, enabling loud (pfctl -x loud) I can see in /var/log/messages the following messages: kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 10.10.110.34:52347 [lo=3922530250 high=3922595445 win=65535 modulator=0] [lo=3059100500 high=3059158735 win=65195 modulator=0] 4:4 S seq=398900533 (398900533) ack=3059100500 len=0 ackskew=0 pkts=6:20 dir=in,fwd kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 10.10.110.34:50668 [lo=395881033 high=395946233 win=65535 modulator=0] [lo=3568232053 high=3568290288 win=65200 modulator=0] 4:4 S seq=2480335288 (2480335288) ack=3568232053 len=0 ackskew=0 pkts=6:20 dir=in,fwd kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 10.10.110.34:51582 [lo=3528357041 high=3528421509 win=65535 modulator=0] [lo=3809540772 high=3809605893 win=64468 modulator=0] 9:9 S seq=3810516558 (3810516558) ack=3809540772 len=0 ackskew=0 pkts=6:5 dir=in,fwd kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 10.10.110.34:50668 [lo=395881033 high=395946233 win=65535 modulator=0] [lo=3568232053 high=3568290288 win=65200 modulator=0] 4:4 S seq=2480335288 (2480335288) ack=3568232053 len=0 ackskew=0 pkts=6:20 dir=in,fwd kernel: pf: BAD state: TCP 10.10.6.18:9090 10.10.6.18:9090 10.10.81.242:2434 [lo=538716318 high=538780855 win=65535 modulator=0] [lo=1004209856 high=1004274961 win=64537 modulator=0] 4:9 S seq=1634723484 (1634723484) ack=1004209856 len=0 ackskew=0 pkts=5:4 dir=in,fwd I tried to set custom tcp timeout options in this rules but this does not help pass log proto tcp from any to { $apphpr01 $apphpr02 } port { 9090 } keep state (tcp.opening 60, tcp.closed 180, tcp.finwait 90) Any ideas on how can I know why this connections are being blocked ?? I can provide any additional information needed. Regards, Alexandre From max at love2party.net Fri Aug 15 14:58:19 2008 From: max at love2party.net (Max Laier) Date: Fri Aug 15 14:58:25 2008 Subject: why BAD state messages In-Reply-To: <8e10486b0808150708g200727b8sc2f4993eee9f5248@mail.gmail.com> References: <8e10486b0808150708g200727b8sc2f4993eee9f5248@mail.gmail.com> Message-ID: <200808151658.15440.max@love2party.net> On Friday 15 August 2008 16:08:38 Alexandre Biancalana wrote: > Hi list, > > I'm experiencing some problems with blocked connections because of > bad states but I need some more information about why this is > happening, if this is timeout between tcp handshake, or state creation > or application trying to talk on closed connection. > > I have two FreeBSD 7-STABLE with PF, carp, pfsync and max carpdev > patch and two application servers (jboss) that listen on port 9090 > behind this firewalls, some connections from external clients off this > appservers are (apparently random) being blocked, enabling loud (pfctl > -x loud) I can see in /var/log/messages the following messages: > > kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 > 10.10.110.34:52347 [lo=3922530250 high=3922595445 win=65535 > modulator=0] [lo=3059100500 high=3059158735 win=65195 modulator=0] 4:4 > S seq=398900533 (398900533) ack=3059100500 len=0 ackskew=0 pkts=6:20 > dir=in,fwd > kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 > 10.10.110.34:50668 [lo=395881033 high=395946233 win=65535 modulator=0] > [lo=3568232053 high=3568290288 win=65200 modulator=0] 4:4 S > seq=2480335288 (2480335288) ack=3568232053 len=0 ackskew=0 pkts=6:20 > dir=in,fwd > kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 > 10.10.110.34:51582 [lo=3528357041 high=3528421509 win=65535 > modulator=0] [lo=3809540772 high=3809605893 win=64468 modulator=0] 9:9 > S seq=3810516558 (3810516558) ack=3809540772 len=0 ackskew=0 pkts=6:5 > dir=in,fwd > kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 > 10.10.110.34:50668 [lo=395881033 high=395946233 win=65535 modulator=0] > [lo=3568232053 high=3568290288 win=65200 modulator=0] 4:4 S > seq=2480335288 (2480335288) ack=3568232053 len=0 ackskew=0 pkts=6:20 > dir=in,fwd > kernel: pf: BAD state: TCP 10.10.6.18:9090 10.10.6.18:9090 > 10.10.81.242:2434 [lo=538716318 high=538780855 win=65535 modulator=0] > [lo=1004209856 high=1004274961 win=64537 modulator=0] 4:9 S > seq=1634723484 (1634723484) ack=1004209856 len=0 ackskew=0 pkts=5:4 > dir=in,fwd > > I tried to set custom tcp timeout options in this rules but this does not > help > > pass log proto tcp from any to { $apphpr01 $apphpr02 } port { 9090 } > keep state (tcp.opening 60, tcp.closed 180, tcp.finwait 90) > > > Any ideas on how can I know why this connections are being blocked ?? > I can provide any additional information needed. The blocked packets are SYNs. That means you are trying to reuse a port. This works if the state on both sides is >= FIN_WAIT2 (9) and you have pf.c r181291 (or one that has it merged). CVS rev 1.55 or 1.46.2.3 (RELENG_7) or apply the following patch: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf.c.diff?r1=1.54;r2=1.55 This should fix the instances above where it says "...] 9:9 S ..." The others might be an artifact from pfsync or asymmetric routing? You can also mitigate the problem by giving your clients and the pf-forwarding a larger port range for outgoing connections. This is a typical problem if you open a large number of connections from one client (or load balancer) to one server. You can only have so many open at a given time. Check if you can enable streaming mode somehow. -- /"\ 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 ryanfirst at sympatico.ca Fri Aug 15 15:03:21 2008 From: ryanfirst at sympatico.ca (B O'Reilly) Date: Fri Aug 15 15:03:26 2008 Subject: syn flood, tcpdump readings (Tom Huppi) References: <20080808120026.58759106569E@hub.freebsd.org> Message-ID: Tom, start by hardening the server (I know this isn't pf specific but, it needs to done) Link for hardening FreeBSD - http://www.bsdguides.org/guides/freebsd/security/harden.php. Enable the "configure FreeBSD to drop SYN/FIN packets:" and monitor the results. Drop known garbage using Pf eg: block drop in quick from to any Ports to look into - lockdown and mod_security. I use the denyhost database to drop any connections from the list for a 24 hr period. Regards From biancalana at gmail.com Fri Aug 15 16:26:32 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Fri Aug 15 16:26:49 2008 Subject: why BAD state messages In-Reply-To: <200808151658.15440.max@love2party.net> References: <8e10486b0808150708g200727b8sc2f4993eee9f5248@mail.gmail.com> <200808151658.15440.max@love2party.net> Message-ID: <8e10486b0808150926m7e25bcedw34b24c2e7707e445@mail.gmail.com> On 8/15/08, Max Laier wrote: > On Friday 15 August 2008 16:08:38 Alexandre Biancalana wrote: > > Hi list, > > > > I'm experiencing some problems with blocked connections because of > > bad states but I need some more information about why this is > > happening, if this is timeout between tcp handshake, or state creation > > or application trying to talk on closed connection. > > > > I have two FreeBSD 7-STABLE with PF, carp, pfsync and max carpdev > > patch and two application servers (jboss) that listen on port 9090 > > behind this firewalls, some connections from external clients off this > > appservers are (apparently random) being blocked, enabling loud (pfctl > > -x loud) I can see in /var/log/messages the following messages: > > > > kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 > > 10.10.110.34:52347 [lo=3922530250 high=3922595445 win=65535 > > modulator=0] [lo=3059100500 high=3059158735 win=65195 modulator=0] 4:4 > > S seq=398900533 (398900533) ack=3059100500 len=0 ackskew=0 pkts=6:20 > > dir=in,fwd > > kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 > > 10.10.110.34:50668 [lo=395881033 high=395946233 win=65535 modulator=0] > > [lo=3568232053 high=3568290288 win=65200 modulator=0] 4:4 S > > seq=2480335288 (2480335288) ack=3568232053 len=0 ackskew=0 pkts=6:20 > > dir=in,fwd > > kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 > > 10.10.110.34:51582 [lo=3528357041 high=3528421509 win=65535 > > modulator=0] [lo=3809540772 high=3809605893 win=64468 modulator=0] 9:9 > > S seq=3810516558 (3810516558) ack=3809540772 len=0 ackskew=0 pkts=6:5 > > dir=in,fwd > > kernel: pf: BAD state: TCP 10.10.6.19:9090 10.10.6.19:9090 > > 10.10.110.34:50668 [lo=395881033 high=395946233 win=65535 modulator=0] > > [lo=3568232053 high=3568290288 win=65200 modulator=0] 4:4 S > > seq=2480335288 (2480335288) ack=3568232053 len=0 ackskew=0 pkts=6:20 > > dir=in,fwd > > kernel: pf: BAD state: TCP 10.10.6.18:9090 10.10.6.18:9090 > > 10.10.81.242:2434 [lo=538716318 high=538780855 win=65535 modulator=0] > > [lo=1004209856 high=1004274961 win=64537 modulator=0] 4:9 S > > seq=1634723484 (1634723484) ack=1004209856 len=0 ackskew=0 pkts=5:4 > > dir=in,fwd > > > > I tried to set custom tcp timeout options in this rules but this does not > > help > > > > pass log proto tcp from any to { $apphpr01 $apphpr02 } port { 9090 } > > keep state (tcp.opening 60, tcp.closed 180, tcp.finwait 90) > > > > > > Any ideas on how can I know why this connections are being blocked ?? > > I can provide any additional information needed. > > > The blocked packets are SYNs. That means you are trying to reuse a port. > This works if the state on both sides is >= FIN_WAIT2 (9) and you have pf.c > r181291 (or one that has it merged). CVS rev 1.55 or 1.46.2.3 (RELENG_7) or > apply the following patch: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf.c.diff?r1=1.54;r2=1.55 Hi Max ! Thank you for your quick the reply. Looking at machine's pf.c this looks too old # grep FBSD /usr/src/sys/contrib/pf/net/pf.c __FBSDID("$FreeBSD: src/sys/contrib/pf/net/pf.c,v 1.46.2.1 2007/11/25 19:26:46 mlaier Exp $"); I will do a csup, rebuild the kernel and see how this improve the situation. > > This should fix the instances above where it says "...] 9:9 S ..." The others > might be an artifact from pfsync or asymmetric routing? You can also mitigate > the problem by giving your clients and the pf-forwarding a larger port range > for outgoing connections. This is a typical problem if you open a large > number of connections from one client (or load balancer) to one server. You > can only have so many open at a given time. Check if you can enable streaming > mode somehow. Looking the logs I made some math on each state 9:9 6174 times 4:4 3283 times 4:9 2611 times 10:10 1382 times 2:0 878 times 9:4 520 times How can I give a larger range for outgoing conections if the clients connect directly to the servers ? In this case I don't have any rdr rule. Thank you again! From koitsu at FreeBSD.org Fri Aug 15 17:30:46 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Aug 15 17:31:01 2008 Subject: why BAD state messages In-Reply-To: <8e10486b0808150926m7e25bcedw34b24c2e7707e445@mail.gmail.com> References: <8e10486b0808150708g200727b8sc2f4993eee9f5248@mail.gmail.com> <200808151658.15440.max@love2party.net> <8e10486b0808150926m7e25bcedw34b24c2e7707e445@mail.gmail.com> Message-ID: <20080815173046.GA99454@eos.sc1.parodius.com> On Fri, Aug 15, 2008 at 01:26:31PM -0300, Alexandre Biancalana wrote: > Looking the logs I made some math on each state > > 9:9 6174 times > 4:4 3283 times > 4:9 2611 times > 10:10 1382 times > 2:0 878 times > 9:4 520 times pfctl -s info will show a total counter for this (and some other oddities, but the majority are probably for what Max has described above), called state-mismatch. > How can I give a larger range for outgoing conections if the clients > connect directly to the servers ? In this case I don't have any rdr > rule. Clients connecting ***to*** the FreeBSD server would be considered an incoming connection, not an outgoing one. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From biancalana at gmail.com Sun Aug 17 22:21:14 2008 From: biancalana at gmail.com (Alexandre Biancalana) Date: Sun Aug 17 22:21:21 2008 Subject: why BAD state messages In-Reply-To: <20080815173046.GA99454@eos.sc1.parodius.com> References: <8e10486b0808150708g200727b8sc2f4993eee9f5248@mail.gmail.com> <200808151658.15440.max@love2party.net> <8e10486b0808150926m7e25bcedw34b24c2e7707e445@mail.gmail.com> <20080815173046.GA99454@eos.sc1.parodius.com> Message-ID: <8e10486b0808171521l1e07c3eay4e462a5599b08a79@mail.gmail.com> On 8/15/08, Jeremy Chadwick wrote: > On Fri, Aug 15, 2008 at 01:26:31PM -0300, Alexandre Biancalana wrote: > > Looking the logs I made some math on each state > > > > 9:9 6174 times > > 4:4 3283 times > > 4:9 2611 times > > 10:10 1382 times > > 2:0 878 times > > 9:4 520 times > > > pfctl -s info will show a total counter for this (and some other > oddities, but the majority are probably for what Max has described > above), called state-mismatch. I know that. > > > > How can I give a larger range for outgoing conections if the clients > > connect directly to the servers ? In this case I don't have any rdr > > rule. > > > Clients connecting ***to*** the FreeBSD server would be considered an > incoming connection, not an outgoing one. I know that too. What I don't know is how to give a larger range to the connections originated from the clients. After do csup and apply Max carpdev patch, I get the following error running make buildkernel [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/netinet/ip_carp.c cc1: warnings being treated as errors /usr/src/sys/netinet/ip_carp.c: In function 'carp_setroute': /usr/src/sys/netinet/ip_carp.c:394: warning: assignment from incompatible pointer type *** Error code 1 Stop in /usr/obj/usr/src/sys/FWPRDIV. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any Ideas ? Regards, Alexandre From bugmaster at FreeBSD.org Mon Aug 18 11:06:54 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 18 11:08:19 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200808181106.m7IB6sKT079889@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o kern/121704 pf [pf] PF mangles loopback packets o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/125467 pf [pf] pf keep state bug while handling sessions between 10 problems total. From volker at vwsoft.com Mon Aug 18 22:39:02 2008 From: volker at vwsoft.com (Volker) Date: Mon Aug 18 22:39:16 2008 Subject: LOR with pf + synproxy state Message-ID: <48A9F452.8020900@vwsoft.com> Hi! Last week I discovered an LOR on 7-STABLE (last build: 2008-Aug-17, RELENG_7). I can easily recreate the problem when running a synproxy state rule for incoming tcp connections and ssh'ing to my box. W/o using synproxy state (keep'ing state instead), no LOR takes place. lock order reversal: 1st 0xc575c92c pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6774 2nd 0xc521777c radix node head (radix node head) @ /usr/src/sys/net/route.c:278 KDB: stack backtrace: db_trace_self_wrapper(c0a2fa65,e557b890,c075f315,c0a30e10,c521777c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0a30e10,c521777c,c0a31129,c0a31129,c0a374a0,...) at kdb_backtrace+0x29 witness_checkorder(c521777c,9,c0a374a0,116,c507d000,...) at witness_checkorder+0x5e5 _mtx_lock_flags(c521777c,0,c0a374a0,116,c5fe9a00,...) at _mtx_lock_flags+0x34 rtalloc1_fib(e557b998,1,100,0,e557b994,...) at rtalloc1_fib+0x76 rtalloc_ign_fib(e557b994,100,0,e557b9b4,c5734a38,...) at rtalloc_ign_fib+0xad in_rtalloc_ign(e557b994,100,0,692a1600,5b47f56,...) at in_rtalloc_ign+0x1f pf_calc_mss(c62a881c,2,5b4,2,e557bb4c,...) at pf_calc_mss+0x88 pf_test_tcp(e557bb68,e557bb64,1,c56e9400,c5fe9a00,...) at pf_test_tcp+0xdf6 pf_test(1,c507d000,e557bbc4,0,0,...) at pf_test+0x1028 pf_check_in(0,e557bbc4,c507d000,1,0,...) at pf_check_in+0x39 pfil_run_hooks(c0b79ec0,e557bc18,c507d000,1,0,...) at pfil_run_hooks+0x78 ip_input(c5fe9a00,14e,800,c507d000,800,...) at ip_input+0x265 netisr_dispatch(2,c5fe9a00,10,3,0,...) at netisr_dispatch+0x55 ether_demux(c507d000,c5fe9a00,3,0,3,...) at ether_demux+0x1c1 ether_input(c507d000,c5fe9a00,c0a0391b,c57,c507d000,...) at ether_input+0x323 bge_intr(c5084000,0,c0a2b122,4b6,c4ef84e8,...) at bge_intr+0x77a ithread_loop(c50814f0,e557bd38,c0a2af4a,305,c508cad0,...) at ithread_loop+0x155 fork_exit(c07102d0,c50814f0,e557bd38) at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe557bd70, ebp = 0 --- KDB: enter: witness_checkorder exclusive sleep mutex pf task mtx r = 0 (0xc575c92c) locked @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6774 shared rw PFil hook read/write mutex r = 0 (0xc0b79ed8) locked @ /usr/src/sys/net/pfil.c:73 exclusive sx so_rcv_sx r = 0 (0xc5db208c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx so_rcv_sx r = 0 (0xc551f22c) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sleep mutex pf task mtx r = 0 (0xc575c92c) locked @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6774 shared rw PFil hook read/write mutex r = 0 (0xc0b79ed8) locked @ /usr/src/sys/net/pfil.c:73 pf rules used: ## Macros TCPSYN="S/SA" if_lan = "bge0" if_wlan = "ndis0" if_ipsec = "enc" ########################### tcp_in = "{ ssh http mdns 9102 49101 5900 }" udp_in = "{ mdns snmp 5029 }" passicmp = "{ 3 4 6 9 10 11 12 17 18 }" samba_tcp = "{ 139 445 }" samba_udp = "{ 137 1434 }" ###################################################### table { 127/8 10/8 172.16/12 192.168/16 } table { 224/8 239/8 } ###################################################### ## GLOBAL OPTIONS set block-policy drop set fingerprints "/etc/pf.os" set state-policy if-bound set skip on lo0 set optimization conservative ########################### ## TRAFFIC NORMALIZATION scrub all random-id fragment reassemble reassemble tcp ########################### ## TRANSLATION RULES (NAT) nat on $if_lan -> ($if_lan) nat on $if_wlan -> ($if_wlan) ###################################################### ## FILTER RULES block quick on lo0 proto {tcp udp} from any to any port biff pass quick on lo0 all antispoof log quick for { $if_lan $if_wlan } block drop log all block return in quick proto { tcp udp } from any to any port auth ########################### # IPSEC VPN ########################### pass log quick on {$if_lan $if_wlan} proto udp from any \ to any port isakmp keep state pass log quick on {$if_lan $if_wlan} proto udp from any \ to any port isakmp keep state pass quick log on {$if_lan $if_wlan} proto { ah, esp } from any \ to any keep state pass quick log on {$if_lan $if_wlan} proto { ah, esp } from any \ to any keep state pass quick log on $if_ipsec from any to any keep state ########################### # ICMP ########################### pass quick log on {$if_lan $if_wlan} proto icmp from any to any \ tag PASSOK keep state pass quick log inet proto icmp all icmp-type $passicmp keep state \ (max 2, max-src-states 1, max-src-nodes 1, source-track rule ) pass in quick log on {$if_lan $if_wlan} proto icmp from any to any \ keep state probability 50% ########################### # out traffic ########################### pass out log quick on {$if_lan $if_wlan} all flags $TCPSYN keep state ########################### # in traffic ########################### # allow broadcasts + samba - don't log pass quick on $if_lan from any to ($if_lan:broadcast) pass quick on $if_wlan from any to ($if_wlan:broadcast) pass quick on {$if_lan $if_wlan} from any to 255.255.255.255 pass in log on {$if_lan $if_wlan} proto tcp \ from any to any port $tcp_in \ flags $TCPSYN synproxy state # change to 'keep state' here to avoid LOR pass in log on {$if_lan $if_wlan} proto tcp from any port $tcp_in \ to any flags $TCPSYN synproxy state # change to 'keep state' here to avoid LOR pass in log on {$if_lan $if_wlan} proto udp from any \ to any port $udp_in keep state pass in log on {$if_lan $if_wlan} proto udp from any port $udp_in \ to any keep state pass quick on {$if_lan $if_wlan} from any to # EOF That LOR may be the same as reported here before (2007-12) - haven't checked the old sources (will verify if it's worth the time to confirm): http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2007-12/msg00150.html `uname -a`: FreeBSD cesar.sz.vwsoft.com 7.0-STABLE FreeBSD 7.0-STABLE #38: Sun Aug 17 15:12:10 CEST 2008 root@cesar.sz.vwsoft.com:/usr/obj/usr/src/sys/CESAR i386 Volker From freebsd-pf at pp.dyndns.biz Wed Aug 20 07:59:50 2008 From: freebsd-pf at pp.dyndns.biz (=?ISO-8859-1?Q?Morgan_Wesstr=F6m?=) Date: Wed Aug 20 07:59:57 2008 Subject: ALTQ weirdness Message-ID: <48ABCA08.6010203@pp.dyndns.biz> Hi. For five years I've used ALTQ to shape the upload of my DSL connection and it has worked very well. All details can be found further down in this mail but the basic setup is a default CBQ queue with 10% of the bandwidth and another queue for the remaining 90% with three child queues where I put traffic I want to prioritize. All queues can borrow bandwidth from each other. When the prio queues are fully utilized the default queue falls back to 10% just as expected. The strange thing happens if I saturate my DOWNLOAD at this point. The default queue is then suddenly able to "steal" much more than its 10% share even though the demand for bandwidth in the prio queues are unchanged at max. The bahaviour can be seen in the lower of the pfstat graphs here at -1.5 hours: http://pp.dyndns.biz/altq-weirdness.png The red spike is the TCP ACKs from the download which are correctly put in the highest priority child queue. Another download can be seen at -6 hours but it doesn't saturate the download bandwidth and the default queue remains at 10% there. Obviously there is something I'm doing wrong and don't understand and I'm just curious of what it is so I can make the queues behave exactly the way I intended. Queue definitions from /etc/pf.conf: altq on $ext_if cbq bandwidth $up_limit queue {q_def, q_pri} queue q_def bandwidth 10% qlimit 400 cbq( borrow default ) queue q_pri bandwidth 90% cbq( borrow ) {q_hv, q_p2p, q_p1, q_p2} queue q_hv bandwidth 10% priority 2 cbq( borrow ) queue q_p2p bandwidth 10% priority 3 cbq( borrow ) queue q_p1 bandwidth 20% priority 5 cbq( borrow ) queue q_p2 bandwidth 60% priority 7 cbq( borrow ) # uname -a FreeBSD gatekeeper.pp.dyndns.biz 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #1: Fri Aug 15 14:12:27 CEST 2008 pp@gatekeeper.pp.dyndns.biz:/usr/obj/usr/src/sys/MYKERNEL amd64 This is on amd64 but I experienced the exact same behaviour on my old router running FreeBSD 6.3/i386 Kind regards Morgan Wesstr?m From eridan911 at gmail.com Wed Aug 20 13:21:23 2008 From: eridan911 at gmail.com (Erik Danielsson) Date: Wed Aug 20 13:21:31 2008 Subject: Limiting bandwidth Message-ID: Hello, I'm using PF together with ALTQ, but my need of limiting bandwidth has changed. I need to be able to limit the bandwidth from/to a certain IP range, but only once a specific amount of data has been transferred from/to that IP range. At midnight I want the counter to be reset, and everything should start over. For example, I want to allow, let's say 10 GiB from e.g 192.168.0.1/24, and once the 10GiB limit has been reached, I want to limit the bandwidth to xx kbits/s until midnight. Any ideas how to accomplish this, can it be done using PF and ALTQ? Regards Erik Danielsson From jille at quis.cx Wed Aug 20 13:42:06 2008 From: jille at quis.cx (Jille) Date: Wed Aug 20 13:42:12 2008 Subject: Limiting bandwidth In-Reply-To: References: Message-ID: <48AC1BCE.3050109@quis.cx> Erik Danielsson wrote: > Hello, > > I'm using PF together with ALTQ, but my need of limiting bandwidth has > changed. I need to be able to limit the bandwidth from/to a certain IP > range, but only once a specific amount of data has been transferred from/to > that IP range. At midnight I want the counter to be reset, and everything > should start over. > > For example, I want to allow, let's say 10 GiB from e.g 192.168.0.1/24, and > once the 10GiB limit has been reached, I want to limit the bandwidth to xx > kbits/s until midnight. > Any ideas how to accomplish this, can it be done using PF and ALTQ? > afaik, you can only limit the bandwith with pf/altq and not count the total usage, and use that in rules. The best you can do (I think), is let pf create stats of the used bandwidth, and let some script check whether they reached the 10GiB limit, and if so add that rule to a table that limits bandwith. and a script that resets the counters at midmight and flush the table. -- Jille > Regards > Erik Danielsson > _______________________________________________ > 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 oleksandr at samoylyk.sumy.ua Wed Aug 20 13:43:39 2008 From: oleksandr at samoylyk.sumy.ua (Oleksandr Samoylyk) Date: Wed Aug 20 13:43:46 2008 Subject: Limiting bandwidth In-Reply-To: References: Message-ID: <48AC1B8D.6000903@samoylyk.sumy.ua> Erik Danielsson wrote: > Hello, > > I'm using PF together with ALTQ, but my need of limiting bandwidth has > changed. I need to be able to limit the bandwidth from/to a certain IP > range, but only once a specific amount of data has been transferred from/to > that IP range. At midnight I want the counter to be reset, and everything > should start over. > > For example, I want to allow, let's say 10 GiB from e.g 192.168.0.1/24, and > once the 10GiB limit has been reached, I want to limit the bandwidth to xx > kbits/s until midnight. > > Any ideas how to accomplish this, can it be done using PF and ALTQ? > Probably by means of external scripts which regenerate pf rules as cron jobs? :) -- Oleksandr Samoylyk OVS-RIPE From leslie at eskk.nu Wed Aug 20 14:27:41 2008 From: leslie at eskk.nu (Leslie Jensen) Date: Wed Aug 20 14:27:49 2008 Subject: port stealth mode? Message-ID: <48AC266D.2030902@eskk.nu> Hello I've done some testing with Steve Gibsons "Shields up" https://www.grc.com/x/ne.dll?bh0bkyd2 These tests lists the ports as closed but visible. Instead the site suggest that one uses stealth so that the ports are not visible from the Internet. Is there a way to achieve this with PF? Thanks Leslie From koitsu at FreeBSD.org Wed Aug 20 14:38:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 20 14:39:02 2008 Subject: port stealth mode? In-Reply-To: <48AC266D.2030902@eskk.nu> References: <48AC266D.2030902@eskk.nu> Message-ID: <20080820143855.GA40160@eos.sc1.parodius.com> On Wed, Aug 20, 2008 at 04:13:01PM +0200, Leslie Jensen wrote: > I've done some testing with Steve Gibsons "Shields up" > https://www.grc.com/x/ne.dll?bh0bkyd2 > > These tests lists the ports as closed but visible. > > Instead the site suggest that one uses stealth so that the ports are not > visible from the Internet. > > Is there a way to achieve this with PF? The "block" directive, along with "set block-policy drop" should suffice for accomplishing this in pf. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From glen.j.barber at gmail.com Wed Aug 20 14:48:06 2008 From: glen.j.barber at gmail.com (Glen Barber) Date: Wed Aug 20 14:48:11 2008 Subject: port stealth mode? In-Reply-To: <48AC266D.2030902@eskk.nu> References: <48AC266D.2030902@eskk.nu> Message-ID: <4ad871310808200748p154b2d96t4c120278bbce4273@mail.gmail.com> There is sysctl for it. Look for tcp.blackhole and udp.blackhole. -- Glen Barber (570)328-0318 From freebsd at chrisbuechler.com Wed Aug 20 15:06:57 2008 From: freebsd at chrisbuechler.com (Chris Buechler) Date: Wed Aug 20 15:07:03 2008 Subject: port stealth mode? In-Reply-To: <48AC266D.2030902@eskk.nu> References: <48AC266D.2030902@eskk.nu> Message-ID: <48AC2C86.6060306@chrisbuechler.com> Leslie Jensen wrote: > Hello > > I've done some testing with Steve Gibsons "Shields up" > > https://www.grc.com/x/ne.dll?bh0bkyd2 > > These tests lists the ports as closed but visible. > > Instead the site suggest that one uses stealth so that the ports are > not visible from the Internet. > > Is there a way to achieve this with PF? That's what pf does by default if you don't specify "return", "return-rst" or "return-icmp" in your block rules. From leslie at eskk.nu Wed Aug 20 17:11:17 2008 From: leslie at eskk.nu (Leslie Jensen) Date: Wed Aug 20 17:11:30 2008 Subject: port stealth mode? In-Reply-To: <20080820143855.GA40160@eos.sc1.parodius.com> References: <48AC266D.2030902@eskk.nu> <20080820143855.GA40160@eos.sc1.parodius.com> Message-ID: <48AC502B.8080901@eskk.nu> Jeremy Chadwick skrev: > On Wed, Aug 20, 2008 at 04:13:01PM +0200, Leslie Jensen wrote: >> I've done some testing with Steve Gibsons "Shields up" >> https://www.grc.com/x/ne.dll?bh0bkyd2 >> >> These tests lists the ports as closed but visible. >> >> Instead the site suggest that one uses stealth so that the ports are not >> visible from the Internet. >> >> Is there a way to achieve this with PF? > > The "block" directive, along with "set block-policy drop" should suffice > for accomplishing this in pf. > Thank you Jeremy. I had "return" instead of "drop". Now when I do the test the ports 0, 1 and 53 are open. I do not have any rules to allow these ports. Any suggestions on what might be the reason for this? /Leslie From leslie at eskk.nu Wed Aug 20 17:16:20 2008 From: leslie at eskk.nu (Leslie Jensen) Date: Wed Aug 20 17:16:30 2008 Subject: #2... sorry typing error Re: port stealth mode? In-Reply-To: <20080820143855.GA40160@eos.sc1.parodius.com> References: <48AC266D.2030902@eskk.nu> <20080820143855.GA40160@eos.sc1.parodius.com> Message-ID: <48AC515B.7060409@eskk.nu> Jeremy Chadwick skrev: > On Wed, Aug 20, 2008 at 04:13:01PM +0200, Leslie Jensen wrote: >> I've done some testing with Steve Gibsons "Shields up" >> https://www.grc.com/x/ne.dll?bh0bkyd2 >> >> These tests lists the ports as closed but visible. >> >> Instead the site suggest that one uses stealth so that the ports are not >> visible from the Internet. >> >> Is there a way to achieve this with PF? > > The "block" directive, along with "set block-policy drop" should suffice > for accomplishing this in pf. > Thank you Jeremy. I had "return" instead of "drop". Now when I do the test the ports 0, 1 and 53 are closed, not dropped. I do not have any rules to allow these ports. Any suggestions on what might be the reason for this? /Leslie _______________________________________________ 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 leslie at eskk.nu Wed Aug 20 17:26:28 2008 From: leslie at eskk.nu (Leslie Jensen) Date: Wed Aug 20 17:26:35 2008 Subject: Question about icmp Message-ID: <48AC53BC.8040003@eskk.nu> When setting up PF I found the recommendation to use the following rule to allow ICMP to pass. # macros icmp_types="echoreq" # filter rules pass in inet proto icmp all icmp-type $icmp_types keep state I do not understand why this is necessary! Will someone Please explain to me why it's necessary if I must have it, or if I can delete that rule. Thanks /Leslie From leslie at eskk.nu Wed Aug 20 17:50:28 2008 From: leslie at eskk.nu (Leslie Jensen) Date: Wed Aug 20 17:50:34 2008 Subject: A problem with variable Message-ID: <48AC595C.2090506@eskk.nu> I've defined a variable proxyport = "{ 8080 }" The rule rdr on $int_if inet proto tcp from $internal_net to any / port $proxy_services -> $proxy port $proxyport gives me a "Syntax error in config file:" I use the same variable in another rule and it does not produce a "Syntax error" pass in on $int_if inet proto tcp from $internal_net to / $proxy port $proxyport keep state If I change the variable in the first rule to 8080 it works. Can someone shed some light on this? Thanks /Leslie From nicolaskarp at freE.fr Wed Aug 20 18:40:59 2008 From: nicolaskarp at freE.fr (Nicolas KARP) Date: Wed Aug 20 18:41:06 2008 Subject: Question about icmp In-Reply-To: <48AC53BC.8040003@eskk.nu> References: <48AC53BC.8040003@eskk.nu> Message-ID: <48AC611E.60007@freE.fr> Leslie Jensen a ?crit : > > When setting up PF I found the recommendation to use the following > rule to allow ICMP to pass. > > # macros > icmp_types="echoreq" > > # filter rules > pass in inet proto icmp all icmp-type $icmp_types keep state > > I do not understand why this is necessary! > > Will someone Please explain to me why it's necessary if I must have > it, or if I can delete that rule. > > Thanks > > /Leslie > _______________________________________________ > 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" Hi, Fo my mind, it's just an example.. So,you can delete that rule if you don't want to permit the ping request :) You must add an ICMP rule if you are using PMTU discovery ! Bye, Nicos. From nicolaskarp at freE.fr Wed Aug 20 18:57:40 2008 From: nicolaskarp at freE.fr (Nicolas KARP) Date: Wed Aug 20 18:57:47 2008 Subject: A problem with variable In-Reply-To: <48AC595C.2090506@eskk.nu> References: <48AC595C.2090506@eskk.nu> Message-ID: <48AC6293.4020607@freE.fr> Leslie Jensen a ?crit : > > I've defined a variable > > proxyport = "{ 8080 }" > > The rule > > rdr on $int_if inet proto tcp from $internal_net to any / > port $proxy_services -> $proxy port $proxyport > > gives me a "Syntax error in config file:" > > I use the same variable in another rule and it does not produce a > "Syntax error" > > pass in on $int_if inet proto tcp from $internal_net to / > $proxy port $proxyport keep state > > If I change the variable in the first rule to 8080 it works. > > Can someone shed some light on this? > > Thanks > > /Leslie > _______________________________________________ > 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" Hi (one more time ;) ) You can't use a list in a rdr rule : see man pf.conf anf precisely the Grammar of PF.conf rdr-rule = [ "no" ] "rdr" [ "pass" [ "log" [ "(" logopts ")" ] ] ] [ "on" ifspec ] [ af ] [ protospec ] hosts [ "tag" string ] [ "tagged" string ] [ "->" ( redirhost | "{" redirhost-list "}" ) [ *portspec* ] [ *pooltype* ] ] pooltype = ( "bitmask" | "random" | "source-hash" [ ( hex-key | string-key ) ] | "round-robin" ) [ sticky-address ] portspec = "port" ( number | name ) [ ":" ( "*" | number | name ) ] From koitsu at FreeBSD.org Wed Aug 20 21:45:23 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 20 21:45:31 2008 Subject: #2... sorry typing error Re: port stealth mode? In-Reply-To: <48AC515B.7060409@eskk.nu> References: <48AC266D.2030902@eskk.nu> <20080820143855.GA40160@eos.sc1.parodius.com> <48AC515B.7060409@eskk.nu> Message-ID: <20080820214523.GA57450@eos.sc1.parodius.com> On Wed, Aug 20, 2008 at 07:16:11PM +0200, Leslie Jensen wrote: > Jeremy Chadwick skrev: >> On Wed, Aug 20, 2008 at 04:13:01PM +0200, Leslie Jensen wrote: >>> I've done some testing with Steve Gibsons "Shields up" >>> https://www.grc.com/x/ne.dll?bh0bkyd2 >>> >>> These tests lists the ports as closed but visible. >>> >>> Instead the site suggest that one uses stealth so that the ports are >>> not visible from the Internet. >>> >>> Is there a way to achieve this with PF? >> >> The "block" directive, along with "set block-policy drop" should suffice >> for accomplishing this in pf. >> > > Thank you Jeremy. > > I had "return" instead of "drop". > > Now when I do the test the ports 0, 1 and 53 are closed, not dropped. > > I do not have any rules to allow these ports. > > Any suggestions on what might be the reason for this? Based on my own attempts using Gibson's utility (grudgingly I might add), I have to assume he's talking about TCP ports and not UDP, and that there's only three result states returned: open, closed, or stealth. I assume the following: "Open" probably means a TCP connection was successfully made against the specific port -- meaning, the standard TCP connection handshake was successful (meaning a firewall is passing/allowing the TCP port, **and** there is a program listening on that TCP port). "Closed" probably means that a TCP connection failed against the specific port, but received either a TCP RST in response or an ICMP port unreachable message. "Stealth" probably means that a TCP connection failed against the specific port, and did not receive a TCP RST or ICMP port unreachable message. I can assure you that if you use pf's "block" directive, and ensure your block-policy is set to "drop", the FreeBSD box *will not* send back a TCP RST or an ICMP port unreachable when something attempts to connect to said port. Here's evidence: 72.20.106.125 attempts to connect to TCP port 89 on 72.20.106.126. 72.20.106.126 uses pf to block all incoming packets and only allow certain ports through -- TCP port 89 of which is NOT passed: 14:39:55.188088 IP 72.20.106.125.59153 > 72.20.106.126.89: S 3525520536:3525520536(0) win 65535 14:39:58.186955 IP 72.20.106.125.59153 > 72.20.106.126.89: S 3525520536:3525520536(0) win 65535 14:40:01.386830 IP 72.20.106.125.59153 > 72.20.106.126.89: S 3525520536:3525520536(0) win 65535 14:40:04.586707 IP 72.20.106.125.59153 > 72.20.106.126.89: S 3525520536:3525520536(0) win 65535 14:40:07.786585 IP 72.20.106.125.59153 > 72.20.106.126.89: S 3525520536:3525520536(0) win 65535 As you can see, there's no sign of TCP RST being emit by 72.20.106.126 in response to the connection, and there's also no ICMP port unreachable. If you're not using pf at all, you can use the sysctls described in the blackhole(4) manpage to achieve similar results -- but see the WARNING part of the manpage. Keep in mind that NAT port redirection can cause extra headaches, but it doesn't sound like you're testing against an IP that redirects ports via NAT. If you do use NAT, and have certain TCP redirected via a FreeBSD router to a machine on your local network, then there are further complications which need to be discussed. Again -- this is all speculative, because Gibson provides no technical data regarding how his utility works or what he's basing the results on. That is a serious problem, IMHO, and one reason why I tend to stay away from his utilities. Thirdly, regarding "ports 0 and 1" -- silly. Look at /etc/services; chances are you aren't using TCP or UDP port 1, and applications cannot bind to TCP or UDP port 0 (doing so, AFAIK, results in an application binding to an arbitrary/random port number), so I really have no idea what he's testing there. His own documentation even described this fact. Fourthly, you didn't state what FreeBSD version you're testing this against, or what your pf rules look like. Most importantly: you shouldn't base network/firewall security on the results of Gibson's utility. Meaning, if your goal is to make "Shields Up!" return a non-failure result, then you're probably wasting your time. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From max at love2party.net Wed Aug 20 21:55:39 2008 From: max at love2party.net (Max Laier) Date: Wed Aug 20 21:55:47 2008 Subject: #2... sorry typing error Re: port stealth mode? In-Reply-To: <48AC515B.7060409@eskk.nu> References: <48AC266D.2030902@eskk.nu> <20080820143855.GA40160@eos.sc1.parodius.com> <48AC515B.7060409@eskk.nu> Message-ID: <200808202355.37629.max@love2party.net> On Wednesday 20 August 2008 19:16:11 Leslie Jensen wrote: > Jeremy Chadwick skrev: > > On Wed, Aug 20, 2008 at 04:13:01PM +0200, Leslie Jensen wrote: > >> I've done some testing with Steve Gibsons "Shields up" > >> https://www.grc.com/x/ne.dll?bh0bkyd2 > >> > >> These tests lists the ports as closed but visible. > >> > >> Instead the site suggest that one uses stealth so that the ports are not > >> visible from the Internet. > >> > >> Is there a way to achieve this with PF? > > > > The "block" directive, along with "set block-policy drop" should suffice > > for accomplishing this in pf. > > Thank you Jeremy. > > I had "return" instead of "drop". > > Now when I do the test the ports 0, 1 and 53 are closed, not dropped. This might be your ISP "helping" ... i.e. they filter your traffic in order to protect against stupid Windows worms or enforce a policy ("you must not run a DNS server here"). If you can try tcptracing from outside to see if the RSTs really come from your pf box or from an ISP firewall (though that fact might be obfuscated, too). > I do not have any rules to allow these ports. > > Any suggestions on what might be the reason for this? -- /"\ 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 eridan911 at gmail.com Thu Aug 21 05:07:59 2008 From: eridan911 at gmail.com (Erik Danielsson) Date: Thu Aug 21 05:08:05 2008 Subject: Limiting bandwidth In-Reply-To: <48AC1BCE.3050109@quis.cx> References: <48AC1BCE.3050109@quis.cx> Message-ID: Thanks guys. One question remains though. To count the total traffic from a certain IP range, should a separate PF rule with a label be used? If so, how can I reset only the labels statistics whenever I want to? On Wed, Aug 20, 2008 at 3:27 PM, Jille wrote: > Erik Danielsson wrote: > >> Hello, >> >> I'm using PF together with ALTQ, but my need of limiting bandwidth has >> changed. I need to be able to limit the bandwidth from/to a certain IP >> range, but only once a specific amount of data has been transferred >> from/to >> that IP range. At midnight I want the counter to be reset, and everything >> should start over. >> >> For example, I want to allow, let's say 10 GiB from e.g 192.168.0.1/24, >> and >> once the 10GiB limit has been reached, I want to limit the bandwidth to xx >> kbits/s until midnight. >> Any ideas how to accomplish this, can it be done using PF and ALTQ? >> >> > afaik, you can only limit the bandwith with pf/altq and not count the total > usage, and use that in rules. > The best you can do (I think), is let pf create stats of the used > bandwidth, and let some script check whether they reached the 10GiB limit, > and if so add that rule to a table that limits bandwith. > and a script that resets the counters at midmight and flush the table. > > -- Jille > >> Regards >> Erik Danielsson >> _______________________________________________ >> 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 koitsu at FreeBSD.org Thu Aug 21 05:17:02 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 21 05:17:08 2008 Subject: Limiting bandwidth In-Reply-To: References: <48AC1BCE.3050109@quis.cx> Message-ID: <20080821051701.GA82314@eos.sc1.parodius.com> On Thu, Aug 21, 2008 at 07:07:57AM +0200, Erik Danielsson wrote: > Thanks guys. > > One question remains though. To count the total traffic from a certain IP > range, should a separate PF rule with a label be used? If so, how can I > reset only the labels statistics whenever I want to? The manpage to pfctl doesn't really indicate this is possible. You could simply delete then re-create the label rule, I would think. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From leslie at eskk.nu Thu Aug 21 05:28:50 2008 From: leslie at eskk.nu (Leslie Jensen) Date: Thu Aug 21 05:28:58 2008 Subject: #2... sorry typing error Re: port stealth mode? In-Reply-To: <20080820214523.GA57450@eos.sc1.parodius.com> References: <48AC266D.2030902@eskk.nu> <20080820143855.GA40160@eos.sc1.parodius.com> <48AC515B.7060409@eskk.nu> <20080820214523.GA57450@eos.sc1.parodius.com> Message-ID: <48ACFD0B.2030600@eskk.nu> > Most importantly: you shouldn't base network/firewall security on the > results of Gibson's utility. Meaning, if your goal is to make "Shields > Up!" return a non-failure result, then you're probably wasting your > time. > Thank you Jeremy :-) I'm fairly new to PF and when I see things I do not understand I need to ask. Now I understand, and as you state I'll stop waisting my time. You're almost certainly right about my ISP, they have limitations on what one can do and not do. /Leslie From jsimola at gmail.com Thu Aug 21 07:46:56 2008 From: jsimola at gmail.com (Jon Simola) Date: Thu Aug 21 07:47:02 2008 Subject: Limiting bandwidth In-Reply-To: References: <48AC1BCE.3050109@quis.cx> Message-ID: <8eea04080808210021v68b34d2cxb07573f8888b25bf@mail.gmail.com> On Wed, Aug 20, 2008 at 10:07 PM, Erik Danielsson wrote: > One question remains though. To count the total traffic from a certain IP > range, should a separate PF rule with a label be used? If so, how can I > reset only the labels statistics whenever I want to? PF already maintains counters for each entry in a table, add -v when showing a table to see them. So explaining in pseudo format, I'd try something like table persist; table persist { 10.0.0.1, 10.0.0.2, ... } pass in all pass out from to any pass out from to any queue overlimit You need a cronjob at midnight to flush the over10gb table, and zero the counters for myiprange. A second cronjob would do "pfctl -t myiprange -vT show", add up the numbers, and spit out any IPs that are over into "pfctl -t over10gb -T add $SOMEIPS" Hopefully that's enough to get you started, or at least an idea of some way to approach it. -- Jon From nejc at skoberne.net Mon Aug 25 09:37:23 2008 From: nejc at skoberne.net (=?ISO-8859-2?Q?Nejc_=A9koberne?=) Date: Mon Aug 25 09:37:30 2008 Subject: Proxying broadcasts? Message-ID: <48B27948.5040101@skoberne.net> Hello, I have a central FreeBSD 7.0 router running pf with SERVERS and USERS1 and USERS2 networks attached to it. I also have some Sybase SQL servers on SERVERS network, which use broadcasts to announce themselves to the network. Before, when there were no separate segments, everything worked fine of course. My question: is there any way to "proxy" (forward) broadcast requests from USERS1 to the SERVERS network? So the users in USERS* networks could find Sybase SQL servers via broadcasts? I tried something like this in my test environment (tried to NAT broadcasted DNS requests, just for trying if pf could do it): nat on $ServersInterface from 192.168.3.100 to 192.168.1.255 -> 192.168.1.1 rdr pass on $UsersInterface proto udp from 192.168.3.100 to 192.168.3.255 port 53 -> 192.168.1.255 (3.100 is a client from USERS1, 1.1 is the router) But this doesn't seem to be working (no translated packets on the interfaces). I guess it's impossible? Thanks, Nejc From bugmaster at FreeBSD.org Mon Aug 25 11:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 25 11:08:31 2008 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200808251106.m7PB6set027839@freefall.freebsd.org> Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o kern/121704 pf [pf] PF mangles loopback packets o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/125467 pf [pf] pf keep state bug while handling sessions between 10 problems total. From rajkumars at gmail.com Wed Aug 27 11:20:03 2008 From: rajkumars at gmail.com (Rajkumar S) Date: Wed Aug 27 11:20:09 2008 Subject: ALTQ and shaping an existing session Message-ID: <64de5c8b0808270347p2d8cf9ccydd63cae3b1ea6a14@mail.gmail.com> Hi, I have configured pf/altq to shape traffic in my freebsd box. rule fragments are as below. altq on rl0 cbq bandwidth 512Kb queue { lanRoot } altq on rl1 cbq bandwidth 512Kb queue { wanRoot } queue lanRoot bandwidth 512Kb cbq { lanStd , lanBad } queue lanStd bandwidth 400Kb cbq (default) queue lanBad bandwidth 112Kb cbq #(default) queue wanRoot bandwidth 512Kb cbq { wanStd , wanBad } queue wanStd bandwidth 450Kb cbq (default) queue wanBad bandwidth 62Kb cbq #(default) pass out quick on $lan from any to any keep state pass in quick on $lan from to any keep state queue lanBad pass in quick on $lan from any to any keep state pass out quick on $ext_if from any to any keep state pass in quick on $ext_if from any to keep state queue wanBad pass in quick on $ext_if from any to any keep state IPs are added to by an external program based on bandwidth. The problem is that even when a new ip is added to or removed from already existing sessions from the newly added ip continues to have previous shaping configuration. All new sessions are shaped as expected. I have tried rules without "keep state", but results are the same. Is this the expected behavior of pf? Can the shaping be performed for existing sessions also when an ip is added to ? with regards, raj From buchtajz at borsice.net Wed Aug 27 19:22:51 2008 From: buchtajz at borsice.net (Michal Buchtik) Date: Wed Aug 27 19:22:58 2008 Subject: ALTQ and shaping an existing session In-Reply-To: <64de5c8b0808270347p2d8cf9ccydd63cae3b1ea6a14@mail.gmail.com> References: <64de5c8b0808270347p2d8cf9ccydd63cae3b1ea6a14@mail.gmail.com> Message-ID: <1219864968.1536.14.camel@manwe.buchtikov.borsice.sfn> Rajkumar S p??e v st 27. 08. 2008 v 16:17 +0530: > The problem is that even when a new ip is added to or removed from > already existing sessions from the newly added ip continues > to have previous shaping configuration. All new sessions are shaped as > expected. I have tried rules without "keep state", but results are the > same. Is this the expected behavior of pf? Can the shaping be > performed for existing sessions also when an ip is added to ? I have same problem. The only way I found is kill existing states of affected ip's. But this is uncomfortable for users. Is there another solution? Michal From koitsu at FreeBSD.org Wed Aug 27 19:45:39 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Aug 27 19:45:46 2008 Subject: ALTQ and shaping an existing session In-Reply-To: <1219864968.1536.14.camel@manwe.buchtikov.borsice.sfn> References: <64de5c8b0808270347p2d8cf9ccydd63cae3b1ea6a14@mail.gmail.com> <1219864968.1536.14.camel@manwe.buchtikov.borsice.sfn> Message-ID: <20080827192938.GA1711@icarus.home.lan> On Wed, Aug 27, 2008 at 09:22:48PM +0200, Michal Buchtik wrote: > Rajkumar S p???e v st 27. 08. 2008 v 16:17 +0530: > > The problem is that even when a new ip is added to or removed from > > already existing sessions from the newly added ip continues > > to have previous shaping configuration. All new sessions are shaped as > > expected. I have tried rules without "keep state", but results are the > > same. Is this the expected behavior of pf? Can the shaping be > > performed for existing sessions also when an ip is added to ? > > I have same problem. The only way I found is kill existing states of > affected ip's. But this is uncomfortable for users. Is there another > solution? It sounds like the root of this problem is that "flags S/SA" is implicit on RELENG_7 for TCP rules. "keep state" is also implicit (on TCP, UDP, and ICMP rules). The only solutions I see, both of which have consequences: 1) Use "flags any", but this *is not* something you would want to use in conjunction with "keep state", since you only want to cause pf to begin tracking state when SYN of SYN+ACK is set, and not on FIN, RST, or other combinations. There is probably some combination of rules you could set up which could utilise "flags any" correctly, but the risks are high. 2) Add "no state" to rules you want shaping to occur on. This has the added drawback of pf not being able to keep track of state on such packets (performance hit), and you'll need to tune your pf rules to match on traffic going both directions (since there's no longer a state kept) Max, does this sound correct? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From max at love2party.net Wed Aug 27 19:57:14 2008 From: max at love2party.net (Max Laier) Date: Wed Aug 27 19:57:20 2008 Subject: ALTQ and shaping an existing session In-Reply-To: <20080827192938.GA1711@icarus.home.lan> References: <64de5c8b0808270347p2d8cf9ccydd63cae3b1ea6a14@mail.gmail.com> <1219864968.1536.14.camel@manwe.buchtikov.borsice.sfn> <20080827192938.GA1711@icarus.home.lan> Message-ID: <200808272157.11585.max@love2party.net> On Wednesday 27 August 2008 21:29:38 Jeremy Chadwick wrote: > On Wed, Aug 27, 2008 at 09:22:48PM +0200, Michal Buchtik wrote: > > Rajkumar S p???e v st 27. 08. 2008 v 16:17 +0530: > > > The problem is that even when a new ip is added to or removed from > > > already existing sessions from the newly added ip continues > > > to have previous shaping configuration. All new sessions are shaped as > > > expected. I have tried rules without "keep state", but results are the > > > same. Is this the expected behavior of pf? Can the shaping be > > > performed for existing sessions also when an ip is added to ? > > > > I have same problem. The only way I found is kill existing states of > > affected ip's. But this is uncomfortable for users. Is there another > > solution? > > It sounds like the root of this problem is that "flags S/SA" is implicit > on RELENG_7 for TCP rules. "keep state" is also implicit (on TCP, UDP, > and ICMP rules). > > The only solutions I see, both of which have consequences: > > 1) Use "flags any", but this *is not* something you would want to use in > conjunction with "keep state", since you only want to cause pf to begin > tracking state when SYN of SYN+ACK is set, and not on FIN, RST, or other > combinations. There is probably some combination of rules you could set > up which could utilise "flags any" correctly, but the risks are high. > > 2) Add "no state" to rules you want shaping to occur on. This has the > added drawback of pf not being able to keep track of state on such > packets (performance hit), and you'll need to tune your pf rules to > match on traffic going both directions (since there's no longer a state > kept) > > Max, does this sound correct? Yes, about right. There might be a way to solve this by hacking up the "pfctl -k" mechanism, though. In a nutshell every state maintains a reference to the rule it was created by (it's parent). The ALTQ queues used by that state come directly from that parent (i.e. the state doesn't store them). If we could modify the "pfctl -k" mechanism to move a state from one rule to another, the ALTQ definitions would change accordingly. I yet have to check how much work that would be or if there are any problems with the basic idea, but since there is a 3 byte hole in pfioc_state_kill this could even be MFCed. I'll have a look. -- /"\ 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 shupej at hermetek.com Thu Aug 28 00:57:12 2008 From: shupej at hermetek.com (James Shupe) Date: Thu Aug 28 00:57:18 2008 Subject: Squid/ Danguardian + Transparent Bridge Message-ID: <48B5F155.3000107@hermetek.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20080828/be27e530/signature-0001.pgp From koitsu at FreeBSD.org Thu Aug 28 01:03:34 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 28 01:03:41 2008 Subject: Squid/ Danguardian + Transparent Bridge In-Reply-To: <48B5F155.3000107@hermetek.com> References: <48B5F155.3000107@hermetek.com> Message-ID: <20080828010332.GA8172@icarus.home.lan> On Wed, Aug 27, 2008 at 07:29:09PM -0500, James Shupe wrote: > I've been trying to get pf to transparently redirect all incoming > traffic on port 80 to port 8080 on a bridge to pass through to > Dansguardian. This machine is a replacement for a Linux box which did > the same thing with IPtables flawlessly, but I can't seem to get it work > with PF. I've tried using dozens of rulesets, including route-to > statements, and have had no success. I was wondering if anybody has a > working ruleset that they could share as an example, as I've seen lots > of questions in mailing list archives regarding this, but no positive fixes. You mean something like this? rdr pass proto tcp from any to port 80 -> 127.0.0.1 port 8080 Assuming ipofyourbox is 4.4.4.4, this will transparently redirect incoming connections to 4.4.4.4 port 80 to 127.0.0.1 port 8080. Response packets will also be remapped appropriately (meaning the remote user will see the response packets coming from 4.4.4.4 port 80). This is under the assumption that Dansguardian is listening on 127.0.0.1 port 8080. It might just be listening on INADDR_ANY port 8080, in which case you should probably configure it to bind to 127.0.0.1 -- or if you cannot, set up an appropriate firewall rule in pf to block that traffic (so people on the Internet cannot connect to 4.4.4.4 port 8080 and talk to Dansguardian directly). Hope this helps. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From max at love2party.net Thu Aug 28 01:12:55 2008 From: max at love2party.net (Max Laier) Date: Thu Aug 28 01:13:01 2008 Subject: Squid/ Danguardian + Transparent Bridge In-Reply-To: <20080828010332.GA8172@icarus.home.lan> References: <48B5F155.3000107@hermetek.com> <20080828010332.GA8172@icarus.home.lan> Message-ID: <200808280312.45587.max@love2party.net> On Thursday 28 August 2008 03:03:32 Jeremy Chadwick wrote: > On Wed, Aug 27, 2008 at 07:29:09PM -0500, James Shupe wrote: > > I've been trying to get pf to transparently redirect all incoming > > traffic on port 80 to port 8080 on a bridge to pass through to > > Dansguardian. This machine is a replacement for a Linux box which did > > the same thing with IPtables flawlessly, but I can't seem to get it work > > with PF. I've tried using dozens of rulesets, including route-to > > statements, and have had no success. I was wondering if anybody has a > > working ruleset that they could share as an example, as I've seen lots > > of questions in mailing list archives regarding this, but no positive > > fixes. > > You mean something like this? > > rdr pass proto tcp from any to port 80 -> 127.0.0.1 port 8080 > > Assuming ipofyourbox is 4.4.4.4, this will transparently redirect > incoming connections to 4.4.4.4 port 80 to 127.0.0.1 port 8080. > Response packets will also be remapped appropriately (meaning the remote > user will see the response packets coming from 4.4.4.4 port 80). > > This is under the assumption that Dansguardian is listening on 127.0.0.1 > port 8080. It might just be listening on INADDR_ANY port 8080, in which > case you should probably configure it to bind to 127.0.0.1 -- or if > you cannot, set up an appropriate firewall rule in pf to block that > traffic (so people on the Internet cannot connect to 4.4.4.4 port 8080 > and talk to Dansguardian directly). Note that software that wants to do transparent proxying needs to be aware of the pf redirection. For squid you can enable code to do that by enabling the port option SQUID_PF (see make config). I have no idea if Dansguardian has support for pf or if squid or Dansguardian is the first to look at the traffic. If squid is the first you should be good ... otherwise you must talk to the Dansguardian people about pf support. -- /"\ 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 koitsu at FreeBSD.org Thu Aug 28 03:56:19 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Aug 28 03:56:25 2008 Subject: Fwd: Re: Squid/ Danguardian + Transparent Bridge Message-ID: <20080828034614.GA11207@icarus.home.lan> ----- Forwarded message from James Shupe ----- > From: James Shupe > To: Jeremy Chadwick > Date: Wed, 27 Aug 2008 20:26:59 -0500 > Subject: Re: Squid/ Danguardian + Transparent Bridge > > I've tried this, and it works with NAT but not when the interfaces are > in a bridge. I'll re-attempt this tomorrow though, just in case I'm wrong. > > Thank you, > James Shupe > > Jeremy Chadwick wrote: > > On Wed, Aug 27, 2008 at 07:29:09PM -0500, James Shupe wrote: > >> I've been trying to get pf to transparently redirect all incoming > >> traffic on port 80 to port 8080 on a bridge to pass through to > >> Dansguardian. This machine is a replacement for a Linux box which did > >> the same thing with IPtables flawlessly, but I can't seem to get it work > >> with PF. I've tried using dozens of rulesets, including route-to > >> statements, and have had no success. I was wondering if anybody has a > >> working ruleset that they could share as an example, as I've seen lots > >> of questions in mailing list archives regarding this, but no positive fixes. > > > > You mean something like this? > > > > rdr pass proto tcp from any to port 80 -> 127.0.0.1 port 8080 > > > > Assuming ipofyourbox is 4.4.4.4, this will transparently redirect > > incoming connections to 4.4.4.4 port 80 to 127.0.0.1 port 8080. > > Response packets will also be remapped appropriately (meaning the remote > > user will see the response packets coming from 4.4.4.4 port 80). > > > > This is under the assumption that Dansguardian is listening on 127.0.0.1 > > port 8080. It might just be listening on INADDR_ANY port 8080, in which > > case you should probably configure it to bind to 127.0.0.1 -- or if > > you cannot, set up an appropriate firewall rule in pf to block that > > traffic (so people on the Internet cannot connect to 4.4.4.4 port 8080 > > and talk to Dansguardian directly). > > > > Hope this helps. > > > > Thank you, > -- > James Shupe > HermeTek Network Solutions > http//www.hermetek.com > 1.866.325.6207 ----- End forwarded message ----- James forgot to CC the list when replying; I got his permission to forward this. His problem seems to be when using rdr while a bridge is in use. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ben at desync.com Fri Aug 29 10:54:28 2008 From: ben at desync.com (ben wilber) Date: Fri Aug 29 10:54:35 2008 Subject: pf and mxge Message-ID: <20080829105422.GI1644@exodus.desync.com> Hello, I'm trying to use PF on a machine with an mxge(4) interface and am having some difficulty. With my ruleset loaded, any TCP session that gets a state grinds to a halt. For example, I can log in via SSH and issue commands that return a couple lines, but the output from a command like dmesg(8) comes very slowly and sometimes won't finish before SSH times out. MTU on the interface is 1500 bytes. This doesn't happen unless states are created (e.g., not with "pass no state"). The machine is running -CURRENT for amd64 as of Jul 18th compiled with ALTQ, crypto and IPSEC, HZ=1000 and DEVICE_POLLING (though not enabled). IP and IPv6 forwarding are enabled, as well as fastforwarding. Only filtering; no bridges, ALTQ, NAT or scrubbing. Any insight? Thanks, bw. From koitsu at FreeBSD.org Fri Aug 29 11:04:01 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Aug 29 11:04:08 2008 Subject: pf and mxge In-Reply-To: <20080829105422.GI1644@exodus.desync.com> References: <20080829105422.GI1644@exodus.desync.com> Message-ID: <20080829110358.GA72503@icarus.home.lan> On Fri, Aug 29, 2008 at 06:54:23AM -0400, ben wilber wrote: > I'm trying to use PF on a machine with an mxge(4) interface and am > having some difficulty. With my ruleset loaded, any TCP session that > gets a state grinds to a halt. > > For example, I can log in via SSH and issue commands that return a > couple lines, but the output from a command like dmesg(8) comes very > slowly and sometimes won't finish before SSH times out. MTU on the > interface is 1500 bytes. This doesn't happen unless states are created > (e.g., not with "pass no state"). > > The machine is running -CURRENT for amd64 as of Jul 18th compiled with > ALTQ, crypto and IPSEC, HZ=1000 and DEVICE_POLLING (though not enabled). > IP and IPv6 forwarding are enabled, as well as fastforwarding. Only > filtering; no bridges, ALTQ, NAT or scrubbing. > > Any insight? I've seen this problem on RELENG_6, although the SSH connections would not "time out" -- after a page or so of 'dmesg' output, they would immediately get disconnected/severed. I believe the problem was caused by my use of "modulate state" instead of "keep state" (since on RELENG_6 "keep state" is not implicit). Are you using "reassemble tcp", "synproxy state", or "modulate state" directives? Does disabling RFC1323 (see sysctl) make a difference at all? Are you blindly filtering all ICMP traffic and destroying PMTU negotiation? Can you provide your pf.conf? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From mcdouga9 at egr.msu.edu Fri Aug 29 13:13:44 2008 From: mcdouga9 at egr.msu.edu (Adam McDougall) Date: Fri Aug 29 13:13:51 2008 Subject: pf and mxge In-Reply-To: <20080829110358.GA72503@icarus.home.lan> References: <20080829105422.GI1644@exodus.desync.com> <20080829110358.GA72503@icarus.home.lan> Message-ID: <20080829125549.GR64444@egr.msu.edu> On Fri, Aug 29, 2008 at 04:03:58AM -0700, Jeremy Chadwick wrote: On Fri, Aug 29, 2008 at 06:54:23AM -0400, ben wilber wrote: > I'm trying to use PF on a machine with an mxge(4) interface and am > having some difficulty. With my ruleset loaded, any TCP session that > gets a state grinds to a halt. > > For example, I can log in via SSH and issue commands that return a > couple lines, but the output from a command like dmesg(8) comes very > slowly and sometimes won't finish before SSH times out. MTU on the > interface is 1500 bytes. This doesn't happen unless states are created > (e.g., not with "pass no state"). > > The machine is running -CURRENT for amd64 as of Jul 18th compiled with > ALTQ, crypto and IPSEC, HZ=1000 and DEVICE_POLLING (though not enabled). > IP and IPv6 forwarding are enabled, as well as fastforwarding. Only > filtering; no bridges, ALTQ, NAT or scrubbing. > > Any insight? I've seen this problem on RELENG_6, although the SSH connections would not "time out" -- after a page or so of 'dmesg' output, they would immediately get disconnected/severed. I believe the problem was caused by my use of "modulate state" instead of "keep state" (since on RELENG_6 "keep state" is not implicit). Are you using "reassemble tcp", "synproxy state", or "modulate state" directives? Does disabling RFC1323 (see sysctl) make a difference at all? Are you blindly filtering all ICMP traffic and destroying PMTU negotiation? Can you provide your pf.conf? -- | Jeremy Chadwick jdc at parodius.com | Just for posterity, I had similar problems and ended up getting rid of floating state in favor of "set state-policy if-bound". If you run pfctl -x loud and watch the kernel output, you should be able to see a state mismatch when the ssh has a problem. Warning, I've had consoles lock up with too much output from pfctl -x loud, so if you care, don't run it too long or with too much traffic (pfctl -x none to disable). From fox at verio.net Fri Aug 29 15:56:38 2008 From: fox at verio.net (David DeSimone) Date: Fri Aug 29 15:56:52 2008 Subject: pf and mxge In-Reply-To: <20080829105422.GI1644@exodus.desync.com> References: <20080829105422.GI1644@exodus.desync.com> Message-ID: <20080829155630.GA31307@verio.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ben wilber wrote: > > For example, I can log in via SSH and issue commands that return a > couple lines, but the output from a command like dmesg(8) comes very > slowly and sometimes won't finish before SSH times out. MTU on the > interface is 1500 bytes. This doesn't happen unless states are > created (e.g., not with "pass no state"). This can happen when TCP Window Scaling (RFC1323) is in effect, but PF is not aware of it. PF can only capture the window scales in effect if it sees the "SYN" and "SYN+ACK" packets that begin a connection, as they are not advertised at any other time. If the state is built from the "middle" of a connection, PF enforces a much smaller version of the expected TCP window, and things slow down tremendously. This is why PF in FreeBSD 7.0 add the "flags S/SA" and "keep state" options by default. Since this is the default, it is surprising to me that you would see this type of behavior, but it gives you something to look into. - -- David DeSimone == Network Admin == fox@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFIuBwuFSrKRjX5eCoRAj70AJ0UIEt5TXIalIWHYWywYMWocHj/8gCfdJrD 8t8KYLSPL1VlLIWuda5v3/U= =Gk8w -----END PGP SIGNATURE----- This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. From ben at desync.com Sun Aug 31 17:30:06 2008 From: ben at desync.com (ben wilber) Date: Sun Aug 31 17:30:16 2008 Subject: pf and mxge In-Reply-To: <20080829125549.GR64444@egr.msu.edu> References: <20080829105422.GI1644@exodus.desync.com> <20080829110358.GA72503@icarus.home.lan> <20080829125549.GR64444@egr.msu.edu> Message-ID: <20080831172943.GA26180@exodus.desync.com> On Fri, Aug 29, 2008 at 08:55:49AM -0400, Adam McDougall wrote: > I've seen this problem on RELENG_6, although the SSH connections > would not "time out" -- after a page or so of 'dmesg' output, they > would immediately get disconnected/severed. I believe the problem was > caused by my use of "modulate state" instead of "keep state" (since on > RELENG_6 "keep state" is not implicit). Bingo. The problem was "modulate state". Sorry if the answer is obvious, but any idea why a new NIC might have aggravated this? In any case, thanks! bw. From koitsu at FreeBSD.org Sun Aug 31 18:06:21 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Aug 31 18:06:28 2008 Subject: pf and mxge In-Reply-To: <20080831172943.GA26180@exodus.desync.com> References: <20080829105422.GI1644@exodus.desync.com> <20080829110358.GA72503@icarus.home.lan> <20080829125549.GR64444@egr.msu.edu> <20080831172943.GA26180@exodus.desync.com> Message-ID: <20080831180618.GA34269@icarus.home.lan> On Sun, Aug 31, 2008 at 01:29:43PM -0400, ben wilber wrote: > On Fri, Aug 29, 2008 at 08:55:49AM -0400, Adam McDougall wrote: > > I've seen this problem on RELENG_6, although the SSH connections > > would not "time out" -- after a page or so of 'dmesg' output, they > > would immediately get disconnected/severed. I believe the problem was > > caused by my use of "modulate state" instead of "keep state" (since on > > RELENG_6 "keep state" is not implicit). > > Bingo. The problem was "modulate state". Sorry if the answer is > obvious, but any idea why a new NIC might have aggravated this? A new NIC wouldn't have had anything to do with the problem; it's probably always been there, or you just didn't notice it before. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |