From bugmaster at FreeBSD.org Mon Jun 1 11:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 1 11:09:05 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200906011106.n51B6vqb021181@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 31 problems total. From freebsd at optiksecurite.com Mon Jun 1 15:10:41 2009 From: freebsd at optiksecurite.com (Martin Turgeon) Date: Mon Jun 1 15:10:48 2009 Subject: State Mismatch and tcp.closed In-Reply-To: <52a241a292d8df1c0970d071267cb865.squirrel@mlaier.homeunix.org> References: <4A1EB5A0.7030206@optiksecurite.com> <4A20001E.5000407@optiksecurite.com> <52a241a292d8df1c0970d071267cb865.squirrel@mlaier.homeunix.org> Message-ID: <4A23EF71.4000707@optiksecurite.com> Max Laier a ?crit : > Can you please post your ruleset. I suspect there is something wrong with > it. By the way, I noticed that your are using a 127/8 addresse for your > web server. Are you - by chance - running in a jail of kinds? In that > case you might need "set skip on lo0" to avoid troubles. Depending on the > kind of filtering you are doing this might be complicated, however. > > In any case, we'd need more details about your setup to help. > I'm not too inclined to post my ruleset to the whole list, so I propose to send it only to people interested in it, in a private mail. Thanks a lot Max for your interest in my problem. I'm sending my pf.conf to you in a few moments. Yes, I'm using jails to isolate every services and they are all binded on the loopback interface. I'm using RDR and NAT to make them available from the outside. Martin > Am Fr, 29.05.2009, 17:32, schrieb Martin Turgeon: >> Martin Turgeon a ?crit : >>> Hi list! >>> >>> I had a problem with state mismatch on my DB server that I solved by >>> lowering the tcp.closed timeout. I setted it to 2 instead of 90. >>> >>> I now have what looks like the same problem on the front-end web server. >>> However, when I tried to apply the same fix, I got connection problem >>> with the back-end DB, but the state mismatch disappearred. >>> >>> On the front-end web server, the state mismatch occurs on the external >>> interface, only on port 80. >>> >>> I enabled misc debugging and got this in /var/log/messages on the >>> front-end web server: >>> >>> May 28 05:02:19 francis kernel: pf: BAD state: TCP 127.0.0.25:80 >>> 206.125.166.65:80 98.207.239.10:54737 [lo=820536733 high=820603340 >>> win=65535 modulator=0 wscale=0] [lo=2871317100 high=2871375106 win=8326 >>> modulator=0 wscale=3] 7:4 R seq=820536733 (820536732) ack=2871317100 >>> len=0 ackskew=0 pkts=43:69 dir=in,fwd >>> May 28 05:02:19 francis kernel: pf: State failure on: | >>> May 28 05:02:19 francis kernel: pf: BAD state: TCP 127.0.0.25:80 >>> 206.125.166.65:80 98.207.239.10:54733 [lo=374985971 high=375052578 >>> win=65535 modulator=0 wscale=0] [lo=2999164748 high=2999229169 win=8326 >>> modulator=0 wscale=3] 7:4 R seq=374985971 (374985970) ack=2999164748 >>> len=0 ackskew=0 pkts=40:54 dir=in,fwd >>> May 28 05:02:19 francis kernel: pf: State failure on: | >>> May 28 05:03:06 francis kernel: pf: BAD state: TCP 127.0.0.20:80 >>> 206.125.166.80:80 123.116.84.41:59776 [lo=3407758259 high=3407823796 >>> win=4096 modulator=0 wscale=2] [lo=374200006 high=374216390 win=8192 >>> modulator=0 wscale=3] 4:2 A seq=3407758259 (3407758260) ack=2320196160 >>> len=0 ackskew=-1945996154 pkts=1:1 dir=in,fwd >>> May 28 05:03:06 francis kernel: pf: State failure on: 3 | >>> May 28 05:03:06 francis kernel: pf: BAD state: TCP 127.0.0.20:80 >>> 206.125.166.80:80 123.116.84.41:59776 [lo=3407758259 high=3407823796 >>> win=4096 modulator=0 wscale=2] [lo=374200006 high=374216390 win=8192 >>> modulator=0 wscale=3] 4:2 RA seq=3407758259 (3407758260) ack=2320196160 >>> len=0 ackskew=-1945996154 pkts=1:1 dir=in,fwd >>> >>> This server has been up for 12 days and already got almost 600000 state >>> mismatch! >>> >>> I tried to lower tcp.finwait, no result. I tried to set optimization to >>> aggressive, no result. I tried to disable port randomization via sysctl, >>> no result either. >>> >>> I tcpdumped and there is only a few RST so I don't understand why >>> tcp.closed would solve my problem. If it's a problem with source port >>> reuse, tcp.finwait should be the timeout that would help, not >>> tcp.closed, right? >>> >>> How can a lower tcp.closed on the front-end cause mysql connection >>> problem with the back-end? I tcpdumped while there is a connection >>> problem with the DB and there is nothing that seems wrong, no RST at >>> all! The front-end web server tries to connect to the DB, wait 3 sec and >>> if it fails to establish a connection, it then tries to connect to a >>> read-only backup DB, on another server, which never fails to connect. >>> >>> The only thing I'm sure is that it's the tcp.closed that cause the DB >>> connection problem. As soon as I remove it, the state mismatch comes >>> back on the external interface but there's no DB connection problem >>> anymore. >>> >>> What am I missing? >>> >>> Martin >>> >> I forgot to mention in the starting post what version I'm using: >> >> uname -a on the front-end web server: >> FreeBSD webserver 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 >> 07:18:07 UTC 2009 >> root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> >> uname -a on the back-end MySQL server: >> FreeBSD mysql 7.0-RELEASE-p5 FreeBSD 7.0-RELEASE-p5 #1: Tue Oct 7 >> 09:57:31 EDT 2008 root@martin.ringadmin.com:/usr/obj/usr/src/sys/OPTIK >> amd64 >> >> I read about the port reuse problem when I first experienced it with the >> DB server and I saw that this wasn't going to happen with the new >> release. I were happy to build I new 7.2-Rel server so that I wasn't >> going to face the same problem. >> >> But, in fact, I'm facing what looks like the same problem... >> >> I'm all ears to any pointers/suggestions! >> >> Thanks for your precious help. >> >> Martin >> _______________________________________________ >> 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" >> >> >> !DSPAM:4a200026570535209328925! >> >> > > From dougb at FreeBSD.org Mon Jun 1 19:05:34 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jun 1 19:05:41 2009 Subject: Moving the pf rc.d scripts to run before netif Message-ID: <4A242035.8010101@FreeBSD.org> Howdy, As you can see below, I've made a change to the order of execution of the rc.d scripts in 8-current (soon to be 8-release) to run all of the firewalls, including pf, before the network is up. However the following PR gives an example of why this might be bad: http://www.freebsd.org/cgi/query-pr.cgi?pr=130381 This leaves me with a few questions. 1. When the _kernel_ first starts, what is the condition of the pf firewall? In other words, you have pf in the kernel, and let's pretend that there is no rc.d/pf initialization script. What's going to happen to the packets when the network comes up? 2. The previous rcorder for the pf script was right after netif (the network coming up) and before routing .... why? Is this related to how pf does its work? The reason I ask this question is that in order to fix the IPv6 rcorder problem in the pr the way that Gert is suggesting the "BEFORE: routing" would have to be removed because our IPv6 startup depends on RA which depends on routing being up. (Side note, in the long term I'd like to revise this so that an IPv6-only host and/or a host with statically assigned IPv6 addresses can easily be configured within rc.d, but that's another thing altogether.) 3. Is the need to be able to use $ext_if after the network is up so overwhelmingly important that it justifies running pf after netif? Or is using ($ext_if) a reasonable solution? Anything else y'all would like to add is welcome at this point. Thanks, Doug -------- Original Message -------- Subject: Re: svn commit: r193198 - head/etc/rc.d Date: Mon, 01 Jun 2009 10:38:41 -0700 From: Doug Barton Bjoern A. Zeeb wrote: > On Mon, 1 Jun 2009, Doug Barton wrote: > >> Author: dougb Date: Mon Jun 1 05:35:03 2009 New Revision: 193198 >> URL: http://svn.freebsd.org/changeset/base/193198 >> >> Log: Make the pf and ipfw firewalls start before netif, just like >> ipfilter already does. This eliminates a logical inconsistency, >> and a small window where the system is open after the network >> comes up. > > Unfortunetaly this is contrary to a lot of PRs and requests on > mailing lists out there that actually want the netif/network_ipv6 > to be run _before_ things come up. Can you provide links to some of those PRs? I'd love to learn more about this issue. > Espescially pf really needs this to avoid rules that needs to do > per paket lookups of the interface address. Not sure what you mean here. > Further ipfw has a default option being setaable at compile time > and as TUNABLE to handle this window. And what happens if someone sets the default to accept? You could argue that they are knowingly opening a window of vulnerability but I would argue that the right thing to do is to have the firewall rules loaded before the network comes up regardless of the default. That way you avoid both the potential window of vulnerability AND the window of time between the network being loaded and the firewall allowing access to the box. To give a little more history, this patch was discussed and reviewed a while back and someone told me that they would incorporate it into some overall work they were doing to improve the way that rc.d handles networking, so I stopped paying attention to it. Last night a user pointed out to me that another patch that this same person said they would handle never got in, so I reviewed other outstanding work and found that this one had not been done either. Obviously if this change breaks something it will have to be reverted. However from the security standpoint (primary concern) it would seem to be the right thing to do, and the previous rcorder was not logically consistent in any case. Max Laier wrote: > Can you please add a note about this in UPDATING? Yes. I was on the fence about this anyways, so now you've pushed me over. :) > It might be a slight POLA violation for people who rely on the > interfaces being configured to setup the firewall. For instance > when one doesn't use dynamic address rules in pf i.e. "from/to ifX" > instead of "from/to (ifX)". I don't understand what you've written here. It seems to me that if the interfaces are always the same then the firewall rules will be fine, but if they are using dynamic rules it doesn't matter if it starts before or after the network is up. Doug -- This .signature sanitized for your protection From max at love2party.net Mon Jun 1 19:45:20 2009 From: max at love2party.net (Max Laier) Date: Mon Jun 1 19:45:28 2009 Subject: Moving the pf rc.d scripts to run before netif In-Reply-To: <4A242035.8010101@FreeBSD.org> References: <4A242035.8010101@FreeBSD.org> Message-ID: <200906012145.17315.max@love2party.net> On Monday 01 June 2009 20:38:45 Doug Barton wrote: > Howdy, > > As you can see below, I've made a change to the order of execution of > the rc.d scripts in 8-current (soon to be 8-release) to run all of the > firewalls, including pf, before the network is up. However the > following PR gives an example of why this might be bad: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130381 > > This leaves me with a few questions. > > 1. When the _kernel_ first starts, what is the condition of the pf > firewall? In other words, you have pf in the kernel, and let's pretend > that there is no rc.d/pf initialization script. What's going to happen > to the packets when the network comes up? The default behavior is to pass everything unconditionally. > 2. The previous rcorder for the pf script was right after netif (the > network coming up) and before routing .... why? Is this related to how > pf does its work? The reason I ask this question is that in order to > fix the IPv6 rcorder problem in the pr the way that Gert is suggesting > the "BEFORE: routing" would have to be removed because our IPv6 > startup depends on RA which depends on routing being up. (Side note, > in the long term I'd like to revise this so that an IPv6-only host > and/or a host with statically assigned IPv6 addresses can easily be > configured within rc.d, but that's another thing altogether.) > > 3. Is the need to be able to use $ext_if after the network is up so > overwhelmingly important that it justifies running pf after netif? Or > is using ($ext_if) a reasonable solution? Traditionally pf has had some issues with startup before netif. e.g. it was not possible to configure ALTQ on interfaces before they are created. Over the years most of these restrictions have been fixed (though you still need to specify an absolute bandwidth for ALTQ if you want to configure non-existing interfaces). The last remaining issue with non- existing interfaces is the "set loginterface". In addition people seem to like to use symbolic hostnames in their pf.conf for some reason. It's a bad idea from the security perspective, but who am I to decide how one shoots oneself? Symbolic hostnames, as well as non-dynamic interface statements are evaluated at ruleset load-time in pf. Thus the resolver must work when we load a ruleset with rules like that. > Anything else y'all would like to add is welcome at this point. It might make sense to have the ability for two points to configure the firewall. One "firewall_early" to setup a minimal "block all/allow dhcp/RA/DNS/..." and "firewall_late" to setup the final thing. In any case setting up the firewall is a non-trivial task and I doubt that there really is a good "one size fits all" solution. I'd prefer your version over the previous incarnation - as it is secure by default. -- /"\ 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 aftaha at cirp.usp.br Mon Jun 1 21:11:20 2009 From: aftaha at cirp.usp.br (Ali Faiez Taha) Date: Mon Jun 1 21:11:27 2009 Subject: Connect to port 5432 Message-ID: <4A2415EF.1070206@cirp.usp.br> Dear Sirs. What I need to redirect connections from any Internet valid IP and port 5432 to one intranet server running (PostgreSQL Database) on 5432 port ? I am using FreeBSD 7.2 with PF firewall. The rule on Linux iptables now is: iptables -t nat -A PREROUTING -p tcp -s 0/0 -d AAA.BBB.CCC.DDD --dport 5432 -j DNAT --to-destination 192.168.2.253:5432 thanks a lot From espartano.mail at gmail.com Mon Jun 1 21:17:23 2009 From: espartano.mail at gmail.com (Espartano) Date: Mon Jun 1 21:17:30 2009 Subject: Connect to port 5432 In-Reply-To: <4A2415EF.1070206@cirp.usp.br> References: <4A2415EF.1070206@cirp.usp.br> Message-ID: 2009/6/1 Ali Faiez Taha : > ? ? ? ?Dear Sirs. > > What I need to redirect connections from any Internet valid IP and port 5432 to one intranet server running (PostgreSQL Database) on > 5432 port ? > I am using ?FreeBSD 7.2 with PF firewall. > > The rule on Linux iptables now is: > > iptables -t nat -A PREROUTING -p tcp -s 0/0 -d AAA.BBB.CCC.DDD --dport 5432 -j DNAT --to-destination 192.168.2.253:5432 > > > thanks a lot > Maybe you have to see this page: http://www.openbsd.org/faq/pf/rdr.html -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." Sent from Veracruz, Ver, Mexico From 000.fbsd at quip.cz Mon Jun 1 22:15:30 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Mon Jun 1 22:15:37 2009 Subject: Connect to port 5432 In-Reply-To: <4A2415EF.1070206@cirp.usp.br> References: <4A2415EF.1070206@cirp.usp.br> Message-ID: <4A244E73.8040203@quip.cz> Ali Faiez Taha wrote: > Dear Sirs. > > What I need to redirect connections from any Internet valid IP and port 5432 to one intranet server running (PostgreSQL Database) on > 5432 port ? > I am using FreeBSD 7.2 with PF firewall. > > The rule on Linux iptables now is: > > iptables -t nat -A PREROUTING -p tcp -s 0/0 -d AAA.BBB.CCC.DDD --dport 5432 -j DNAT --to-destination 192.168.2.253:5432 It could be something like this rdr pass on $ext_if proto tcp from any to AAA.BBB.CCC.DDD port 5432 -> 192.168.2.253 but better read some docs (man pf.conf and examples on the net) Miroslav Lachman From dougb at FreeBSD.org Mon Jun 1 22:57:15 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jun 1 22:57:21 2009 Subject: Moving the pf rc.d scripts to run before netif In-Reply-To: <200906012145.17315.max@love2party.net> References: <4A242035.8010101@FreeBSD.org> <200906012145.17315.max@love2party.net> Message-ID: <4A245CC6.7010901@FreeBSD.org> Max Laier wrote: > On Monday 01 June 2009 20:38:45 Doug Barton wrote: >> Howdy, >> >> As you can see below, I've made a change to the order of execution of >> the rc.d scripts in 8-current (soon to be 8-release) to run all of the >> firewalls, including pf, before the network is up. However the >> following PR gives an example of why this might be bad: >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=130381 >> >> This leaves me with a few questions. >> >> 1. When the _kernel_ first starts, what is the condition of the pf >> firewall? In other words, you have pf in the kernel, and let's pretend >> that there is no rc.d/pf initialization script. What's going to happen >> to the packets when the network comes up? > > The default behavior is to pass everything unconditionally. That's what I was afraid of. Traditionally this has been viewed as a Bad Thing(TM) and I'm surprised that it was ever set up that way to start with. >> 2. The previous rcorder for the pf script was right after netif (the >> network coming up) and before routing .... why? Is this related to how >> pf does its work? The reason I ask this question is that in order to >> fix the IPv6 rcorder problem in the pr the way that Gert is suggesting >> the "BEFORE: routing" would have to be removed because our IPv6 >> startup depends on RA which depends on routing being up. (Side note, >> in the long term I'd like to revise this so that an IPv6-only host >> and/or a host with statically assigned IPv6 addresses can easily be >> configured within rc.d, but that's another thing altogether.) >> >> 3. Is the need to be able to use $ext_if after the network is up so >> overwhelmingly important that it justifies running pf after netif? Or >> is using ($ext_if) a reasonable solution? > > Traditionally pf has had some issues with startup before netif. e.g. it > was not possible to configure ALTQ on interfaces before they are created. > Over the years most of these restrictions have been fixed (though you > still need to specify an absolute bandwidth for ALTQ if you want to > configure non-existing interfaces). The last remaining issue with non- > existing interfaces is the "set loginterface". Ok. > In addition people seem to like to use symbolic hostnames in their pf.conf > for some reason. It's a bad idea from the security perspective, but who > am I to decide how one shoots oneself? Symbolic hostnames, as well as > non-dynamic interface statements are evaluated at ruleset load-time in pf. > Thus the resolver must work when we load a ruleset with rules like that. Well the previous order had pf starting before routing anyway (and therefore also starting before IPv6, nsswitch, resolv, named, etc.) so I don't think this would have worked in any case. >> Anything else y'all would like to add is welcome at this point. > > It might make sense to have the ability for two points to configure the > firewall. One "firewall_early" to setup a minimal "block all/allow > dhcp/RA/DNS/..." and "firewall_late" to setup the final thing. I would definitely be supportive of a pf-late script that runs after the network is up. I'll even write the thing if someone can tell me what it needs to have. Would calling "/etc/rc.d/pf reload" do the right thing? And if this is the best way to handle the problem, how late should it start? (IOW, what should it REQUIRE to make sure it will have everything it needs when it is run, and what would it need to run BEFORE to make sure the system is still as secure as possible?) > In any case setting up the firewall is a non-trivial task and I doubt that > there really is a good "one size fits all" solution. I'd prefer your > version over the previous incarnation - as it is secure by default. Thanks for the well-informed response, and the note of support. :) Doug -- This .signature sanitized for your protection From linimon at FreeBSD.org Tue Jun 2 02:30:00 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Tue Jun 2 02:30:08 2009 Subject: kern/135162: [pfsync] pfsync(4) not usable with GENERIC kernel Message-ID: <200906020230.n522U03l031179@freefall.freebsd.org> Old Synopsis: pfsync(4) not usable with GENERIC kernel New Synopsis: [pfsync] pfsync(4) not usable with GENERIC kernel Responsible-Changed-From-To: gnats-admin->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Tue Jun 2 02:28:18 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135162 From repcsike at gmail.com Tue Jun 2 15:13:32 2009 From: repcsike at gmail.com (Kevin Smith) Date: Tue Jun 2 15:13:39 2009 Subject: Problem: nating jails with private ip addresses. Message-ID: Hi guys, Please help if you can, I have a problem, and I can't get my config to work. I have one public ip address, and several jails with private ip addresses in the 172.20.0.0/24 area. I don't know how to make this work, maybe somewhere I blocked the traffic, but dns request are coming through, I can open (redirected)http on the jail itself inside from the internet, but i can't connect to any host on the internet from the jails, the main problem comes with installing from ports and downloading the distfiles. My System is 7.1-RELEASE.with pf,pflog,pfsync devices, and ALTQ,ALTQ_CBQ,ALTQ_RED,ALTQ_RIO,ALTQ_HFSC,ALTQ_PRIQ,ALTQ_NOPCC options compiled in the kernel! Is this possible, or should I pop in another card and bind the jails to that card? The corresponding config is here(really partial): tcp_services = "{ ssh, smtp, domain, www, pop3, auth, https, pop3s, ftp, ftp-data }" ext_if = "bge0" jails = "172.20.0.0/24" nat on $ext_if proto { tcp, udp, icmp } from $jails to any -> ($ext_if) rdr pass on $ext_if inet proto tcp from any to $ext_if port http -> 172.20.0.100 pass out proto tcp to any port $tcp_services keep state pass out proto tcp from any to any keep state Thanks in advance, Best Regards, Kevin From vila at tesla.cujae.edu.cu Sat Jun 6 03:16:42 2009 From: vila at tesla.cujae.edu.cu (vila@tesla.cujae.edu.cu) Date: Sat Jun 6 03:16:50 2009 Subject: Connmark target Message-ID: <20090605225730.wrvm0ae74kco0cws@correo.cujae.edu.cu> Hi folks! I?m trying to figure out if there is a way to make connection marking in a similar way as the iptables?s CONNMARK target does? Does pf supports this feature? My intentions are to tag an outgoing packet, transfer the tag to the hole connection and then use that tag to mark incoming packets belonging to the same connection. Also, i would like then to use that mark to enqueue marked packets to hfsc clases. I?ve done all of this in linux but never on freebsd, I?ve searched in pf?s man page and the FAQ without success. thanks in advance, evelio vila ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y Educaci?n Energ?tica 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energ?tica sustentable www.ciercuba.com From dudu at dudu.ro Sat Jun 6 06:10:33 2009 From: dudu at dudu.ro (Vlad Galu) Date: Sat Jun 6 06:10:39 2009 Subject: Connmark target In-Reply-To: <20090605225730.wrvm0ae74kco0cws@correo.cujae.edu.cu> References: <20090605225730.wrvm0ae74kco0cws@correo.cujae.edu.cu> Message-ID: On Sat, Jun 6, 2009 at 5:57 AM, wrote: > Hi folks! > > I?m trying to figure out if there is a way to make connection marking in a > similar way as the iptables?s CONNMARK target does? > > Does pf supports this feature? > > My intentions are to tag an outgoing packet, transfer the tag to the hole > connection and then use that tag to mark incoming packets belonging to the > same connection. > > Also, i would like then to use that mark to enqueue marked packets to hfsc > clases. > > I?ve done all of this in linux but never on freebsd, I?ve searched in pf?s > man page and the FAQ without success. > > thanks in advance, > > evelio vila Hi evelio, see below: -- cut here -- tag Packets matching this rule will be tagged with the specified string. The tag acts as an internal marker that can be used to identify these packets later on. This can be used, for example, to provide trust between interfaces and to determine if packets have been processed by translation rules. Tags are "sticky", meaning that the packet will be tagged even if the rule is not the last matching rule. Further matching rules can replace the tag with a new one but will not remove a previously applied tag. A packet is only ever assigned one tag at a time. Packet tagging can be done during nat, rdr, or binat rules in addition to filter rules. Tags take the same macros as labels (see above). tagged Used with filter or translation rules to specify that packets must already be tagged with the given tag in order to match the rule. Inverse tag matching can also be done by specifying the ! operator before the tagged keyword. -- and here -- Anyway, I believe that keeping state for the desired outgoing connections should be enough all by itself. You would simply add the "queue " directive at the end of your pass out rule, even though the interface packets go out through is the "external" one, and you want to do shaping on the "internal" one but, as I understand, for that you also need floating (not if-bound) states. If I'm wrong, I'd like somebody with better pf knowledge to correct me :) From vila at tesla.cujae.edu.cu Sat Jun 6 16:49:59 2009 From: vila at tesla.cujae.edu.cu (vila@tesla.cujae.edu.cu) Date: Sat Jun 6 16:50:08 2009 Subject: Connmark target Message-ID: <20090606124949.japda2vrkck4wk8o@correo.cujae.edu.cu> Vlad Galu ha escrito: > On Sat, Jun 6, 2009 at 5:57 AM, wrote: >> Hi folks! >> >> I?m trying to figure out if there is a way to make connection marking in a >> similar way as the iptables?s CONNMARK target does? >> >> Does pf supports this feature? >> >> My intentions are to tag an outgoing packet, transfer the tag to the hole >> connection and then use that tag to mark incoming packets belonging to the >> same connection. >> >> Also, i would like then to use that mark to enqueue marked packets to hfsc >> clases. >> >> I?ve done all of this in linux but never on freebsd, I?ve searched in pf?s >> man page and the FAQ without success. >> >> thanks in advance, >> >> evelio vila > > Hi evelio, see below: > -- cut here -- > tag > Packets matching this rule will be tagged with the specified > string. The tag acts as an internal marker that can be used to > identify these packets later on. This can be used, for > example, to > provide trust between interfaces and to determine if packets have > been processed by translation rules. Tags are "sticky", meaning > that the packet will be tagged even if the rule is not the last > matching rule. Further matching rules can replace the tag with a > new one but will not remove a previously applied tag. A packet is > only ever assigned one tag at a time. Packet tagging can be done > during nat, rdr, or binat rules in addition to filter rules. Tags > take the same macros as labels (see above). > > tagged > Used with filter or translation rules to specify that packets must > already be tagged with the given tag in order to match the rule. > Inverse tag matching can also be done by specifying the ! operator > before the tagged keyword. > -- and here -- > > Anyway, I believe that keeping state for the desired outgoing > connections should be enough all by itself. You would simply add the Indeed no, what i want is also to mark the connection to be able then to mark incoming packets beloging to the same connection. > "queue " directive at the end of your pass out rule, even > though the interface packets go out through is the "external" one, and > you want to do shaping on the "internal" one but, as I understand, for > that you also need floating (not if-bound) states. If I'm wrong, I'd i am not sure what you mean with "floating (not if-bound) states" could you please explain this. > like somebody with better pf knowledge to correct me :) > thanks for your quick answer vlad. evelio vila ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y Educaci?n Energ?tica 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energ?tica sustentable www.ciercuba.com From eri at freebsd.org Sat Jun 6 16:55:47 2009 From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Sat Jun 6 16:55:53 2009 Subject: Connmark target In-Reply-To: <20090606124949.japda2vrkck4wk8o@correo.cujae.edu.cu> References: <20090606124949.japda2vrkck4wk8o@correo.cujae.edu.cu> Message-ID: <9a542da30906060955i4a1097bcpad5fd78587d7e169@mail.gmail.com> On Sat, Jun 6, 2009 at 6:49 PM, wrote: > Vlad Galu ha escrito: > >> On Sat, Jun 6, 2009 at 5:57 AM, wrote: >>> >>> Hi folks! >>> >>> I?m trying to figure out if there is a way to make connection marking in >>> a >>> similar way as the iptables?s CONNMARK target does? >>> >>> Does pf supports this feature? >>> >>> My intentions are to tag an outgoing packet, transfer the tag to the hole >>> connection and then use that tag to mark incoming packets belonging to >>> the >>> same connection. >>> >>> Also, i would like then to use that mark to enqueue marked packets to >>> hfsc >>> clases. >>> >>> I?ve done all of this in linux but never on freebsd, I?ve searched in >>> pf?s >>> man page and the FAQ without success. >>> >>> thanks in advance, >>> >>> evelio vila >> >> ? Hi evelio, see below: >> -- cut here -- >> ? ? tag >> ? ? ? ? ? Packets matching this rule will be tagged with the specified >> ? ? ? ? ? string. ?The tag acts as an internal marker that can be used to >> ? ? ? ? ? identify these packets later on. ?This can be used, for >> example, to >> ? ? ? ? ? provide trust between interfaces and to determine if packets >> have >> ? ? ? ? ? been processed by translation rules. ?Tags are "sticky", meaning >> ? ? ? ? ? that the packet will be tagged even if the rule is not the last >> ? ? ? ? ? matching rule. ?Further matching rules can replace the tag with >> a >> ? ? ? ? ? new one but will not remove a previously applied tag. ?A packet >> is >> ? ? ? ? ? only ever assigned one tag at a time. ?Packet tagging can be >> done >> ? ? ? ? ? during nat, rdr, or binat rules in addition to filter rules. >> ?Tags >> ? ? ? ? ? take the same macros as labels (see above). >> >> ? ? tagged >> ? ? ? ? ? Used with filter or translation rules to specify that packets >> must >> ? ? ? ? ? already be tagged with the given tag in order to match the rule. >> ? ? ? ? ? Inverse tag matching can also be done by specifying the ! >> operator >> ? ? ? ? ? before the tagged keyword. >> -- and here -- >> >> ?Anyway, I believe that keeping state for the desired outgoing >> connections should be enough all by itself. You would simply add the > > Indeed no, ?what i want is also to mark the connection to be able then > to mark incoming packets beloging to the same connection. > >> "queue " directive at the end of your pass out rule, even >> though the interface packets go out through is the "external" one, and >> you want to do shaping on the "internal" one but, as I understand, for >> that you also need floating (not if-bound) states. If I'm wrong, I'd > > i am not sure what you mean with "floating (not if-bound) states" > could you please explain this. >> >> like somebody with better pf knowledge to correct me :) pf(4) is not iptables. So before using it read more about it. http://home.nuug.no/~peter/pf/en/ http://www.openbsd.org/faq/pf > thanks for your quick answer vlad. > > evelio vila > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y > Educaci?n Energ?tica > 9 - 12 de Junio 2009, Palacio de las Convenciones > ...Por una cultura energ?tica sustentable > www.ciercuba.com_______________________________________________ > 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" > -- Ermal From vila at tesla.cujae.edu.cu Sat Jun 6 17:15:52 2009 From: vila at tesla.cujae.edu.cu (vila@tesla.cujae.edu.cu) Date: Sat Jun 6 17:16:00 2009 Subject: Connmark target In-Reply-To: <9a542da30906060955i4a1097bcpad5fd78587d7e169@mail.gmail.com> References: <20090606124949.japda2vrkck4wk8o@correo.cujae.edu.cu> <9a542da30906060955i4a1097bcpad5fd78587d7e169@mail.gmail.com> Message-ID: <20090606131545.kk8k1qf7a8oc4os8@correo.cujae.edu.cu> Ermal Lu?i ha escrito: > On Sat, Jun 6, 2009 at 6:49 PM, wrote: >> Vlad Galu ha escrito: >> >>> On Sat, Jun 6, 2009 at 5:57 AM, wrote: >>>> >>>> Hi folks! >>>> >>>> I?m trying to figure out if there is a way to make connection marking in >>>> a >>>> similar way as the iptables?s CONNMARK target does? >>>> >>>> Does pf supports this feature? >>>> >>>> My intentions are to tag an outgoing packet, transfer the tag to the hole >>>> connection and then use that tag to mark incoming packets belonging to >>>> the >>>> same connection. >>>> >>>> Also, i would like then to use that mark to enqueue marked packets to >>>> hfsc >>>> clases. >>>> >>>> I?ve done all of this in linux but never on freebsd, I?ve searched in >>>> pf?s >>>> man page and the FAQ without success. >>>> >>>> thanks in advance, >>>> >>>> evelio vila >>> >>> ? Hi evelio, see below: >>> -- cut here -- >>> ? ? tag >>> ? ? ? ? ? Packets matching this rule will be tagged with the specified >>> ? ? ? ? ? string. ?The tag acts as an internal marker that can be used to >>> ? ? ? ? ? identify these packets later on. ?This can be used, for >>> example, to >>> ? ? ? ? ? provide trust between interfaces and to determine if packets >>> have >>> ? ? ? ? ? been processed by translation rules. ?Tags are "sticky", meaning >>> ? ? ? ? ? that the packet will be tagged even if the rule is not the last >>> ? ? ? ? ? matching rule. ?Further matching rules can replace the tag with >>> a >>> ? ? ? ? ? new one but will not remove a previously applied tag. ?A packet >>> is >>> ? ? ? ? ? only ever assigned one tag at a time. ?Packet tagging can be >>> done >>> ? ? ? ? ? during nat, rdr, or binat rules in addition to filter rules. >>> ?Tags >>> ? ? ? ? ? take the same macros as labels (see above). >>> >>> ? ? tagged >>> ? ? ? ? ? Used with filter or translation rules to specify that packets >>> must >>> ? ? ? ? ? already be tagged with the given tag in order to match the rule. >>> ? ? ? ? ? Inverse tag matching can also be done by specifying the ! >>> operator >>> ? ? ? ? ? before the tagged keyword. >>> -- and here -- >>> >>> ?Anyway, I believe that keeping state for the desired outgoing >>> connections should be enough all by itself. You would simply add the >> >> Indeed no, ?what i want is also to mark the connection to be able then >> to mark incoming packets beloging to the same connection. >> >>> "queue " directive at the end of your pass out rule, even >>> though the interface packets go out through is the "external" one, and >>> you want to do shaping on the "internal" one but, as I understand, for >>> that you also need floating (not if-bound) states. If I'm wrong, I'd >> >> i am not sure what you mean with "floating (not if-bound) states" >> could you please explain this. >>> >>> like somebody with better pf knowledge to correct me :) > > pf(4) is not iptables. So before using it read more about it. > I?m aware of that. I think its pretty obvius that my post is simply trying to figure out how to achieve with pf something that i use to do with netfilter. I?ve read this before but nothing comes up to me. http://www.openbsd.org/faq/pf/tagging.html thanks anyway ermal regards, evelio vila > http://home.nuug.no/~peter/pf/en/ > http://www.openbsd.org/faq/pf > > > >> thanks for your quick answer vlad. >> >> evelio vila >> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >> Educaci?n Energ?tica >> 9 - 12 de Junio 2009, Palacio de las Convenciones >> ...Por una cultura energ?tica sustentable >> www.ciercuba.com_______________________________________________ >> 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" >> > > > > -- > Ermal > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y Educaci?n Energ?tica 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energ?tica sustentable www.ciercuba.com From vila at tesla.cujae.edu.cu Sat Jun 6 17:52:58 2009 From: vila at tesla.cujae.edu.cu (vila@tesla.cujae.edu.cu) Date: Sat Jun 6 17:53:10 2009 Subject: Connmark target In-Reply-To: References: <20090606124949.japda2vrkck4wk8o@correo.cujae.edu.cu> <9a542da30906060955i4a1097bcpad5fd78587d7e169@mail.gmail.com> <20090606131545.kk8k1qf7a8oc4os8@correo.cujae.edu.cu> Message-ID: <20090606135250.3n87bzp88wc4kgk8@correo.cujae.edu.cu> Istv?n ha escrito: > Hi! > > In general it is a very bad idea to use the same way what you have been > using before when you are moving to a new platform. You wouldn't use bash to > manage win2k8 servers, just to give you an example what I am talking about. > > The question is: > > What do you want to do with pf. Forget about netfilter/conntrack and so on. > What do you want to achieve? > > This is the only question. > > > Regards, > Istvan I believe you are righ istvan! this is the thing: I want to make some traffic shapping on both interfaces of a freebsd box. As u all probably know the real congestion occurs generally on the downlink interface because of the asymmetric nature of some protocols (eg. http) on the internal network i have some applications that puts dscp tags to packets according to different classes of service. the uplink shapping can be done simply by mathing the corresponding dscp field of each connection and sending to different queues. (by the way the doc i?ve read only presents TOS mathing and nothing about dscp).. anyway , the problem arises when the incoming traffic (from the internet) has no dscp tags and i need to enqueue then accordingly to make the downlink traffic shapping. regards, evelio vila > > > > On Sat, Jun 6, 2009 at 6:15 PM, wrote: > >> Ermal Lu?i ha escrito: >> >> >> On Sat, Jun 6, 2009 at 6:49 PM, wrote: >>> >>>> Vlad Galu ha escrito: >>>> >>>> On Sat, Jun 6, 2009 at 5:57 AM, wrote: >>>>> >>>>>> >>>>>> Hi folks! >>>>>> >>>>>> I?m trying to figure out if there is a way to make connection marking >>>>>> in >>>>>> a >>>>>> similar way as the iptables?s CONNMARK target does? >>>>>> >>>>>> Does pf supports this feature? >>>>>> >>>>>> My intentions are to tag an outgoing packet, transfer the tag to the >>>>>> hole >>>>>> connection and then use that tag to mark incoming packets belonging to >>>>>> the >>>>>> same connection. >>>>>> >>>>>> Also, i would like then to use that mark to enqueue marked packets to >>>>>> hfsc >>>>>> clases. >>>>>> >>>>>> I?ve done all of this in linux but never on freebsd, I?ve searched in >>>>>> pf?s >>>>>> man page and the FAQ without success. >>>>>> >>>>>> thanks in advance, >>>>>> >>>>>> evelio vila >>>>>> >>>>> >>>>> Hi evelio, see below: >>>>> -- cut here -- >>>>> tag >>>>> Packets matching this rule will be tagged with the specified >>>>> string. The tag acts as an internal marker that can be used >>>>> to >>>>> identify these packets later on. This can be used, for >>>>> example, to >>>>> provide trust between interfaces and to determine if packets >>>>> have >>>>> been processed by translation rules. Tags are "sticky", >>>>> meaning >>>>> that the packet will be tagged even if the rule is not the >>>>> last >>>>> matching rule. Further matching rules can replace the tag >>>>> with >>>>> a >>>>> new one but will not remove a previously applied tag. A >>>>> packet >>>>> is >>>>> only ever assigned one tag at a time. Packet tagging can be >>>>> done >>>>> during nat, rdr, or binat rules in addition to filter rules. >>>>> Tags >>>>> take the same macros as labels (see above). >>>>> >>>>> tagged >>>>> Used with filter or translation rules to specify that packets >>>>> must >>>>> already be tagged with the given tag in order to match the >>>>> rule. >>>>> Inverse tag matching can also be done by specifying the ! >>>>> operator >>>>> before the tagged keyword. >>>>> -- and here -- >>>>> >>>>> Anyway, I believe that keeping state for the desired outgoing >>>>> connections should be enough all by itself. You would simply add the >>>>> >>>> >>>> Indeed no, what i want is also to mark the connection to be able then >>>> to mark incoming packets beloging to the same connection. >>>> >>>> "queue " directive at the end of your pass out rule, even >>>>> though the interface packets go out through is the "external" one, and >>>>> you want to do shaping on the "internal" one but, as I understand, for >>>>> that you also need floating (not if-bound) states. If I'm wrong, I'd >>>>> >>>> >>>> i am not sure what you mean with "floating (not if-bound) states" >>>> could you please explain this. >>>> >>>>> >>>>> like somebody with better pf knowledge to correct me :) >>>>> >>>> >>> pf(4) is not iptables. So before using it read more about it. >>> >>> >> I?m aware of that. >> >> I think its pretty obvius that my post is simply trying to figure out how >> to achieve with pf something that i use to do with netfilter. >> >> I?ve read this before but nothing comes up to me. >> http://www.openbsd.org/faq/pf/tagging.html >> >> >> thanks anyway ermal >> regards, >> evelio vila >> >> >> http://home.nuug.no/~peter/pf/en/ >>> http://www.openbsd.org/faq/pf >>> >>> >>> >>> thanks for your quick answer vlad. >>>> >>>> evelio vila >>>> >>>> >>>> >>>> ---------------------------------------------------------------- >>>> This message was sent using IMP, the Internet Messaging Program. >>>> >>>> >>>> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >>>> Educaci?n Energ?tica >>>> 9 - 12 de Junio 2009, Palacio de las Convenciones >>>> ...Por una cultura energ?tica sustentable >>>> www.ciercuba.com_______________________________________________ >>>> 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" >>>> >>>> >>> >>> >>> -- >>> Ermal >>> >>> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >> Educaci?n Energ?tica >> 9 - 12 de Junio 2009, Palacio de las Convenciones >> ...Por una cultura energ?tica sustentable >> www.ciercuba.com_______________________________________________ >> freebsd-pf@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >> > > > > -- > the sun shines for all > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y Educaci?n Energ?tica 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energ?tica sustentable www.ciercuba.com From vila at tesla.cujae.edu.cu Sat Jun 6 18:29:48 2009 From: vila at tesla.cujae.edu.cu (vila@tesla.cujae.edu.cu) Date: Sat Jun 6 18:29:54 2009 Subject: Connmark target In-Reply-To: References: <20090606124949.japda2vrkck4wk8o@correo.cujae.edu.cu> <9a542da30906060955i4a1097bcpad5fd78587d7e169@mail.gmail.com> <20090606131545.kk8k1qf7a8oc4os8@correo.cujae.edu.cu> <20090606135250.3n87bzp88wc4kgk8@correo.cujae.edu.cu> Message-ID: <20090606142940.0c42ju9uswkg4w8s@correo.cujae.edu.cu> unfortunately that would not help me because the whole traffic is all originated from a single IP address (proxy) so i can not distinguish between them (that is why i use dscp marks) even if i could achieved this, there is still the issue about selecting incoming packets accordingly and direct them to inbound queues (for downlink traffic shapping). regards, evelio vila Istv?n ha escrito: > I guess you might want to tag that dscp enabled packets -because pf has no > support for that at the moment, at least i cannot see- and put them into the > queue based on the tag. > http://www.openbsd.org/faq/pf/queueing.html#assign > > > Regards, > Istvan > > On Sat, Jun 6, 2009 at 6:52 PM, wrote: > >> Istv?n ha escrito: >> >> Hi! >>> >>> In general it is a very bad idea to use the same way what you have been >>> using before when you are moving to a new platform. You wouldn't use bash >>> to >>> manage win2k8 servers, just to give you an example what I am talking >>> about. >>> >>> The question is: >>> >>> What do you want to do with pf. Forget about netfilter/conntrack and so >>> on. >>> What do you want to achieve? >>> >>> This is the only question. >>> >>> >>> Regards, >>> Istvan >>> >> >> I believe you are righ istvan! >> >> this is the thing: >> >> I want to make some traffic shapping on both interfaces of a freebsd box. >> As u all probably know the real congestion occurs generally on the downlink >> interface because of the asymmetric nature of some protocols (eg. http) >> >> on the internal network i have some applications that puts dscp tags to >> packets according to different classes of service. the uplink shapping can >> be done simply by mathing the corresponding dscp field of each connection >> and sending to different queues. (by the way the doc i?ve read only presents >> TOS mathing and nothing about dscp).. >> anyway , the problem arises when the incoming traffic (from the internet) >> has no dscp tags and i need to enqueue then accordingly to make the downlink >> traffic shapping. >> >> regards, >> evelio vila >> >> >> >> >> >>> >>> >>> On Sat, Jun 6, 2009 at 6:15 PM, wrote: >>> >>> Ermal Lu?i ha escrito: >>>> >>>> >>>> On Sat, Jun 6, 2009 at 6:49 PM, wrote: >>>> >>>>> >>>>> Vlad Galu ha escrito: >>>>>> >>>>>> On Sat, Jun 6, 2009 at 5:57 AM, wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi folks! >>>>>>>> >>>>>>>> I?m trying to figure out if there is a way to make connection marking >>>>>>>> in >>>>>>>> a >>>>>>>> similar way as the iptables?s CONNMARK target does? >>>>>>>> >>>>>>>> Does pf supports this feature? >>>>>>>> >>>>>>>> My intentions are to tag an outgoing packet, transfer the tag to the >>>>>>>> hole >>>>>>>> connection and then use that tag to mark incoming packets belonging >>>>>>>> to >>>>>>>> the >>>>>>>> same connection. >>>>>>>> >>>>>>>> Also, i would like then to use that mark to enqueue marked packets to >>>>>>>> hfsc >>>>>>>> clases. >>>>>>>> >>>>>>>> I?ve done all of this in linux but never on freebsd, I?ve searched in >>>>>>>> pf?s >>>>>>>> man page and the FAQ without success. >>>>>>>> >>>>>>>> thanks in advance, >>>>>>>> >>>>>>>> evelio vila >>>>>>>> >>>>>>>> >>>>>>> Hi evelio, see below: >>>>>>> -- cut here -- >>>>>>> tag >>>>>>> Packets matching this rule will be tagged with the specified >>>>>>> string. The tag acts as an internal marker that can be used >>>>>>> to >>>>>>> identify these packets later on. This can be used, for >>>>>>> example, to >>>>>>> provide trust between interfaces and to determine if packets >>>>>>> have >>>>>>> been processed by translation rules. Tags are "sticky", >>>>>>> meaning >>>>>>> that the packet will be tagged even if the rule is not the >>>>>>> last >>>>>>> matching rule. Further matching rules can replace the tag >>>>>>> with >>>>>>> a >>>>>>> new one but will not remove a previously applied tag. A >>>>>>> packet >>>>>>> is >>>>>>> only ever assigned one tag at a time. Packet tagging can be >>>>>>> done >>>>>>> during nat, rdr, or binat rules in addition to filter rules. >>>>>>> Tags >>>>>>> take the same macros as labels (see above). >>>>>>> >>>>>>> tagged >>>>>>> Used with filter or translation rules to specify that packets >>>>>>> must >>>>>>> already be tagged with the given tag in order to match the >>>>>>> rule. >>>>>>> Inverse tag matching can also be done by specifying the ! >>>>>>> operator >>>>>>> before the tagged keyword. >>>>>>> -- and here -- >>>>>>> >>>>>>> Anyway, I believe that keeping state for the desired outgoing >>>>>>> connections should be enough all by itself. You would simply add the >>>>>>> >>>>>>> >>>>>> Indeed no, what i want is also to mark the connection to be able then >>>>>> to mark incoming packets beloging to the same connection. >>>>>> >>>>>> "queue " directive at the end of your pass out rule, even >>>>>> >>>>>>> though the interface packets go out through is the "external" one, and >>>>>>> you want to do shaping on the "internal" one but, as I understand, for >>>>>>> that you also need floating (not if-bound) states. If I'm wrong, I'd >>>>>>> >>>>>>> >>>>>> i am not sure what you mean with "floating (not if-bound) states" >>>>>> could you please explain this. >>>>>> >>>>>> >>>>>>> like somebody with better pf knowledge to correct me :) >>>>>>> >>>>>>> >>>>>> pf(4) is not iptables. So before using it read more about it. >>>>> >>>>> >>>>> I?m aware of that. >>>> >>>> I think its pretty obvius that my post is simply trying to figure out how >>>> to achieve with pf something that i use to do with netfilter. >>>> >>>> I?ve read this before but nothing comes up to me. >>>> http://www.openbsd.org/faq/pf/tagging.html >>>> >>>> >>>> thanks anyway ermal >>>> regards, >>>> evelio vila >>>> >>>> >>>> http://home.nuug.no/~peter/pf/en/ >>>> >>>>> http://www.openbsd.org/faq/pf >>>>> >>>>> >>>>> >>>>> thanks for your quick answer vlad. >>>>> >>>>>> >>>>>> evelio vila >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------- >>>>>> This message was sent using IMP, the Internet Messaging Program. >>>>>> >>>>>> >>>>>> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >>>>>> Educaci?n Energ?tica >>>>>> 9 - 12 de Junio 2009, Palacio de las Convenciones >>>>>> ...Por una cultura energ?tica sustentable >>>>>> www.ciercuba.com_______________________________________________ >>>>>> 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" >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Ermal >>>>> >>>>> >>>>> >>>> >>>> ---------------------------------------------------------------- >>>> This message was sent using IMP, the Internet Messaging Program. >>>> >>>> >>>> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >>>> Educaci?n Energ?tica >>>> 9 - 12 de Junio 2009, Palacio de las Convenciones >>>> ...Por una cultura energ?tica sustentable >>>> www.ciercuba.com_______________________________________________ >>>> freebsd-pf@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >>>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >>>> >>>> >>> >>> >>> -- >>> the sun shines for all >>> >>> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >> Educaci?n Energ?tica >> 9 - 12 de Junio 2009, Palacio de las Convenciones >> ...Por una cultura energ?tica sustentable >> www.ciercuba.com >> > > > > -- > the sun shines for all > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y Educaci?n Energ?tica 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energ?tica sustentable www.ciercuba.com From leccine at gmail.com Sat Jun 6 18:43:33 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Sat Jun 6 18:43:40 2009 Subject: Connmark target In-Reply-To: <20090606135250.3n87bzp88wc4kgk8@correo.cujae.edu.cu> References: <20090606124949.japda2vrkck4wk8o@correo.cujae.edu.cu> <9a542da30906060955i4a1097bcpad5fd78587d7e169@mail.gmail.com> <20090606131545.kk8k1qf7a8oc4os8@correo.cujae.edu.cu> <20090606135250.3n87bzp88wc4kgk8@correo.cujae.edu.cu> Message-ID: I guess you might want to tag that dscp enabled packets -because pf has no support for that at the moment, at least i cannot see- and put them into the queue based on the tag. http://www.openbsd.org/faq/pf/queueing.html#assign Regards, Istvan On Sat, Jun 6, 2009 at 6:52 PM, wrote: > Istv?n ha escrito: > > Hi! >> >> In general it is a very bad idea to use the same way what you have been >> using before when you are moving to a new platform. You wouldn't use bash >> to >> manage win2k8 servers, just to give you an example what I am talking >> about. >> >> The question is: >> >> What do you want to do with pf. Forget about netfilter/conntrack and so >> on. >> What do you want to achieve? >> >> This is the only question. >> >> >> Regards, >> Istvan >> > > I believe you are righ istvan! > > this is the thing: > > I want to make some traffic shapping on both interfaces of a freebsd box. > As u all probably know the real congestion occurs generally on the downlink > interface because of the asymmetric nature of some protocols (eg. http) > > on the internal network i have some applications that puts dscp tags to > packets according to different classes of service. the uplink shapping can > be done simply by mathing the corresponding dscp field of each connection > and sending to different queues. (by the way the doc i?ve read only presents > TOS mathing and nothing about dscp).. > anyway , the problem arises when the incoming traffic (from the internet) > has no dscp tags and i need to enqueue then accordingly to make the downlink > traffic shapping. > > regards, > evelio vila > > > > > >> >> >> On Sat, Jun 6, 2009 at 6:15 PM, wrote: >> >> Ermal Lu?i ha escrito: >>> >>> >>> On Sat, Jun 6, 2009 at 6:49 PM, wrote: >>> >>>> >>>> Vlad Galu ha escrito: >>>>> >>>>> On Sat, Jun 6, 2009 at 5:57 AM, wrote: >>>>> >>>>>> >>>>>> >>>>>>> Hi folks! >>>>>>> >>>>>>> I?m trying to figure out if there is a way to make connection marking >>>>>>> in >>>>>>> a >>>>>>> similar way as the iptables?s CONNMARK target does? >>>>>>> >>>>>>> Does pf supports this feature? >>>>>>> >>>>>>> My intentions are to tag an outgoing packet, transfer the tag to the >>>>>>> hole >>>>>>> connection and then use that tag to mark incoming packets belonging >>>>>>> to >>>>>>> the >>>>>>> same connection. >>>>>>> >>>>>>> Also, i would like then to use that mark to enqueue marked packets to >>>>>>> hfsc >>>>>>> clases. >>>>>>> >>>>>>> I?ve done all of this in linux but never on freebsd, I?ve searched in >>>>>>> pf?s >>>>>>> man page and the FAQ without success. >>>>>>> >>>>>>> thanks in advance, >>>>>>> >>>>>>> evelio vila >>>>>>> >>>>>>> >>>>>> Hi evelio, see below: >>>>>> -- cut here -- >>>>>> tag >>>>>> Packets matching this rule will be tagged with the specified >>>>>> string. The tag acts as an internal marker that can be used >>>>>> to >>>>>> identify these packets later on. This can be used, for >>>>>> example, to >>>>>> provide trust between interfaces and to determine if packets >>>>>> have >>>>>> been processed by translation rules. Tags are "sticky", >>>>>> meaning >>>>>> that the packet will be tagged even if the rule is not the >>>>>> last >>>>>> matching rule. Further matching rules can replace the tag >>>>>> with >>>>>> a >>>>>> new one but will not remove a previously applied tag. A >>>>>> packet >>>>>> is >>>>>> only ever assigned one tag at a time. Packet tagging can be >>>>>> done >>>>>> during nat, rdr, or binat rules in addition to filter rules. >>>>>> Tags >>>>>> take the same macros as labels (see above). >>>>>> >>>>>> tagged >>>>>> Used with filter or translation rules to specify that packets >>>>>> must >>>>>> already be tagged with the given tag in order to match the >>>>>> rule. >>>>>> Inverse tag matching can also be done by specifying the ! >>>>>> operator >>>>>> before the tagged keyword. >>>>>> -- and here -- >>>>>> >>>>>> Anyway, I believe that keeping state for the desired outgoing >>>>>> connections should be enough all by itself. You would simply add the >>>>>> >>>>>> >>>>> Indeed no, what i want is also to mark the connection to be able then >>>>> to mark incoming packets beloging to the same connection. >>>>> >>>>> "queue " directive at the end of your pass out rule, even >>>>> >>>>>> though the interface packets go out through is the "external" one, and >>>>>> you want to do shaping on the "internal" one but, as I understand, for >>>>>> that you also need floating (not if-bound) states. If I'm wrong, I'd >>>>>> >>>>>> >>>>> i am not sure what you mean with "floating (not if-bound) states" >>>>> could you please explain this. >>>>> >>>>> >>>>>> like somebody with better pf knowledge to correct me :) >>>>>> >>>>>> >>>>> pf(4) is not iptables. So before using it read more about it. >>>> >>>> >>>> I?m aware of that. >>> >>> I think its pretty obvius that my post is simply trying to figure out how >>> to achieve with pf something that i use to do with netfilter. >>> >>> I?ve read this before but nothing comes up to me. >>> http://www.openbsd.org/faq/pf/tagging.html >>> >>> >>> thanks anyway ermal >>> regards, >>> evelio vila >>> >>> >>> http://home.nuug.no/~peter/pf/en/ >>> >>>> http://www.openbsd.org/faq/pf >>>> >>>> >>>> >>>> thanks for your quick answer vlad. >>>> >>>>> >>>>> evelio vila >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------- >>>>> This message was sent using IMP, the Internet Messaging Program. >>>>> >>>>> >>>>> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >>>>> Educaci?n Energ?tica >>>>> 9 - 12 de Junio 2009, Palacio de las Convenciones >>>>> ...Por una cultura energ?tica sustentable >>>>> www.ciercuba.com_______________________________________________ >>>>> 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" >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Ermal >>>> >>>> >>>> >>> >>> ---------------------------------------------------------------- >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> >>> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >>> Educaci?n Energ?tica >>> 9 - 12 de Junio 2009, Palacio de las Convenciones >>> ...Por una cultura energ?tica sustentable >>> www.ciercuba.com_______________________________________________ >>> freebsd-pf@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >>> >>> >> >> >> -- >> the sun shines for all >> >> > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y > Educaci?n Energ?tica > 9 - 12 de Junio 2009, Palacio de las Convenciones > ...Por una cultura energ?tica sustentable > www.ciercuba.com > -- the sun shines for all From vila at tesla.cujae.edu.cu Sun Jun 7 17:28:12 2009 From: vila at tesla.cujae.edu.cu (vila@tesla.cujae.edu.cu) Date: Sun Jun 7 17:28:21 2009 Subject: Connmark target In-Reply-To: References: <20090606124949.japda2vrkck4wk8o@correo.cujae.edu.cu> <9a542da30906060955i4a1097bcpad5fd78587d7e169@mail.gmail.com> <20090606131545.kk8k1qf7a8oc4os8@correo.cujae.edu.cu> <20090606135250.3n87bzp88wc4kgk8@correo.cujae.edu.cu> <20090606142940.0c42ju9uswkg4w8s@correo.cujae.edu.cu> Message-ID: <20090607132751.18wu3idnkgcgkss8@correo.cujae.edu.cu> Ok istvan, i?ll try this and post results. by the way, anyone knows if there are plans to include connection mark capabilities to pf. i say this because until now is the only way i?ve found to solve my issue. if anybody knows another way to achieve the same goals, help is really apriciated. thanks everyone, evelio vila Istv?n ha escrito: > Then we have to investigate the possibility to use those flags ;) > http://groups.google.com/group/bit.listserv.openbsd-pf/browse_thread/thread/dd04e046f70e8ebc# > > > Regards, > Istvan > > On Sat, Jun 6, 2009 at 7:29 PM, wrote: > >> unfortunately that would not help me because the whole traffic is all >> originated from a single IP address (proxy) so i can not distinguish between >> them (that is why i use dscp marks) >> even if i could achieved this, there is still the issue about selecting >> incoming packets accordingly and direct them to inbound queues (for >> downlink traffic shapping). >> >> regards, >> evelio vila >> >> >> Istv?n ha escrito: >> >> I guess you might want to tag that dscp enabled packets -because pf has no >>> support for that at the moment, at least i cannot see- and put them into >>> the >>> queue based on the tag. >>> http://www.openbsd.org/faq/pf/queueing.html#assign >>> >>> >>> Regards, >>> Istvan >>> >>> On Sat, Jun 6, 2009 at 6:52 PM, wrote: >>> >>> Istv?n ha escrito: >>>> >>>> Hi! >>>> >>>>> >>>>> In general it is a very bad idea to use the same way what you have been >>>>> using before when you are moving to a new platform. You wouldn't use >>>>> bash >>>>> to >>>>> manage win2k8 servers, just to give you an example what I am talking >>>>> about. >>>>> >>>>> The question is: >>>>> >>>>> What do you want to do with pf. Forget about netfilter/conntrack and so >>>>> on. >>>>> What do you want to achieve? >>>>> >>>>> This is the only question. >>>>> >>>>> >>>>> Regards, >>>>> Istvan >>>>> >>>>> >>>> I believe you are righ istvan! >>>> >>>> this is the thing: >>>> >>>> I want to make some traffic shapping on both interfaces of a freebsd box. >>>> As u all probably know the real congestion occurs generally on the >>>> downlink >>>> interface because of the asymmetric nature of some protocols (eg. http) >>>> >>>> on the internal network i have some applications that puts dscp tags to >>>> packets according to different classes of service. the uplink shapping >>>> can >>>> be done simply by mathing the corresponding dscp field of each connection >>>> and sending to different queues. (by the way the doc i?ve read only >>>> presents >>>> TOS mathing and nothing about dscp).. >>>> anyway , the problem arises when the incoming traffic (from the internet) >>>> has no dscp tags and i need to enqueue then accordingly to make the >>>> downlink >>>> traffic shapping. >>>> >>>> regards, >>>> evelio vila >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> On Sat, Jun 6, 2009 at 6:15 PM, wrote: >>>>> >>>>> Ermal Lu?i ha escrito: >>>>> >>>>>> >>>>>> >>>>>> On Sat, Jun 6, 2009 at 6:49 PM, wrote: >>>>>> >>>>>> >>>>>>> Vlad Galu ha escrito: >>>>>>> >>>>>>>> >>>>>>>> On Sat, Jun 6, 2009 at 5:57 AM, wrote: >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Hi folks! >>>>>>>>>> >>>>>>>>>> I?m trying to figure out if there is a way to make connection >>>>>>>>>> marking >>>>>>>>>> in >>>>>>>>>> a >>>>>>>>>> similar way as the iptables?s CONNMARK target does? >>>>>>>>>> >>>>>>>>>> Does pf supports this feature? >>>>>>>>>> >>>>>>>>>> My intentions are to tag an outgoing packet, transfer the tag to >>>>>>>>>> the >>>>>>>>>> hole >>>>>>>>>> connection and then use that tag to mark incoming packets belonging >>>>>>>>>> to >>>>>>>>>> the >>>>>>>>>> same connection. >>>>>>>>>> >>>>>>>>>> Also, i would like then to use that mark to enqueue marked packets >>>>>>>>>> to >>>>>>>>>> hfsc >>>>>>>>>> clases. >>>>>>>>>> >>>>>>>>>> I?ve done all of this in linux but never on freebsd, I?ve searched >>>>>>>>>> in >>>>>>>>>> pf?s >>>>>>>>>> man page and the FAQ without success. >>>>>>>>>> >>>>>>>>>> thanks in advance, >>>>>>>>>> >>>>>>>>>> evelio vila >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi evelio, see below: >>>>>>>>> -- cut here -- >>>>>>>>> tag >>>>>>>>> Packets matching this rule will be tagged with the specified >>>>>>>>> string. The tag acts as an internal marker that can be used >>>>>>>>> to >>>>>>>>> identify these packets later on. This can be used, for >>>>>>>>> example, to >>>>>>>>> provide trust between interfaces and to determine if packets >>>>>>>>> have >>>>>>>>> been processed by translation rules. Tags are "sticky", >>>>>>>>> meaning >>>>>>>>> that the packet will be tagged even if the rule is not the >>>>>>>>> last >>>>>>>>> matching rule. Further matching rules can replace the tag >>>>>>>>> with >>>>>>>>> a >>>>>>>>> new one but will not remove a previously applied tag. A >>>>>>>>> packet >>>>>>>>> is >>>>>>>>> only ever assigned one tag at a time. Packet tagging can be >>>>>>>>> done >>>>>>>>> during nat, rdr, or binat rules in addition to filter rules. >>>>>>>>> Tags >>>>>>>>> take the same macros as labels (see above). >>>>>>>>> >>>>>>>>> tagged >>>>>>>>> Used with filter or translation rules to specify that >>>>>>>>> packets >>>>>>>>> must >>>>>>>>> already be tagged with the given tag in order to match the >>>>>>>>> rule. >>>>>>>>> Inverse tag matching can also be done by specifying the ! >>>>>>>>> operator >>>>>>>>> before the tagged keyword. >>>>>>>>> -- and here -- >>>>>>>>> >>>>>>>>> Anyway, I believe that keeping state for the desired outgoing >>>>>>>>> connections should be enough all by itself. You would simply add the >>>>>>>>> >>>>>>>>> >>>>>>>>> Indeed no, what i want is also to mark the connection to be able >>>>>>>> then >>>>>>>> to mark incoming packets beloging to the same connection. >>>>>>>> >>>>>>>> "queue " directive at the end of your pass out rule, even >>>>>>>> >>>>>>>> though the interface packets go out through is the "external" one, >>>>>>>>> and >>>>>>>>> you want to do shaping on the "internal" one but, as I understand, >>>>>>>>> for >>>>>>>>> that you also need floating (not if-bound) states. If I'm wrong, I'd >>>>>>>>> >>>>>>>>> >>>>>>>>> i am not sure what you mean with "floating (not if-bound) states" >>>>>>>> could you please explain this. >>>>>>>> >>>>>>>> >>>>>>>> like somebody with better pf knowledge to correct me :) >>>>>>>>> >>>>>>>>> >>>>>>>>> pf(4) is not iptables. So before using it read more about it. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I?m aware of that. >>>>>>> >>>>>> >>>>>> I think its pretty obvius that my post is simply trying to figure out >>>>>> how >>>>>> to achieve with pf something that i use to do with netfilter. >>>>>> >>>>>> I?ve read this before but nothing comes up to me. >>>>>> http://www.openbsd.org/faq/pf/tagging.html >>>>>> >>>>>> >>>>>> thanks anyway ermal >>>>>> regards, >>>>>> evelio vila >>>>>> >>>>>> >>>>>> http://home.nuug.no/~peter/pf/en/ >>>>>> >>>>>> http://www.openbsd.org/faq/pf >>>>>>> >>>>>>> >>>>>>> >>>>>>> thanks for your quick answer vlad. >>>>>>> >>>>>>> >>>>>>>> evelio vila >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> This message was sent using IMP, the Internet Messaging Program. >>>>>>>> >>>>>>>> >>>>>>>> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a >>>>>>>> y >>>>>>>> Educaci?n Energ?tica >>>>>>>> 9 - 12 de Junio 2009, Palacio de las Convenciones >>>>>>>> ...Por una cultura energ?tica sustentable >>>>>>>> www.ciercuba.com_______________________________________________ >>>>>>>> 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 >>>>>>>> " >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Ermal >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ---------------------------------------------------------------- >>>>>> This message was sent using IMP, the Internet Messaging Program. >>>>>> >>>>>> >>>>>> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >>>>>> Educaci?n Energ?tica >>>>>> 9 - 12 de Junio 2009, Palacio de las Convenciones >>>>>> ...Por una cultura energ?tica sustentable >>>>>> www.ciercuba.com_______________________________________________ >>>>>> freebsd-pf@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >>>>>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> the sun shines for all >>>>> >>>>> >>>>> >>>> >>>> ---------------------------------------------------------------- >>>> This message was sent using IMP, the Internet Messaging Program. >>>> >>>> >>>> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >>>> Educaci?n Energ?tica >>>> 9 - 12 de Junio 2009, Palacio de las Convenciones >>>> ...Por una cultura energ?tica sustentable >>>> www.ciercuba.com >>>> >>>> >>> >>> >>> -- >>> the sun shines for all >>> >>> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y >> Educaci?n Energ?tica >> 9 - 12 de Junio 2009, Palacio de las Convenciones >> ...Por una cultura energ?tica sustentable >> www.ciercuba.com >> > > > > -- > the sun shines for all > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. VI Conferencia Internacional de Energ?a Renovable, Ahorro de Energ?a y Educaci?n Energ?tica 9 - 12 de Junio 2009, Palacio de las Convenciones ...Por una cultura energ?tica sustentable www.ciercuba.com From bugmaster at FreeBSD.org Mon Jun 8 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 8 11:09:12 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200906081106.n58B6w6R020748@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 32 problems total. From fox at verio.net Mon Jun 8 20:53:16 2009 From: fox at verio.net (David DeSimone) Date: Mon Jun 8 20:53:23 2009 Subject: Connmark target In-Reply-To: <20090607132751.18wu3idnkgcgkss8@correo.cujae.edu.cu> References: <20090606124949.japda2vrkck4wk8o@correo.cujae.edu.cu> <9a542da30906060955i4a1097bcpad5fd78587d7e169@mail.gmail.com> <20090606131545.kk8k1qf7a8oc4os8@correo.cujae.edu.cu> <20090606135250.3n87bzp88wc4kgk8@correo.cujae.edu.cu> <20090606142940.0c42ju9uswkg4w8s@correo.cujae.edu.cu> <20090607132751.18wu3idnkgcgkss8@correo.cujae.edu.cu> Message-ID: <20090608205312.GS5596@verio.net> vila@tesla.cujae.edu.cu wrote: > > by the way, anyone knows if there are plans to include connection mark > capabilities to pf. > > i say this because until now is the only way i?ve found to solve my > issue. I think the real question is whether tags become part of connection "state". For instance: pass in quick on $INT_IF from $NETWORK to any tag "INTERNAL" keep state pass out quick on $EXT_IF tagged "INTERNAL" keep state So, when a packet comes in on $INT_IF and goes out $EXT_IF, obviously it will have tag "INTERNAL" attached to it. However, when the reply packet comes back in $EXT_IF and makes its way back to $INT_IF, will it also have the "INTERNAL" tag attached? If it does, that would make ALTQ able to assign it and classify it and queue it the way people want. But the question is, is the tagging considered part of the "state" that is kept in the state table? -- 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 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 eri at freebsd.org Mon Jun 8 22:13:06 2009 From: eri at freebsd.org (=?ISO-8859-1?Q?Ermal_Lu=E7i?=) Date: Mon Jun 8 22:13:13 2009 Subject: Connmark target In-Reply-To: <20090608205312.GS5596@verio.net> References: <20090606124949.japda2vrkck4wk8o@correo.cujae.edu.cu> <9a542da30906060955i4a1097bcpad5fd78587d7e169@mail.gmail.com> <20090606131545.kk8k1qf7a8oc4os8@correo.cujae.edu.cu> <20090606135250.3n87bzp88wc4kgk8@correo.cujae.edu.cu> <20090606142940.0c42ju9uswkg4w8s@correo.cujae.edu.cu> <20090607132751.18wu3idnkgcgkss8@correo.cujae.edu.cu> <20090608205312.GS5596@verio.net> Message-ID: <9a542da30906081512v340b590fme0291f4fdd69db56@mail.gmail.com> On Mon, Jun 8, 2009 at 10:53 PM, David DeSimone wrote: > vila@tesla.cujae.edu.cu wrote: >> >> by the way, anyone knows if there are plans to include connection mark >> capabilities to pf. >> >> i say this because until now is the only way i?ve found to solve my >> issue. > > I think the real question is whether tags become part of connection > "state". > > For instance: > > ? ?pass in quick on $INT_IF from $NETWORK to any tag "INTERNAL" keep state pass in quick on $INT_IF from $NETWORK to any tag "INTERNAL" tagged INTERNAL keep state > > ? ?pass out quick on $EXT_IF tagged "INTERNAL" keep state pass out quick on $EXT_IF tag INTERNAL tagged "INTERNAL" keep state In this way it would work. > > So, when a packet comes in on $INT_IF and goes out $EXT_IF, obviously it > will have tag "INTERNAL" attached to it. ?However, when the reply packet > comes back in $EXT_IF and makes its way back to $INT_IF, will it also > have the "INTERNAL" tag attached? ?If it does, that would make ALTQ able > to assign it and classify it and queue it the way people want. ?But the > question is, is the tagging considered part of the "state" that is kept > in the state table? > > -- > 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 > > > 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" > -- Ermal From rick.harris at strath.ac.uk Wed Jun 10 14:22:53 2009 From: rick.harris at strath.ac.uk (Rick Harris) Date: Wed Jun 10 14:23:00 2009 Subject: PF display options Message-ID: Hello,I am trying to use freebsd PF as a transparent bridge. I have 2 NICs. I have successfully bridged between the nics and have got a windows pc connected on a crossover cable. I have established internet access on the windows pc through the bridge on the unix box but how do I use PF or anything else to display the ip address/protocols (ie tcp/udp) etc of the internet traffic packets going though the UNIX box? I have a live log showing IGMP Rick Harris, IT Technician| TEL: +44 (0)141-548-4842 email: | FAX: +44 (0)141-552-7986 Design, Manufacture and Engineering Management Dept, University of Strathclyde,James Weir Building, 75 Montrose Street, GLASGOW, G1 1XJ, UK <>< The University of Strathclyde is a charitable body, registered in Scotland, number SC015263 From sullrich at gmail.com Wed Jun 10 16:26:30 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Wed Jun 10 16:26:36 2009 Subject: PF display options In-Reply-To: References: Message-ID: On Wed, Jun 10, 2009 at 9:52 AM, Rick Harris wrote: > Hello,I am trying to use freebsd PF as a transparent bridge. > I have 2 NICs. I have successfully bridged between the nics and have got a windows pc connected on a crossover cable. > I have established internet access on the windows pc through the bridge on the unix box but > how do I use PF or anything else to display the ip address/protocols ?(ie tcp/udp) etc of the internet traffic packets going though the UNIX box? > I have a live log showing IGMP Sounds like you are looking for the PFTOP port which is located in /usr/ports/sysutils/pftop Scott From gert at greenie.muc.de Mon Jun 15 06:58:32 2009 From: gert at greenie.muc.de (Gert Doering) Date: Mon Jun 15 06:58:39 2009 Subject: Moving the pf rc.d scripts to run before netif In-Reply-To: <4A242035.8010101@FreeBSD.org> References: <4A242035.8010101@FreeBSD.org> Message-ID: <20090615065817.GJ290@greenie.muc.de> Hi Doug, thanks for taking this up - and sorry for not responding more timely. I can't answer all the questions but might have a yet-unmentioned idea that could solve all this in one go :-) On Mon, Jun 01, 2009 at 11:38:45AM -0700, Doug Barton wrote: > 2. The previous rcorder for the pf script was right after netif (the > network coming up) and before routing .... why? Is this related to how > pf does its work? The reason I ask this question is that in order to > fix the IPv6 rcorder problem in the pr the way that Gert is suggesting > the "BEFORE: routing" would have to be removed because our IPv6 > startup depends on RA which depends on routing being up. (Side note, > in the long term I'd like to revise this so that an IPv6-only host > and/or a host with statically assigned IPv6 addresses can easily be > configured within rc.d, but that's another thing altogether.) > > 3. Is the need to be able to use $ext_if after the network is up so > overwhelmingly important that it justifies running pf after netif? Or > is using ($ext_if) a reasonable solution? Well - let's turn this one around: since we *have* the functionality in pf(4), let's not cripple it by building a framework that makes using this functionality effectively impossible. If I understand Bjoern right, this is also a performance issue - ($ext_if) needs a per-packet lookup to get the now-current address, while $ext_if reads the address at pf setup time. I can see the arguments for having the firewall initialization right at the start - to avoid opening an window of opportunity where services are "up" but the firewall hasn't yet been loaded. So what about the following approach: - split the firewall initialization into two halves - the first half is run before any other networking stuff is configured and basically sets up a "deny everything incoming" filter (with exceptions for IPv6 RD/ND, of course). Optionally this could permit outbound connections (with state), to enable things like bgpd to run. - after this, run interface configuration, set up routing, ... - when all this is finished, load the "real" set of firewall rules, which can now (if so desired) safely use $ext_if gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert@greenie.muc.de fax: +49-89-35655025 gert@net.informatik.tu-muenchen.de From bugmaster at FreeBSD.org Mon Jun 15 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 15 11:09:08 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200906151107.n5FB70Bh077023@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 32 problems total. From dougb at FreeBSD.org Mon Jun 15 19:26:06 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jun 15 19:26:13 2009 Subject: Moving the pf rc.d scripts to run before netif In-Reply-To: <20090615065817.GJ290@greenie.muc.de> References: <4A242035.8010101@FreeBSD.org> <20090615065817.GJ290@greenie.muc.de> Message-ID: <4A36A051.3040007@FreeBSD.org> Gert Doering wrote: > Hi Doug, > > thanks for taking this up - and sorry for not responding more timely. > > I can't answer all the questions but might have a yet-unmentioned idea > that could solve all this in one go :-) > > On Mon, Jun 01, 2009 at 11:38:45AM -0700, Doug Barton wrote: >> 2. The previous rcorder for the pf script was right after netif (the >> network coming up) and before routing .... why? Is this related to how >> pf does its work? The reason I ask this question is that in order to >> fix the IPv6 rcorder problem in the pr the way that Gert is suggesting >> the "BEFORE: routing" would have to be removed because our IPv6 >> startup depends on RA which depends on routing being up. (Side note, >> in the long term I'd like to revise this so that an IPv6-only host >> and/or a host with statically assigned IPv6 addresses can easily be >> configured within rc.d, but that's another thing altogether.) >> >> 3. Is the need to be able to use $ext_if after the network is up so >> overwhelmingly important that it justifies running pf after netif? Or >> is using ($ext_if) a reasonable solution? > > Well - let's turn this one around: since we *have* the functionality in > pf(4), let's not cripple it by building a framework that makes using this > functionality effectively impossible. If I understand Bjoern right, this > is also a performance issue - ($ext_if) needs a per-packet lookup to > get the now-current address, while $ext_if reads the address at pf setup > time. > > > I can see the arguments for having the firewall initialization right at > the start - to avoid opening an window of opportunity where services are > "up" but the firewall hasn't yet been loaded. > > > So what about the following approach: > > - split the firewall initialization into two halves > > - the first half is run before any other networking stuff is configured > and basically sets up a "deny everything incoming" filter (with > exceptions for IPv6 RD/ND, of course). > > Optionally this could permit outbound connections (with state), to > enable things like bgpd to run. > > - after this, run interface configuration, set up routing, ... > > - when all this is finished, load the "real" set of firewall rules, > which can now (if so desired) safely use $ext_if I already said I support this solution, I'm just waiting for someone with some real pf knowledge to propose something. Doug From vwe at FreeBSD.org Tue Jun 16 20:46:35 2009 From: vwe at FreeBSD.org (vwe@FreeBSD.org) Date: Tue Jun 16 20:46:42 2009 Subject: kern/134996: [pf] Anchor tables not included when pfctl(8) is run with -o Message-ID: <200906162046.n5GKkYp9083921@freefall.freebsd.org> Old Synopsis: Anchor tables not included when pfctl is run with -o New Synopsis: [pf] Anchor tables not included when pfctl(8) is run with -o Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: vwe Responsible-Changed-When: Tue Jun 16 20:45:10 UTC 2009 Responsible-Changed-Why: not quite sure if this is question or a bug report Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=134996 From bugmaster at FreeBSD.org Mon Jun 22 11:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 22 11:09:02 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200906221107.n5MB70kI018132@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 33 problems total. From fayerwall at gmail.com Wed Jun 24 01:24:24 2009 From: fayerwall at gmail.com (Fire walls) Date: Wed Jun 24 01:24:30 2009 Subject: Understanding the keep state? Message-ID: Hi people. I start working with pf in freebsd 7.2. Is working, but I have some doubts that I would like someone to clarify me. My home network is the classic one, 2 nics: Nic1 --> ng0 Public IP PPPoE Nic2 --> sis0 My Home network. All my clients like winboxes, linux and bsd OS receive the IP from my firewall. If someone try to access to the outside they reach the Nic2 and them Nic1 and done they can access the outside. The keep state function is to track each connection, in my case I prefer to open just the ports I need, example the www. Nic1 --> ExtIF Nic2 --> IntIF LOCALLAN= 192.168.50.0/24 *Nat Rule nat on $ExtIF inet from $LOCALLAN to any -> ($ExtIF) *LAN Rule pass in quick on $IntIF proto tcp from $LOCALLAN to any port 80 flags S/SA *Firewall Rule pass out quick on $ExtIF proto tcp from any to any port 80 flags S/SA keep state label "Internet Browsing http" In my case, anyone who need access to the outside(www) they first reach the "LAN Rule", them the IntIF detect that they need are trying to access a IP that is not in his site, them that nic forward the package to the next gate in this case the ExtIF and touch the "Firewall Rule". Working this way, where is the best way to put the "keep state" statement, in the "LAN Rules" or in the "Firewall Rules" or in both parts? Thanks all for your help, if Im doing this the wrong way please let me know, I want to get a deep understanding of pf. -- :-) From fayerwall at gmail.com Wed Jun 24 04:31:28 2009 From: fayerwall at gmail.com (Fire walls) Date: Wed Jun 24 04:31:35 2009 Subject: Understanding the keep state? In-Reply-To: <4A41814B.7010909@gmail.com> References: <4A41814B.7010909@gmail.com> Message-ID: On Tue, Jun 23, 2009 at 6:28 PM, Eric Williams wrote: > On 6/23/2009 7:58 PM, Fire walls wrote: > > > > Working this way, where is the best way to put the "keep state" > statement, > > in the "LAN Rules" or in the "Firewall Rules" or in both parts? > > > > Thanks all for your help, if Im doing this the wrong way please let me > > know, I want to get a deep understanding of pf. > > Excluding certain rare cases, generally you want to keep state on all > rules. Because of this more recent pf versions keep state by default. If > you have a particular reason you don't want state kept, you need to use > the "no state" statement, however, take note that if you're using NAT, > you need state for proper routing of responses. > > Thanks for your quick answer. Them in make case is better to have: *LAN Rule pass in quick on $IntIF proto tcp from $LOCALLAN to any port 80 flags S/SA keep state *Firewall Rule pass out quick on $ExtIF proto tcp from any to any port 80 flags S/SA keep state Like u say, the current version add the "keep state" by default, is the same thing I'm doing here, there will not be any problem? Thanks for your help!!! -- :-) From fayerwall at gmail.com Wed Jun 24 15:52:56 2009 From: fayerwall at gmail.com (Fire walls) Date: Wed Jun 24 15:53:03 2009 Subject: OpenVPN Client Nat question? Message-ID: Hi people. Working with pf, every day I'm understanding more pf. I have openvpn at work running on gentoo, I add my openvpn in my home FW with freebsd 7.2, I setup everything and is working, I can reach my work network. I read some sites on internet about this setup and they say something about NAT the openvpn network but doesn't explain if this must be done just in the server side or both sides, I mean server + client. In my case I'm a client, I have to NAT my vpn network? nat on $ext_if from $vpn_network to any -> ($ext_if) Or just need to play with the pass/block rules? Thanks all for your time!!! -- :-) From fayerwall at gmail.com Wed Jun 24 19:33:30 2009 From: fayerwall at gmail.com (Fire walls) Date: Wed Jun 24 19:33:37 2009 Subject: OpenVPN Client Nat question? In-Reply-To: <014301c9f4fb$bb7893e0$3269bba0$@net> References: <014301c9f4fb$bb7893e0$3269bba0$@net> Message-ID: On Wed, Jun 24, 2009 at 11:43 AM, Torsten Kersandt wrote: > -----Original Message----- > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] > On > Behalf Of Fire walls > Sent: 24 June 2009 16:53 > To: freebsd-pf@freebsd.org > Subject: OpenVPN Client Nat question? > > Hi people. > > Working with pf, every day I'm understanding more pf. > > I have openvpn at work running on gentoo, I add my openvpn in my home FW > with freebsd 7.2, I setup everything and is working, I can reach my work > network. > > I read some sites on internet about this setup and they say something > about NAT the openvpn network but doesn't explain if this must be done just > in the server side or both sides, I mean server + client. > > In my case I'm a client, I have to NAT my vpn network? > > nat on $ext_if from $vpn_network to any -> ($ext_if) > > Or just need to play with the pass/block rules? > > Thanks all for your time!!! > > -- > :-) > _______________________________________________ > 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" > > This is what I have got on my boxes > Openvpn.conf: > server 10.12.215.0 255.255.255.0 > ifconfig-pool-persist /usr/local/etc/openvpn/ipp.txt > > # Certificates for VPN Authentication > ca /usr/local/etc/openvpn/keys/soundnet/ca.crt > cert /usr/local/etc/openvpn/keys/soundnet/ca.crt > key /usr/local/etc/openvpn/keys/soundnet/ca.key > dh /usr/local/etc/openvpn/keys/soundnet/dh1024.pem > > # Routes to push to the client > push "route 192.168.100.0 255.255.255.0" > push "dhcp-option WINS 192.168.100.12" > push "dhcp-option DNS 192.168.100.12" > push "dhcp-option DNS 192.168.100.12" > push "dhcp-option DOMAIN home" > > pf.conf > vpn_if="tun0" > vpn_network="10.12.215.0/24" > > nat on $ext_if from $vpn_network to any -> ($ext_if) > nat on $int_if from $vpn_network to $int_net -> ($int_if) > > pass in quick on $vpn_if > pass out quick > > regards > Torsten > > > Hi Torsten. Hey but this config is for the server side right? What questions is, if I have have to NAT to in the client side? Thanks for your quick answer!!! -- :-) From torsten at cnc-london.net Wed Jun 24 20:14:08 2009 From: torsten at cnc-london.net (Torsten Kersandt) Date: Wed Jun 24 20:14:15 2009 Subject: OpenVPN Client Nat question? In-Reply-To: References: <014301c9f4fb$bb7893e0$3269bba0$@net> Message-ID: <014901c9f504$8dfbe620$a9f3b260$@net> > -----Original Message----- > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] > On > Behalf Of Fire walls > Sent: 24 June 2009 16:53 > To: freebsd-pf@freebsd.org > Subject: OpenVPN Client Nat question? > > Hi people. > > Working with pf, every day I'm understanding more pf. > > I have openvpn at work running on gentoo, I add my openvpn in my home FW > with freebsd 7.2, I setup everything and is working, I can reach my work > network. > > I read some sites on internet about this setup and they say something > about NAT the openvpn network but doesn't explain if this must be done just > in the server side or both sides, I mean server + client. > > In my case I'm a client, I have to NAT my vpn network? > > nat on $ext_if from $vpn_network to any -> ($ext_if) > > Or just need to play with the pass/block rules? > > Thanks all for your time!!! > > -- > :-) > _______________________________________________ > 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" > > This is what I have got on my boxes > Openvpn.conf: > server 10.12.215.0 255.255.255.0 > ifconfig-pool-persist /usr/local/etc/openvpn/ipp.txt > > # Certificates for VPN Authentication > ca /usr/local/etc/openvpn/keys/soundnet/ca.crt > cert /usr/local/etc/openvpn/keys/soundnet/ca.crt > key /usr/local/etc/openvpn/keys/soundnet/ca.key > dh /usr/local/etc/openvpn/keys/soundnet/dh1024.pem > > # Routes to push to the client > push "route 192.168.100.0 255.255.255.0" > push "dhcp-option WINS 192.168.100.12" > push "dhcp-option DNS 192.168.100.12" > push "dhcp-option DNS 192.168.100.12" > push "dhcp-option DOMAIN home" > > pf.conf > vpn_if="tun0" > vpn_network="10.12.215.0/24" > > nat on $ext_if from $vpn_network to any -> ($ext_if) > nat on $int_if from $vpn_network to $int_net -> ($int_if) > > pass in quick on $vpn_if > pass out quick > > regards > Torsten > > > Hi Torsten. Hey but this config is for the server side right? What questions is, if I have have to NAT to in the client side? Thanks for your quick answer!!! -- :-) _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" The client side only needs to which route to which network to take. In this case my internal network is 192.168.100.0/24 and fully accessible by all openvpn connections. If you want your computer to fully become part (of the other sites network bi directional and fully accessible as in a common Micros..t Network), You may have to go down the bridging way , meaning tun0<-->ext_if, never done that and can't help on this. But as much as have been reading about it not a impossible thing to do Regards T From fayerwall at gmail.com Wed Jun 24 21:23:56 2009 From: fayerwall at gmail.com (Fire walls) Date: Wed Jun 24 21:24:19 2009 Subject: OpenVPN Client Nat question? In-Reply-To: <014901c9f504$8dfbe620$a9f3b260$@net> References: <014301c9f4fb$bb7893e0$3269bba0$@net> <014901c9f504$8dfbe620$a9f3b260$@net> Message-ID: On Wed, Jun 24, 2009 at 12:47 PM, Torsten Kersandt wrote: > > -----Original Message----- > > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] > > On > > Behalf Of Fire walls > > Sent: 24 June 2009 16:53 > > To: freebsd-pf@freebsd.org > > Subject: OpenVPN Client Nat question? > > > > Hi people. > > > > Working with pf, every day I'm understanding more pf. > > > > I have openvpn at work running on gentoo, I add my openvpn in my home > FW > > with freebsd 7.2, I setup everything and is working, I can reach my work > > network. > > > > I read some sites on internet about this setup and they say something > > about NAT the openvpn network but doesn't explain if this must be done > just > > in the server side or both sides, I mean server + client. > > > > In my case I'm a client, I have to NAT my vpn network? > > > > nat on $ext_if from $vpn_network to any -> ($ext_if) > > > > Or just need to play with the pass/block rules? > > > > Thanks all for your time!!! > > > > -- > > :-) > > _______________________________________________ > > 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" > > > > This is what I have got on my boxes > > Openvpn.conf: > > server 10.12.215.0 255.255.255.0 > > ifconfig-pool-persist /usr/local/etc/openvpn/ipp.txt > > > > # Certificates for VPN Authentication > > ca /usr/local/etc/openvpn/keys/soundnet/ca.crt > > cert /usr/local/etc/openvpn/keys/soundnet/ca.crt > > key /usr/local/etc/openvpn/keys/soundnet/ca.key > > dh /usr/local/etc/openvpn/keys/soundnet/dh1024.pem > > > > # Routes to push to the client > > push "route 192.168.100.0 255.255.255.0" > > push "dhcp-option WINS 192.168.100.12" > > push "dhcp-option DNS 192.168.100.12" > > push "dhcp-option DNS 192.168.100.12" > > push "dhcp-option DOMAIN home" > > > > pf.conf > > vpn_if="tun0" > > vpn_network="10.12.215.0/24" > > > > nat on $ext_if from $vpn_network to any -> ($ext_if) > > nat on $int_if from $vpn_network to $int_net -> ($int_if) > > > > pass in quick on $vpn_if > > pass out quick > > > > regards > > Torsten > > > > > > > Hi Torsten. > > Hey but this config is for the server side right? > > What questions is, if I have have to NAT to in the client side? > > Thanks for your quick answer!!! > > > -- > :-) > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > > The client side only needs to which route to which network to take. > In this case my internal network is 192.168.100.0/24 and fully accessible > by > all openvpn connections. > > If you want your computer to fully become part (of the other sites network > bi directional and fully accessible as in a common Micros..t Network), > You may have to go down the bridging way , meaning tun0<-->ext_if, never > done that and can't help on this. > But as much as have been reading about it not a impossible thing to do > > Regards T > > > > _______________________________________________ > 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" > Thanks Torsten. U already had answer my question, I appreciated your very well help and time. See u latter, thanks again!!! -- :-) From linimon at FreeBSD.org Thu Jun 25 07:29:21 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Jun 25 07:29:33 2009 Subject: kern/135948: [pf] [gre] pf not natting gre protocol Message-ID: <200906250729.n5P7TKKM086781@freefall.freebsd.org> Old Synopsis: pf not natting gre protocol New Synopsis: [pf] [gre] pf not natting gre protocol Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jun 25 07:29:00 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=135948 From tutorial at gawab.com Thu Jun 25 08:35:10 2009 From: tutorial at gawab.com (x) Date: Thu Jun 25 08:35:17 2009 Subject: Any kind of hashing filters for Pf ? Message-ID: <4A433076.1060006@gawab.com> Hi everyone! I am new to Pf and ALTQ. My question is fairly obscure. Does pf support any kind hashing ? (for large rulesets). Basically like this: http://lartc.org/howto/lartc.adv-filter.hashing.html How does a QoS hfsc solution behave for two /24 blocks (500 hosts), each with 4 queues ? Anyone can share some experience? Best regards From dudu at dudu.ro Thu Jun 25 08:40:13 2009 From: dudu at dudu.ro (Vlad Galu) Date: Thu Jun 25 08:40:18 2009 Subject: Any kind of hashing filters for Pf ? In-Reply-To: <4A433076.1060006@gawab.com> References: <4A433076.1060006@gawab.com> Message-ID: On Thu, Jun 25, 2009 at 11:08 AM, x wrote: > Hi everyone! > I am new to Pf and ALTQ. ?My question is fairly obscure. Does pf support any > kind hashing ? (for large rulesets). Basically like this: > ?http://lartc.org/howto/lartc.adv-filter.hashing.html > How does a QoS hfsc solution behave for two /24 blocks (500 hosts), each > with 4 queues ? Anyone can share some experience? It scales very well when you use PF tables (they're basically tries) for matching packets when queueing. From v.prokofyev at gmail.com Thu Jun 25 09:47:02 2009 From: v.prokofyev at gmail.com (Prokofyev Vladislav) Date: Thu Jun 25 09:47:08 2009 Subject: Any kind of hashing filters for Pf ? In-Reply-To: <46dcef4e0906250213q235be17dw2bf81e61cd5a6a79@mail.gmail.com> References: <4A433076.1060006@gawab.com> <46dcef4e0906250213q235be17dw2bf81e61cd5a6a79@mail.gmail.com> Message-ID: <46dcef4e0906250216o3a9cb302h28e6b5d9142478e0@mail.gmail.com> 2009/6/25 Vlad Galu > > It scales very well when you use PF tables (they're basically tries) > for matching packets when queueing. > _______________________________________________ > 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" > Also, tables are recommended according to PF howto. ps: sorry, forgot to send copy to the mail-list at once. -- With best regards, Vladislav Prokofyev From max at love2party.net Fri Jun 26 09:04:11 2009 From: max at love2party.net (Max Laier) Date: Fri Jun 26 09:04:18 2009 Subject: pfsync rc script breaks pfsync on cloned interfaces In-Reply-To: <4A444BC2.4010606@FreeBSD.org> References: <4A444BC2.4010606@FreeBSD.org> Message-ID: <200906261104.07597.max@love2party.net> On Friday 26 June 2009 06:17:06 Doug Barton wrote: > I have reverted the change that caused pf and ipfw to appear before > netif in the rcorder. While I still feel strongly that it is the > "right thing" to configure the firewalls first, the changes caused too > many problems for too many users, and it's too late in the release > cycle to make a change like this that has significant side effects. > > I would like to strongly encourage those who use pf and ipfw to > consider doing the work required to make this change possible. With > ipfw it's not quite as urgent since by default it does not pass > packets till it is configured. This is not the case with pf, as its > default is wide open until it is configured. It's not a simple problem and I'm not sure we can really come up with a "one-size-fits-all" solution. That does not mean we shouldn't try, though. My idea how this should work is something along the following lines: 1) Very early in the boot (just after the necessary firewall configuration tools are available [NFS-root might be a problem here!]) setup an "initial firewall" configuration. For most users this could be a default (allow dhcp, outgoing DNS, maybe ssh in/out, NFS(???), ...). 2) After setting up the interfaces have the option to start a more involved firewall that is fully user supplied. At this point we should be able to look up DNS (though this is clearly a bad idea from the security PoV unless you have DNSSEC), get interface configurations and maybe even routing information. The latter could be another chicken-egg-problem as we might need a routing daemon active to get this. However, people who really need that should be able to modify the early setup accordingly. It is unclear to me where stage 2 should be located. I would argue that with a reasonable default setup we can easily get away with putting stage 2 at the very end of the start up procedure. If people need early holes in the firewall (e.g. for smbfs, routing daemons, ...) they can place them in the early stage. I would like input about how a very simple "save default" setup could look like. A ruleset for pf or ipfw that allows most of the boot process to complete without opening the host to the outside world, yet. For extra points this ruleset is aware of the rc.conf variables and adjusts accordingly (e.g. opening access to sshd iff it is configured). In addition there might be *one or two* configuration variables for the early stage to open additional ports or to select a default interface. However, the fewer the better. Input greatly appreciated! -- /"\ 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 dimitry at andric.com Fri Jun 26 11:58:24 2009 From: dimitry at andric.com (Dimitry Andric) Date: Fri Jun 26 11:58:31 2009 Subject: pfsync rc script breaks pfsync on cloned interfaces In-Reply-To: <200906261104.07597.max@love2party.net> References: <4A444BC2.4010606@FreeBSD.org> <200906261104.07597.max@love2party.net> Message-ID: <4A44B7DE.2090503@andric.com> On 2009-06-26 11:04, Max Laier wrote: > I would like input about how a very simple "save default" setup could look > like. A ruleset for pf or ipfw that allows most of the boot process to > complete without opening the host to the outside world, yet. For extra > points this ruleset is aware of the rc.conf variables and adjusts > accordingly (e.g. opening access to sshd iff it is configured). In > addition there might be *one or two* configuration variables for the early > stage to open additional ports or to select a default interface. However, > the fewer the better. If you look at how OpenBSD implements their /etc/rc script, you will see it first loads a simple PF ruleset, which allows ssh, dns, icmp echo and (if applicable) IPv6 routing and neighbor advertisements. Then it does the regular network setup (/etc/netstart), followed by loading the full PF rules. Relevant excerpt: ###################### if [ X"${pf}" != X"NO" ]; then RULES="block all" RULES="$RULES\npass on lo0" RULES="$RULES\npass in proto tcp from any to any port 22 keep state" RULES="$RULES\npass out proto { tcp, udp } from any to any port 53 keep state" RULES="$RULES\npass out inet proto icmp all icmp-type echoreq keep state" if ifconfig lo0 inet6 >/dev/null 2>&1; then RULES="$RULES\npass out inet6 proto icmp6 all icmp6-type neighbrsol" RULES="$RULES\npass in inet6 proto icmp6 all icmp6-type neighbradv" RULES="$RULES\npass out inet6 proto icmp6 all icmp6-type routersol" RULES="$RULES\npass in inet6 proto icmp6 all icmp6-type routeradv" fi RULES="$RULES\npass proto carp keep state (no-sync)" case `sysctl vfs.mounts.nfs 2>/dev/null` in *[1-9]*) # don't kill NFS RULES="set reassemble yes no-df\n$RULES" RULES="$RULES\npass in proto { tcp, udp } from any port { 111, 2049 } to any" RULES="$RULES\npass out proto { tcp, udp } from any to any port { 111, 2049 }" ;; esac echo $RULES | pfctl -f - pfctl -e fi # Fill net.inet.(tcp|udp).baddynamic lists from /etc/services fill_baddynamic udp fill_baddynamic tcp sysctl_conf # set hostname, turn on network echo 'starting network' ifconfig -g carp carpdemote 128 if [ -f /etc/resolv.conf.save ]; then mv /etc/resolv.conf.save /etc/resolv.conf touch /etc/resolv.conf fi . /etc/netstart if [ X"${pf}" != X"NO" ]; then if [ -f ${pf_rules} ]; then pfctl -f ${pf_rules} fi # bring up pfsync after the working ruleset has been loaded if [ -f /etc/hostname.pfsync0 ]; then . /etc/netstart pfsync0 fi fi ###################### Perhaps this approach can be molded into /etc/rc.d form? :) From dougb at FreeBSD.org Fri Jun 26 14:56:31 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jun 26 14:56:37 2009 Subject: pfsync rc script breaks pfsync on cloned interfaces In-Reply-To: <4A44B7DE.2090503@andric.com> References: <4A444BC2.4010606@FreeBSD.org> <200906261104.07597.max@love2party.net> <4A44B7DE.2090503@andric.com> Message-ID: <4A44E198.3050004@FreeBSD.org> Dimitry Andric wrote: > On 2009-06-26 11:04, Max Laier wrote: >> I would like input about how a very simple "save default" setup could look >> like. A ruleset for pf or ipfw that allows most of the boot process to >> complete without opening the host to the outside world, yet. For extra >> points this ruleset is aware of the rc.conf variables and adjusts >> accordingly (e.g. opening access to sshd iff it is configured). In >> addition there might be *one or two* configuration variables for the early >> stage to open additional ports or to select a default interface. However, >> the fewer the better. > > If you look at how OpenBSD implements their /etc/rc script, you will see > it first loads a simple PF ruleset, which allows ssh, dns, icmp echo and > (if applicable) IPv6 routing and neighbor advertisements. > > Then it does the regular network setup (/etc/netstart), followed by > loading the full PF rules. I think that would be a great approach, it's just waiting for someone familiar with pf to implement it. :) I also forgot to mention, there is no need to include me on future cc's for this topic. Regards, Doug -- This .signature sanitized for your protection From Edward2a at gmail.com Fri Jun 26 18:47:38 2009 From: Edward2a at gmail.com (Edward2a) Date: Fri Jun 26 18:47:47 2009 Subject: Problems with connections Message-ID: <24225285.post@talk.nabble.com> Hello to everyone. Sorry to bother, probably I'm somewhat loose. I'm having problems with various pf configurations. Basicly, all of them work as router/firewall, with scrub, and all are behind a cisco asa. 1st: I have to make a nat rule for all passing trough smtp connections that send mail with attachments. 2nd: Connections dynamically drop. Wether downloading a file trhough web or ftp, or using rdp client, connection drops alike. Any tips would be helpful. Thanks in advance. -- View this message in context: http://www.nabble.com/Problems-with-connections-tp24225285p24225285.html Sent from the freebsd-pf mailing list archive at Nabble.com. From bugmaster at FreeBSD.org Mon Jun 29 11:07:05 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 29 11:09:02 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200906291107.n5TB74pk046439@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 34 problems total.